Page 1 of 1

menu user module

Posted: Fri Apr 06, 2007 1:45 pm
by rocketbob
Hi All, I'm a noob with Swordfish and am working on my first SF project, which is a rewrite of a project I wrote in assembler for an 18F. Without getting into all the details I built a thermocouple datalogger that incorporated a pushbutton rotary encoder and a 44780 display. The menu subroutines I wrote were not as flexible as I would like them to be so as part of of the SF rewrite I would like to come up with a display menu user module that would be generic and reusable. I'm thinking about/looking for some ideas on how I should best approach this task, and am wondering if anyone here has already done something like this.

BTW I will add that I've fallen in love with SF. I've done projects with MPASM, CCS, C30...and so far working with SF I can say that my productivity has skyrocketed. Everything about the IDE, the language, the libraries, and the documentation is nicely laid out and easy to use, and has been a pleasure to learn. I'm looking forward to getting started with the GLCD modules.

Regards,
Bob

Posted: Fri Apr 06, 2007 2:10 pm
by TimB
I wrote a number of Menu'ing routines in another compiler in the long past.

So when I started working with SF the ability to replicate the routines was high on my list of "intrigation" topics I gave Dave to how it would be able to handle them.

Basically it comes down to how compact the data tables have to be. The ultra compact tables system is where you use offset data lookup tables as you will see used in the font tables.

The other method is just to use constant arrays with the menu options as an element of the array. Unless you have may 10's of menu options it's not worth the effort of off set lookup's.

I see it just a call to a Function that will return the menu option selected. In my other version I do stuff like have timeouts that return with the no option values should they fail to make a selection of play with the menu option within a set period.

I will see if I can knock up a small demo later.

Dave though is a superb programmer and may have a take on it also.

Any more info on details. Display type , input etc?

Posted: Fri Apr 06, 2007 2:56 pm
by rocketbob
The way I've done it previously was I had a counter that I incremented/decremented through my rotary encoder code, and when I hit my drawscreen subroutine in my main loop, I just looked at the value of the counter to determine which screen to draw. Pretty simple.

But to answer your question Tim, the display is a character display and the rotary encoder cycles through the different displays. The pushbutton was to be used to navigate to submenus and set values or do things but I never got that far.

My thought is to make the module display-independent...

Regards,
Bob

Posted: Fri Apr 06, 2007 5:17 pm
by TimB
If your trying to make it display independent you have to account for a number different display sizes of the display's. Also you have to have a universal system for the input.

Personally I would adopt a bespoke system until you get to grips with what's needed. Make one for each then see what can be made universal, but by then you have bespoke ones and you might not bother.

Posted: Mon Apr 09, 2007 12:31 pm
by rocketbob
Tim, I found a wonderful article on the subject from a 2003 issue of Circuit Cellar... doesn't look like the forum here allows attachments, otherwise I'd post it.

Regards,
Bob

Posted: Mon Apr 09, 2007 2:34 pm
by TimB
I for one would be very pleased to look at that.

I have Pm'ed you with my mail address would appreciate if you could mail me it.

Posted: Tue Apr 10, 2007 2:07 am
by xor
Same here (if you don't mind).

a year (or more) later - could i get a copy too of article

Posted: Tue Jan 15, 2008 6:57 pm
by rachel33
i am new to all this and trying to work out a general display menu system

Posted: Tue Jan 15, 2008 8:38 pm
by johngb
There is an underlying issue with Swordfish for any table driven application (which is where I see generalised menus sitting). The issue is that you cannot place pointers in constant arrays so you cannot reference strings or other constant data from another constant constant array.

Personally, I have now given up trying to do anything generic like this until Dave chooses to extend the compiler to support such features. I cannot even see an easy way to do this in assembler as SF does not support the ORG function so it is not possible to manage linked tables in assembler. Dave knows of the issues but I am not expecting any likely resolution in the foreseeable future.

It's a shame but I have to say that Proton is a lot more flexible in this area than Swordfish.

Posted: Wed Jan 16, 2008 12:06 am
by octal
Hi John,
you can actually do whatever you want using tables to make table driven menus. I personnaly see no problem with SF as it is now. You just have to rework the way you think to menus and their driven nature. If you relay on automaton like data table (state machines) you'll be able to do whatever you want without the need for any pointer !

I'll try to post an example of a system I personnaly used with Swordfish Basic next days. I just hope to find a bit of free time !

Regards
octal

Posted: Thu Jan 17, 2008 1:47 pm
by johngb
For menus in Proton I use a state machine currently and a set of tables which define the contents of the menu, the images (and each images position) and/or text which should be displayed for an any particular menu item and the action which should be taken when a particular menu item is selected. All this requires the ability to insert the address of (for example a Bit map or a text string). I.e. pointers to code memory.

The disadvantage with Proton is that it does not support Array Constants which makes addressing the data a bit easier, however, this is a minor difficulty as opposed to Swordfish's limitation of not being able to place the address of an item in a table in memory.

Posted: Thu Jan 17, 2008 8:07 pm
by octal
Hi John,
I understand your frustration ... maybe I'm so optimist, but if you re-think again the way you implemented your state machines, you'll see that it's not that difficult to do that in SF ... ;) I'll make something this weekend and send it to you (and post it here when the WIKI will be alive again).

Regards
octal