Menu System for Liquid Dispenser

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

Freaks,

Although i'm only 15, my knowlege of micros has led me to be "contracted" by my dad's friend who owns a checmical company. They are extreamly adept at using analogue circuits to create liquid dispensers, etc. but wish to use a micro for a complex project.

Basically the system should have a 4x4 industial button matrix scanned by BASCOM. Each button will have several functions (text, numerical and mode) that are selected by the current device operation (some sections will require text, while others will need numbers, etc). I can't disclose the device's main functions, but I need to ask a question.

What is the best way to set up a menu system on the 16x2 LCD? It should have several functions that are selected with the left/right keys and entered with the "Enter" key. This is easy, but each function in the menu also has several sub-functions.

I was thinking to use a seperate subroutine for each menu that has a controller loop, looking for appropriate keypresses. This would add more complexity to the device's program, but I can't think of any other way.

Does anyone know of an easier method to implement a complex menu structure, using the smallest amount of memory possible? I need most of the flash memory for EEPROM accessing routines, and the liquid type ml/sec calculations which are extreamly complex.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Hello,

Which AVR are you using? I wouldn't worry too much about space to be honest - when you are using floating point there will generally just be a one-time space hit as it links in the floating point libraries. After that you just have to be sure you don't use up are your SRAM - so don't have lots of floats declared at once ;-)

I haven't used BASOM-AVR in a while so I can't remember exactly what it can do, but something like this would work:

Have an array of strings that is displayed on the LCD. Then you have a counter that will count up or down for each button press (left/right). This counter variable is used to index the array, so the proper text is displayed.

Then when enter is pressed you can do a case (does BASCOM have case?) statement or a if...elsif..elsif..endif on that variable. At that point you do have a choice - you could either just call a subroutine for the new submenu, or make another case statement for the submenu. The new subroutine method would be easiest to maintain IMHO. And the code space is going to be about the same anyway.

If you don't want to do the subroutine thing - you basically repeat what I just said (about counter, etc). However instead of using the first array - you have a new array that has all the submenu choices. However I would think this would get ugly fast!

If you use C there is more elegant ways to do this, but I don't really think they are applicable to BASOM-AVR. But as I say it might have added some new features from when the last time I've used it - I'll try to take a look at it to see what it's got.

Regards and good luck,

-Colin

PS: When writing code it is often better to first write it the way you think it "should be". Don't worry about optimization - let the compiler fret about that. If you find that you are totally out of space then go and change it, as in a year when the company calls you back to make a change you don't want to look at your code and go "wtf was I thinking!?".

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

what i did was determine the button that was pressed inside the interrupt sub-routine and set/clear some bits (which defines the state of the program). so it is basically a nested IF-THEN statements of clearing and setting bits and let the main program manage where the program should go from there.

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

Freaks,

For the record, BASCOM DOES have a case statement. Anyway, the reply first posted was what I was expecting - I was originally going to make one like that, as it was my first idea. Unforturatly, space is tight (i'm using a 90S8535) because I also need to include:

Keypad handling routines
LCD routines
I2C Routines
Simple FAT-like system for EEPROM data storage
Extrapolation routines for data retrived from the I2C EEPROM

Amognst others. As a result, I need to use minimum space for the menu.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

As this is a limited run job ie a one off; do not mess about with a small micro go for the biggest one around the mega 128.
This removes any code size restrictions you may have.

If there is any winging on cost( make them pay for any dev kit you need); tell then to take a hike. What you are being asked to do would run up a bill of several thousand dollars in the real world, they are just after cheap labour so make them pay do not undervalue your work.
Oh, and you might want to ask who gets kicked if it goes wrong, and get in on paper.

Keep it simple it will not bite as hard

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

Freaks,

We want to use the 8535 because we are going to use the Investment Technologies' board called the "ABCmini" because it will enable us to create the devices the fastest.

I am very good friends with Jim Gamelis (my dad's friend who wants my help) and so have no qualms with doing the work - he's going to pay me at the end but I don't expect more than $100, mainly because the project will teach me about the development cycle of a commercial product.

The company is quite successfull but DEFINETLY not large - it consists of only two warehouses and less than 20 employees so money cannot be thrown around, nor can they afford to pay another company to mass produce the boards (units are assembled by Jim & employees) so the fact that most of the micro circuitry is on-board sinmplifies the design.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

To add to this, the device IS for commercial sale - i.e. it will be produced in quantity and sold to other companies.

- Dean

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Hi Dean,

Developing a product always seems to take much more time than one ever
thinks it will, plus ongoing support is usually needed as improvements
are made and new features thought of. Fifteen is not to young to approach
this as a "real" business proposition. I have no problem with doing design
essentially for free, when the payoff is a piece of every unit sold. That
often amounts to far more than what you can get by just charging for the
design. Twenty employees is not a real big company, but it is certainly
big enough to properly compensate the efforts of a young designer helping
to make that company, and its employees, successful! As others have said,
do not sell yourself short. At fifteen, the money you bank now can grow to pretty
impressive amounts as you move through adulthood. Ask your dad about
"The Rule of 76".

Good luck!

Tom Pappano
Tulsa, Oklahoma

Tom Pappano
Tulsa, Oklahoma

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

Freaks,

Can we just forget the reason and focus on the actual question? No offence, but i'm doing this because I want to, and have lots of free time. I cam to ask a question, not request business information.

So can anyone reply with a proper answer to the original question?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

A menu tree built on case statements still seems the way to go. It is the way I
do it for systems large to very small. Write the app as cleanly and efficiently as
possible, and it will either fit in 8k or it won't. Sometimes the application must
dictate the componenst to use, instead of forcing the application into what is
handy 8-)

Tom Pappano
Tulsa, Oklahoma

Tom Pappano
Tulsa, Oklahoma

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

tpappano wrote:
A menu tree built on case statements still seems the way to go. It is the way I
do it for systems large to very small. Write the app as cleanly and efficiently as
possible, and it will either fit in 8k or it won't. Sometimes the application must
dictate the componenst to use, instead of forcing the application into what is
handy 8-)

Tom Pappano
Tulsa, Oklahoma


I agree with this. You can spend ages trying to devise a structure, for example, to define menu entries, only to hit a situation that doesn't quite fit. Write it all as switch(x) and case: statements or whatever your basic equivalent is. When youv'e got it all working as you want it to, you can think about something more elegant. I always find that I need to start writing code first. Then the solutions start to occur to me.
Good luck.

Four legs good, two legs bad, three legs stable.

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

Have you considered storing the menu strings in an external EEPROM to save space?

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

Good idea, although i'll probably use the internal EEPROM for the menu system, and an external large I2C EEPROM for the temp/viscosity data.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Sounds like a great project, Dean.

Just a thought, but have you looked at the code for the Butterfly? It's a menuing system and even though the navigation is through a joystick of sorts, it might be pretty close to what you want to do?

Please note - this post may not present all information available on a subject.

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

Hey Dean,

I think you might also be able to use a generic structure for the menu. However, you will have to think about how deep the maximum sub-menu level wil get. You then need variables to store:

the current sub menu level
chosen branch out of main menu.
chosen branch out of sub menu
chosen branch out of sub sub menu

Then you can use thes variables to choose which menu string to show and which action to take when an option is selected. The menu structure is then autonomous and the options are mapped. You can store an array of pointers to the functions, which you can address by the menu choices. Don't know if It's the best way to do it. Personally I would prefer it because you can separate the menu code from the actual application.

I have to warn you. Personally I still have nightmares of the smaller AVRs. Your memory is quite limited and overruns are not reported. They will just end up in very "funny behaviour". I think you don't have to keep from take a "bigger one" for unit prince or development costs. There is probably a an AVR which will also fit your demo board and has more memory. IIRC it could be ATMEGA16.

In my humble opinion what you are trying to create is quite a lot and will be a huge challenge even for an experienced developer.
Some more memory can really save your day.

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

Thanks for the input. I wanted to use the ABCmini (board with 8535, power supply, serial chip, etc) because it would minimise the extra circuitry required, since the company isn't exactly huge...

Anyway, can anyone direct me to a company that can supply a board with a larger AVR micro on board (speed not important), with optional serial chip (not nesesary for the project) and power supply? Basically it just needs the chip, regulator and crystal. The price for boards (each) should be $50 or under, for a bulk price of 10-20 units.

If not, I'll probably just order the chip without board as the serial and extras are not needed. It just needs a minimum of 25 I/O's, and lots of FLASH and EEPROM.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Hi,

see https://www.avrfreaks.net/Tools/j... for some development boards. See http://www.bdmicro.com/ for the MAVRIC-II, which sounds like just what the doctor ordered.

Quote:
FEATURES: Atmel ATmega128 MCU • 128K Program FLASH, 4K Static RAM, 4K EEPROM • dual level shifted UARTs • RS485 on-board • I2C ready w/pull-up resistors installed • up to 53 digital I/O pins • Selectable clock frequency of 16 MHz or 14.7456 MHz (select at order time) • Advanced, low drow-out voltage regulator on-board accepts 5.5-15V input with reverse polarity hookup protection • Small size at 2.2 x 3.6 inches

The price might be a bit higher though - the website doesn't talk about discounts for larger orders though. It is $85 with normal pin headers in quantity 1. It might even be too powerful, as the Mega128 probably will end up being somewhat wasted!

However - you can buy just the bare PCB. Then you could mount only the required parts, to save some cost there.

Regards,

-Colin

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

Very nice, how much are the MEGA128's in a DIL package? Also, what's with the odd-ball low clock frequency?

Anyway, ultimatly I'll need to discuss it with Jim to see what he wants. For now though, i'll design and write the program's main sections (menu system last) and then go from there - if it doesn't fit, it doesn't fit, THEN we'll use larger micros.

Thanks, for the help,
- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Quote:

what's with the odd-ball low clock frequency?

Have a look at the baud rate register.

Keep it simple it will not bite as hard

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

abcminiuser wrote:
Very nice, how much are the MEGA128's in a DIL package?

Well, it isn't ;-) The MEGA128 is not available in a DIL package, sadly...

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

WHAT?!?! :shock: Why on earth would Atmel NOT produce the chip in a DIL package??? Is the smaller MEGA chips avaliable in a DIL package?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

It's pretty simple:
1. There's virtually no market for it
2. It has too many pins

Mark

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

Hi,

gizmo said:

Quote:

2. It has too many pins

Didn't Hitachi make a 64 pin "shrink DIP" for their HD64180 (or something like that re: part number)?

Of course I realize that was in the dark ages before SMT was big :)

Sorry gizmo, just picking on you...in fun of course :D I know that you are correct.

Regards,
Steve

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

All of the chips with 40 pins or below have a DIL package. Anything over 40 won't. At least with Atmel.

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

Peoples,

The project has been cancelled because of chinease units already avaliable for a fraction of the cost that we could use, but i'd like to keep the discussion going.

Can anyone think of any other way for a LCD menu system?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Hi,

BTW as a side-note: SMD devices are actually not that hard to work with. I found you can solder them almost as easily as DIP, and for prototype there is the STK501.

Regards,

-Colin