Very nice!
Controlling the SideCar should be a piece of cake, considering that the input selection code already exists and that the sidecar itself is essentialy just a relay.
I am guessing that you are using the myGLCD.drawBitmap function and Henning's online ImageConverter 565.
Are you sure that the c files that are generated are not too big?
For example, the little graphic displayed below takes up almost 20K of memory:
Attachments
I am still considering whether use SideCar or not as it is not a good device to switch high frequency digital signal. I was thinking to use Ian's BIII input adaptor with SideCar for impedance matching but seems not that simple.
Did you buy the available shield with the screen?
What is the pin layout you have used for the screen & mega?
Do you have a link to the code you are using?
Yes, I bought the shield with the screen, it made wiring much easier.
You can directly plug the screen with shield onto the mega. If you want to connect them by wires, just download the two pages manual.
PM your email and I will send you my code.
I am guessing that you are using the myGLCD.drawBitmap function and Henning's online ImageConverter 565.
Are you sure that the c files that are generated are not too big?
For example, the little graphic displayed below takes up almost 20K of memory:
I convert the TPA logo using the online converter and the file generated is 20K which cause the "file too big" error.
That is indeed odd. I don't have much experience with the drawBitmap function, but since it stores the bitmap in an array, it is limited by the max size of an array.
If I were you, I would probably experiment with the UTFT_tinyFAT library and try storing my bitmaps as files on an SD card. That is probably the way to go in the long run, since the 256K available on the MEGA is pretty limiting.
If I were you, I would probably experiment with the UTFT_tinyFAT library and try storing my bitmaps as files on an SD card. That is probably the way to go in the long run, since the 256K available on the MEGA is pretty limiting.
Hi CeeVee
you are correct, it was caused by short circuit. I hoped it was caused by something else other than the ES9018. After I removed all the tridents, DVCC and GND on the BIII still shorted. The only component connected to these points is the ES9018. I further confirmed the chip is dead by removed it from the PCB. No short on PCB and the two pins on the chip shorted.
That's too bad. Seems you are capable of replacing the chip yourself.
I was enjoying reading about your project very much...
Have you found reason for short circuit yet ? I'd like to see you conclude your project....I'm working on similar one and was hoping to use your code...I'm no good there
It would be indeed sad if you put a new chip in and the root of the problem is still there....boom another chip gone !
Have you found reason for short circuit yet ? I'd like to see you conclude your project....I'm working on similar one and was hoping to use your code...I'm no good there
It would be indeed sad if you put a new chip in and the root of the problem is still there....boom another chip gone !
I've ordered the chip and hope it will arrive in the next couple of days. I don't know what actually cause the chip die but may be the I2C bus shorted to the SSLV supply rail when I accidentially drop the I2C level converter onto the SSLV when I was testing the BIII with Ian's adaptors.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.