Use a separate command for writing flash

[andrewcharnley]

Having a multi coloured display is a real bonus, I can use it to indicate errors and the like.

But if I flash/change colours a few times that's a couple writes to EPROM, and the 100,000 count will eventually be used up. It also slows the whole system down by locking the CPU while it writes.

Solution is to remove the auto-save and map it to a character in the 0x0 to 0x20 region, or add it to the command options.

[nseidle]

I'm hesitant to implement mapping directly to the 0x0-0x19 non-visible region. Many users attach SerLCD to a serial stream that may include all sorts of garbage characters. They could quickly bork their display is the system settings are mapped to non-vis characters.

FWIW, flash is a lot more resilient than quoted. Checkout Flash Thrasher.

We could add an option to disable auto-saving of screen color to flash but disabling the current auto-record structure would break a lot of existing user code.

We could map a variety of commands to the 0x0 to 0x19 region. 0x20 is space char. We'd need to have a special system command to enable these 'direct' commands so they aren't enabled by default (to avoid the garbage serial stream issue mentioned above). Do you have a proposed command map? Here's my first take. We'll have to create a setting in the library to enable writing of direct commands (off by default) so users who have <v2.0 LCD firmware still have a functioning library.

This is quickly growing in complexity for little added value.

[fourstix]

Ugh. Personally, I hate adding all these unusual command codes one can accidentally trip over. The ASCII control characters have well-defined meanings, and do often appear in text streams.

I'd recommend a two character sequence, using Escape (0x1B) or one of the Device Control 1-4 (0x11 to 0x14) characters followed by a command character for a particular command. That's less error-prone and fits into the ASCII model better than redefining several control codes to mean something other than their conventional descriptions.

From the spreadsheet, it looks like you are defining TAB (0x09) to be a command character. That would be bad.

[andrewcharnley]

Fourstix -> It's not bad if the HD controller doesn't support it, which it doesn't. If you're expecting to not read the documentation and send the display crap that's your problem, it absolutely should not mean sacrificing performance for the wider audience.

If they are sending garbage over serial there is the same chance that they send say 0x03 or the '|' command character, so I don't see the difference. '|' is a printable character so it shouldn't be used for the command. Make the whole thing a none critical issue by only writing to flash with a particular sequence , i.e four specific bytes. Another reason for not writing the flash every time is interrupt servicing is turned off and because the simple Atmega only has a single buffer it may not be quick enough to catch the next incoming byte (I2C etc).

If compatibility is important may I suggest a command which switches it into v2 mode, then duplicate everything (assuming there is the memory).

Little added value -> well there's currently not a single character based LCD that can handle DMA transactions with the nice features which this display has (specifically the background colours). It will be the go to model for more advanced users.

Only the 8 custom characters need mapping into the 0x0 to 0x19 region, plus the command character. I'd then extend my framebuffer by 20 bytes and it would be enough to handle commands for changing colour and the like. I agree with fourstix it makes sense to use a pattern to enter command mode if you are concerned about crap being sent over the wire. No problem doing that.

Don't forget to increase the Arduino''s inadequate circular buffer. ;)

[andrewcharnley]

Also to put it into context why DMA is important, on the AtMega2560 arduino with the same display + i2c backpack the delays inherent to the HD controller meant the ADC would read at 25Hz. Using the NRF52 with DMA to the Sparkfun screen I'm able to hit 50KHz.

[fourstix]

I would be the first to agree that the Pipe (|) character was an unfortunate choice as the command escape character. (Personally, I would chose ESC 0x1B that is what the ASCII spec specifies. But Pipe has a rather dubious history as an escape character in old data streams, and that's probably why it was used.)

But re-defining more ASCII control codes would just make a bad situation worse. After all, it is reasonable to expect a serial device to respond to an ASCII text stream according to spec. And the ASCII characters 0x00 to 0x7F have all had well defined meanings since 1967. (One might use a character above 0x7F in the "Extended Ascii" range as a control character, without causing many problems, but then someone in Europe or Japan will stumble on it.)

Maybe what we really need as a feature is the ability to switch the display to use another character as the command control character. Then you could chose your character and and I could have mine. Also this would be backwards compatible with the previous versions.

PS. The buffer in Wire is just a 32 char array. You are giving way to much credit by thinking they use a circular buffer. ;-)