AVR Freaks

It is my observation too that user interface code is the most biggest part of a project that takes a lot to think, a lot time to implement and a lot of available resources.

Can you post some code to look at?

- Jani

I've been following this post and now I have a question. I don't want to change the focus of this post, so you can pm me if you know the answer.

Although I'm not new at working with AVR's, I'm new at anything involving a UI. I don't understand how a font library like this could help. If you're storing 8bit characters or using an 8bit pointer in the place of the character, how are you saving room?

Thanks,
Nathan

Also do you use floating point (float, double) variables anywhere? That will also bump up the flash usage by a largish amount.

And I assume that you have a 20x4 LCD display, and you seem to be storing full 20 character lines. If there are lot of spaces, it would be beneficial to store only the part of the string that is needed, not just arrays of 20 characters for every line. So basically this means that if you have things like linetext[20] in some struct or array of menus, you have a char* which points to the actual null-terminated string somewhere in flash. This way short strings like "Hello" would take 6 bytes instead of 20 bytes, plus the pointer to flash, 2 bytes.

Can you post an example menu building routine (change the texts if you like)?

- Jani

I seem to forget the LZW patent has expired - I would have said it can't be used because of the patent.

Anyway, if you need compression, real difference between Huffman and LZW is that you can build the dictionary on the fly with LZW while with Huffman you need to store the dictionary separately. LZW might also be a bit easier to implement, as it can be done in one pass, while best results with Huffman is first to analyze the data for building the best dictionary and then doing the actual encoding.

As we are compressing ASCII text which has 7-bit codes, you could have 8-bit dictionary only. I think LZW in GIF images had 12 bit dictionary. See how it works out. If you need some special symbols with MSB on, you could make remapping tables to map those to unused 7-bit characters and back.

- Jani

Interesting, that is like a text based script language which the menu engine parses and executes.

You could shave off a few bytes if some of that stuff was in binary, i.e. bytecode instead of text. Like instead of "st01" which takes four bytes, you could use escape codes to insert hex or decimal numbers. Like "st" would be replaced with one byte, say 0x80, and the "01" would be another byte, 0x01, etc..

It would be most irritating to insert/concatenate both single character escape codes and text strings, I have not yet found a reasonable way to do it, if the escape codes are first #defined to be something like 0x80 or \x80. Preprocessor won't replace stuff inside quotes, and in C, I don't know a good way to build/concatenate stuff like I have done in x86 asm or pascal languages:

So any way to combine good sides of both C ways? Maybe with string building macros, which builds the string and finally quotes it?

- Jani

Edit:

Ah forget it, it was not the OPs code - sorry I was not paying attention.

While at it, I solved my string problems. The C compiler concatenates string literals by itself, so basically the following things are equal: