|
Post by powersoft on Oct 19, 2015 11:41:55 GMT -8
Hi, Found on the forum some jpg files. When I run them I get the error "ERROR COPROCESSOR EXECPTION" What is wrong with this jpg file? Cheers, Jan
|
|
|
Post by jamesbowman on Oct 19, 2015 14:30:12 GMT -8
At a guess I would say that it is a progressive JPEG. The FT800 can only decode non-progressive (also known as baseline) JPEGs.
If you attach the JPEG I will be able to tell for sure.
|
|
|
Post by Renaud on Dec 1, 2015 12:25:27 GMT -8
Hi,
Is it possible to get the ERROR COPROCESSOR EXCEPTION on the screen because of a weak power supply?
Thx, Renaud
|
|
|
Post by jamesbowman on Dec 1, 2015 22:11:19 GMT -8
Yes. If there is a data integrity issue on the SPI bus between Arduino and the FT800, then COPROCESSOR EXCEPTION can happen because of a corrupted command stream.
|
|
dl14
Junior Member
Posts: 22
|
Post by dl14 on Sept 12, 2016 19:09:48 GMT -8
I am having a similar issue. I am using the default viewer program to see the files in my microSD. I have uploaded an image to the microSD card and it pre-loaded the image once and I when I power cycled the board (unplug and replug the USB), I received the "ERROR COPROCESSOR EXCEPTION" I have confirmed that it is not a progressive JPEG and also that the size is smaller than the screen of the gameduino2. Any suggestions on formatting images so that they always work on the Gameduino 2? I have attached the image to this post. Thanks!!
|
|
|
Post by jamesbowman on Sept 13, 2016 6:45:51 GMT -8
That jpeg was in 4:4:0 format, which the FT800 cannot handle. Here's the same image, converted to 4:2:0 format with Gimp, should load fine.
|
|
dl14
Junior Member
Posts: 22
|
Post by dl14 on Sept 14, 2016 13:48:00 GMT -8
Thank you very much!
How can I recognize this with other pictures and how can I re-format them to be 4:2:0?
Thanks!
|
|
|
Post by jamesbowman on Sept 15, 2016 5:46:09 GMT -8
Good question. I used ImageMagick, and the command-line:
identify -format "%f %[jpeg:sampling-factor]\n" *.jpg
to report on the two jpegs:
Gita_1.jpg 1x2,1x1,1x1 Gita_2.jpg 2x2,1x1,1x1
4:2:0 jpegs (1x2 sampling factor) are very rarely seen.
|
|
dl14
Junior Member
Posts: 22
|
Post by dl14 on Sept 16, 2016 16:43:41 GMT -8
Ah okay! I got ImageMagick working on my machine and can see the sampling factor now. Can I use ImageMagick to convert pictures to have a 2x2 sampling factor or is it possible in GIMP?
To clarify, the FT800 requires a 2x2 sampling factor, correct? What is the equivalent ratio (4:2 or 4:4)?
|
|
|
Post by deathbyhandswallow on Nov 9, 2016 20:26:29 GMT -8
Hi, I have the same issue loading a .jpg. I use the example code "jpeg" and I only change the name of the file for the name of my image .jpg file. I modified the picture with Gimp so it is 480 px X 272 px, 4:2:0, non-progressive jpeg. Is there another possible reason for that coprocessor exception error? I am using a fat-32 formatted 16 GB class 10 microSD card.
|
|
dl14
Junior Member
Posts: 22
|
Post by dl14 on Apr 17, 2017 16:44:14 GMT -8
Try 4 or 8 gb SanDisk or Kingston
|
|
|
Post by aliekens on Jan 22, 2018 6:05:26 GMT -8
I am also having problems converting files to JPEGs and getting "COPROCESSOR EXCEPTION" errors. I have tried some of the above suggestions, but the problem remains. For example, I want to convert this "ashtray.png" file to JPEG so I can use it on my Gameduino 3: I convert it to a JPEG using ImageMagick, making sure it is non-progressive and fits the 2x2,1x1,1x1 sampling factor, as suggested in this thread: convert ashtray.png -colorspace sRGB -type truecolor -sampling-factor 2x2,1x1,1x1 -interlace none ashtray.jpg
The converted "ashtray.jpg" is this one: ImageMagick confirms that the JPEG uses the correct sampling factor: $ identify -format "%f %[jpeg:sampling-factor]\n" ashtray.jpg ashtray.jpg 2x2,1x1,1x1
ImageMagick also confirms that the JPEG is not progressive: $ identify -verbose ashtray.jpg | grep Interlace Interlace: None Although the JPG seems fine, loading and rendering it with the Gameduino results in a "COPROCESSOR EXCEPTION" error. What am I doing wrong? Any help is greatly appreciated.
|
|
|
Post by aliekens on Jan 22, 2018 7:20:19 GMT -8
I managed to show the converted picture, but only after scaling it down to 128x128 pixels (from 283x283).
convert ashtray.png -scale 128x128 -colorspace sRGB -type truecolor -sampling-factor 2x2,1x1,1x1 -interlace none ashtray.jpg Is there a limit to the size of my JPEGs? The "tree.jpg" example file on the SD card is much bigger and more complex, but loads and renders just fine.
|
|
|
Post by jamesbowman on Jan 22, 2018 16:11:39 GMT -8
I took the first jpg above (the 283x283 one), copied it to a microSD card, and modified the jpg example: #include <EEPROM.h> #include <SPI.h> #include <GD2.h>
void setup() { GD.begin(); GD.cmd_loadimage(0, 0); GD.load("ashtray.jpg"); }
void loop() { GD.Clear(); GD.Begin(BITMAPS); GD.Vertex2ii(0, 0); GD.swap(); }
Seems to come up fine: Strange. Just to be certain it's the same file as you have: $ sha1sum ashtray.jpg 98ae529f552ceb721b743501f2bd5bf52c52bede ashtray.jpg
|
|
janb
Full Member
Retiree, born 1948, mostly HW/FW oriented programming for > 50 years, 25+ for IBM
Posts: 33
|
Post by janb on Aug 6, 2020 12:13:01 GMT -8
Hi, I'm having problems with 'Coprocessor exception: ERROR: display list overflow in cmd_text()'. They seem to occur when I write (too?) many consecutive 'GD.cmd_text' stmts. FT800 Programmers Guide, 5.5 Fault Scenarios, says "An attempt is made to write more than 2048 instructions into a display list". How can I avoid this? How many consecutive cmd_texts are safe to issue? Should I insert GD.finish() or GD.flush() among my cmd_texts? Is it possible to recover from a 'Coprocessor exception'? There is a 'Recovery Description' in the Programmers Guide, but I have no idea how to implement it...! I found a 'GD.reset()' cmd in GD2.cpp, but it doesn't seem to do exactly as described in the FT800 Programmers Guide...
I tried to do a 'GD.finish()' for every 5th 'GD.cmd_text()' cmd (I display up to 17 loglines); the "Coprocessor Exception" occur anyway! Even with a 'GD.finish()' for every 3rd 'GD.cmd_text()', they still occur...
A 'GD.finish()' before EVERY 'GD.cmd_text()' seem to help; execution time from top to bottom of my code is still about 16.7ms (60Hz!)...
|
|