LCD Menu: Which is a better approach regarding code size?

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

I have a question. I'm building up an UI for an LCD with ~6 submenus.
Now, at the beginning of the design I have a question:

I have two different approach:
1. I handle the buttons (up,down,ok,esc) in one function (the state machine). For example. When button down is pressed, the row is calculated and given to the correct submenu function which will prepare the data for the LCD.

2. The state machine just gives the button to the correct submenu function and in that function everything (like row change and so on) is calculated and than the data is prepared.

My thinking is, that the first approach will result in less code size, but is it really a good idea to use that approach or will it be to much calculation in the state machine?

I hope my question is understandable
:lol:

Regards,
Baldrian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Suck it and see! How can you have too much calculation in the state machine? If the calcs need to be done, they need to be done somewhere - be it in the state machine or elsewhere.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Suck it and see! How can you have too much calculation in the state machine? If the calcs need to be done, they need to be done somewhere - be it in the state machine or elsewhere.

thanks for your answer, but what about code size? I can imaging that the first approach will use less space, but I'm not really sure.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1. You are using a Mega, so code size will probably be irrelevant
2. Use the method that is simplest for you.
3. You can always see first and suck later.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
1. You are using a Mega, so code size will probably be irrelevant
2. Use the method that is simplest for you.
3. You can always see first and suck later.

David.

It seems, that even with an Atmega, at the end, code size will be a matter. LCD Menu with >15 different languages is only a small part of it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can quite see that 15 languages can eat up flash memory. But the basic algorithm will be trivial in code space or difference. You will have the same amount of text strings.

I would suggest a table approach, but this is purely because of the housekeeping involved with different languages.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
I can quite see that 15 languages can eat up flash memory. But the basic algorithm will be trivial in code space or difference. You will have the same amount of text strings.

I would suggest a table approach, but this is purely because of the housekeeping involved with different languages.

David.

You are right. I didn't see it from that point of view. Along with all the language strings, the menu algorithm is just a tiny little memory space, so it doesn't matter which approach I will use.
Thanks a lot :D