Mill Electrotrickery Part 1 - Stepping out with Arduino

Gallery, Projects and General > Project Logs

<< < (2/7) > >>

RodW:
I have worked out what the menu structure should look like for this project and decided to order an SD card reader for the Arduino. It cost all of $13.00

If I can get it to play nicely with the display, it will allow programs to be created in a text editor on a computer and read from the SD card by the Arduino. I may also deal with device profiles too.

If it works out, the SD card will substantially simplify the coding required to support the more advanced features proposed.

I'll work on the menus and input routines while waiting for the hardware to arrive.

RodW:
Well the SD card arrived last night but I have not played with it yet. I have been working on some code for menus and string entry. I have been doing this on a PC using Visual Studio so it will need to be reworked slightly for the Arduino string display. So I have a reworking menu dispatcher now as well a procedure to get a number and select a string from a list. To enter a number you use left and right arrows to select different digits (skipping any decimal point) and the up and down arrows increment or decrement the digit. The string selector works by using the left and right arrows to move up and down the list of strings supplied and refreshes the display. I will add an alpha numeric string data entry routine and then I think the next step will be to work on displaying multiple data entry field on a single screen and navigating between.

I will say it has been years since I have done much in C and I have found I have forgotten so much so it has been taking a long time to relearn how to code what I envisioned. I have spent hours tinkering with stucture definitions until I finally got stuff compiling without errors or warnings! :bang:

RodW:
I soldered the SD card controller board onto a Protyping shield andmanaged to get the demo programs compiling. I have given the SD card a bit of a workout and it is all good. There is a trick using the SDfat library. I followed the pinouts on the SD card web site and put Chip select on Pin 4 but SDFat wanted it on pin 10. Once I sorted this out, it was pretty easy to read and write t the card and I even formatted it!. Nothing much to look at, but here is the protoshield I soldered up with the SD card good to go.

This is the SD card that bought but m still waiting for the stepper drive board to arrive
http://www.dfrobot.com/index.php?route=product/product&filter_name=sd%20card&product_id=875#.UZivFbVmh8E

RodW:
Well, I have finally got some working menus to show off. You would not believe how many hours have gone into programming to get this far.

First, I had to remember a fair bit about C, then I had to develop a class to manage the keyboard and then integrate that with a buggy Menu system that mostly does what I want.

I have also got an SD card sandwiched between the screen and the Arduino which will explain why some of the menus exist.

Note at the end of the video, where I am talking about a motor controller, it will go on my mill power feed, not on the Rotary table.

The program started to behave erratically before I had finished building the menus which is a sure sign I had run out of RAM. On closer investigation, the third party Menu library was creating duplicate strings of all of the menu options so we were using twice as much RAM as we needed to. Given the Arduino only has 2k of RAM space for storing variables, this was a serious problem. I might add that had the menu developer bothered to use any error checking which could have easily alerted me of the memory overflow. Anyway, I moved all of the menu descriptions to a static string array and this saved the day. This also let me reuse strings which trimmed the memory usage down quite a bit and the code is a few K slimmer now.

Anyway, hopefully it won't take long to develop the field input routines and screen navigation stuff and I can start coding the stuff that really matters.

But at this point the backbone of the program exists as each menu option is calling a stub procedure so once I get going, all I have to do is progressively work my way through the code that talks to the attached hardware.

kwackers:
Not sure if you realise this but if you don't declare your strings 'const' then they'll sit in ROM and be copied to RAM when the your program starts.
The reason for this is that a string that isn't declared const is presumed to be modifiable and thus would need copying...

I don't play with arduino's that much so haven't seen the menu system you speak of but I'd expect the functions to take const string pointers.

I'd be inclined to write my own menu's. Most 'systems' are over complex for the sort of stuff you need on LCD's and can invoke a fair bit of overhead.
In the code for the rotary table Chris linked to above there are just two functions.
The first is an init routine which simply prints the new screen.
The second is the handler which reads the keyboard and executes a switch statement to call the appropriate function(s).

Due to the lack of stack depth the menu system is non-hierarchical and simply consists of a variable with the current state which each loop through the main code simply 'switches' to the correct menu handler. Changing menus is then a simple task of calling init with the new state, this calls the appropriate print routine to draw the new screen and sets the new menu state. Subsequent loops through main will then call the appropriate handler.

It's slightly more hard wired than a 'system' could be but imo it's quicker and easier to knock stuff up with, particularly if you need to leave the beaten track. I did originally consider writing a more complex system that could automate various animation and data entry fields but I felt they'd exist just to show how clever the system was rather than making things easier.

Navigation

 Message Index

Go to full version