633 Acknowledgement

[wyofreeride]

I am using the 633 display in a hardware based MP3 player project, and am wondering if there is any way to disable the acknowlegement that is returned for each packet sent to the display. We are having some speed problems due to the ack packets causing unneeded interrupts and it would be nice to be able to disable them.

I would also like to thank you for the excellent support we have gotten so far on this project

Crystalfontz Rocks

Crystalfontz LCD Blog

Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

 

[wyofreeride]

I also have another question. I am using the flash on the display
to save the audio levels and other settings so they can be maintained after the power is turned off. When I send the Write User Flash command, I may have to send it more than once to have it succesfully save. Is this a known bug or is there something special I need to do to use this.

I have tried it with both my software and the crystal control software with the same results

 

[CF Tech]

There is not a way to disable the acknowledges.

What processor are you using that 19200 baud is killing it? The only things that need to happen quickly in the ISR are reading the UART and stuffing that data into a circular buffer. Everything else can happen in the foreground at a low priority as cycles are available.

I do not know of any troubles with the flash routine. Can you duplicate the trouble with 633_WinTest?

The two issues may be related. The 633's packet protocol requires that you wait for an acknowledge before issuing the next command. Now most of the time you can get away with hammering the heck out of the 633 with commands one on top of another and ignoring acknowledges, because most commands are dispatched very quickly by the 633. The write to flash takes longer though. If you wait for its acknowledge, you will be fine since the acknowledge is not sent until the flash write is complete. But if you send another command quickly you are breaking the protocol and could be disrupting the flash write.

As a quick work-around, try putting a 500mS delay after the flash write command.