Show Posts
Pages: [1] 2
1  Development / Other Software Development / New library: arduino-fsm on: December 24, 2013, 12:10:32 pm
I've created a new arduino library called arduino-fsm for implementing a finite state machine1. It's similar to this library2; however, the user triggers a transition by sending an event, allowing the client to remove the need for complex switch statements in their code. This is really an implementation of the State design pattern, using callbacks instead of inheritence.

The code is available on github:

See the example code for a guide on using it. I'll follow up with a blog post soon. It's worth noting the following callbacks:

* on_enter (when a state is entered)
* on_exit (when a state is exited)
* on_transition (when transitioning from one state to another)

Each callback is optional.

Questions? Post here. Clear bugs? See the github issue tracker.

2  Development / Other Software Development / Re: New Arduino library: MenuSystem on: December 20, 2013, 07:18:42 am
UPDATE: version 1.0.1 released

I've released a new version (1.0.1) of the menusystem library, which is now called arduino-menusystem. This update includes a fix for the buffer overflow mention in this thread, which also means that there is no longer a limit of five items per Menu - they are now dynamically allocated, so you can have as many as your arduino can support in it's little memory.

As the name has changed, so has the github link:

NOTE: The arduino IDE has a hissy-fit when loading the library because the project now has a dash in its name. You can rename it locally without it being a problem, just remove the dash. I have no idea why the arduino IDE cares about this, but I'm not changing the name smiley

As much as I wanted to I couldn't find a generic way to implement a setup menu item. My first thoughts were right on this. I've been writing a clock using an LED matrix, and I solved this by using the menu to change a global variable called "current_mode". Depending on the mode, different things are displayed on the screen and the buttons do different things. When in a mode for setting the display brightness, the buttons change the value of another global variable. I hope this helps.
3  Development / Other Software Development / Re: New Arduino library: MenuSystem on: December 16, 2013, 02:50:50 pm
I'll take a look at your proposal this coming weekend (I'm pretty busy during the week).

My first thoughts are:

1. MenuSystem::increase() and descrease() don't really make sense. The menu system must not be aware of the current menu item, so the interface must stay generic. You can always use next, prev, select, and back, for example. increase and decrease only make sense for the SetupItem;
2. Moving the callback to the constructor and merging the add_item and add_menu functions seems like a good idea; I think you've highlighted a bug in the missing buffer overrun check too;
3. Whatever happens when a menu item is selected must take place in select() or the callback to maintain the generic interface;
4. ToggleMenuItem feels like something that can be used. It's easy to store a boolean, the constructor has a param specifying the default value and it can easily be flipped in select() and passed in the call to the callback (although this would mean a different callback signature...maybe that's bad...need to think about it);
5. A ValueMenuItem therefore has the problem that you can never communicate how the value changes through the MenuSystem interface, and I doubt there is a generic way to do that.

Anyway...I'm warming up to the idea of "other menu items" so when I take a look at the weekend, maybe I will have an "aha!" moment.

Also, I don't take offence to your comments, I welcome them smiley
4  Development / Other Software Development / Re: New Arduino library: MenuSystem on: December 16, 2013, 10:44:30 am
Let me see if I understand.

You're adding a 'SetupItem' to the menu in order to use the menusystem interface to change values? The example I can think of is a menu item for setting a clock format to be 12 hour or 24 hour.

If my understanding is right, I don't think 'SetupItem' is needed. The handler for an arbitrary 'MenuItem' can perform the required action. The benefit of the 'SetupItem' is that it stores the setting value automatically, but this is also a downside - it results in the menusystem also being responsible for settings.

I'm also reluctant to add more classes. The arduino doesn't have a huge amount of memory, and generic libraries should be small so more of that memory can be used by the client application.

The interface change in your example also isn't ideal: it would break existing code. That said, I think the 'MenuItem' might be better off if the handler function pointer was passed in the constructor.

Anyway, I don't want to demoralise you. Perhaps I've misunderstood and there is a good use case for this. I've not convinced myself completely that this is a bad idea (Right now I'm thinking of a 'ToggleMenuItem' that when toggled sends the new value to the callback function...but I'm also wondering if a Settings library should really handle this...hmmm).
5  Development / Other Software Development / Re: New Arduino library: MenuSystem on: December 15, 2013, 10:04:13 am
menusystem 1.0.0 has been released. See github for more information. This is the first release to have a version number, so it doesn't mean much at the moment. Also, I couldn't test this on an arduino because I've lost my usb cable....oops. It compiles fine, so hopefully all is well smiley

I've merged in your pull-request. What you wrote here in the forum was different to the pull request. I changed the pull request to match what you have here, but also making the default behaviour the same as always (return to the root menu).

I've merged in your examples as well. I renamed the files to match the format of the existing ones. A small thing, I know smiley.

As for your other question, I'm not sure I understand completely what you're trying to achieve. Your handler should be called directly when you select a menu item, so you shouldn't need to store what was selected. What is your use case for tracking the menu selection outside of the library (by returning the id)?
6  Development / Other Software Development / Re: New Arduino library: MenuSystem on: December 02, 2013, 01:37:32 am
Looks good. I'll merge this in sometime this week. Thanks again for the contribution smiley

I had made a new example so that the user can navigate the menu over serial comands. The idea is to make easy to understand how to control the menu. I'll make a pull request of this example, but meanwhile you can found it here
7  Development / Other Software Development / Re: New Arduino library: MenuSystem on: October 28, 2013, 04:57:44 am
Thanks! I'm going away on holiday for a few weeks soon. I'll try and take a look before then, otherwise I'll handle it when I get back. It's nice that a solution is available in the meantime if people need it.
8  Development / Other Software Development / Re: New Arduino library: MenuSystem on: October 26, 2013, 02:43:28 pm
Apologies for those who left messages addressed to me. I didn't have notifications turned on, so have missed them.

I'm not sure because it's been a while since I've done any arduino development. My first thought is that the library isn't in the correct folder, but the error message is odd since "menu system" is written with a space in it. Did you make a typo by any chance?

There are examples included with the library, have you tried those out?

You posted way, way back in March. I'm very sorry. Hopefully you've found an answer by now. If not, please raise an issue on github and I'll take a look. Why do I need a github issue? I'm away for a few weeks, and I tend to be active on github a lot, so when I return I will be reminded.

9  Development / Other Software Development / Re: New Arduino library: MenuSystem on: May 25, 2012, 01:15:04 pm
arcachofo, I had a look at the two options: it was fun. smiley

I was leaning towards my option, because I really wanted to prevent the user from doing something stupid like:

Menu* current_menu = ms.get_current_menu();

My idea was too hard to implement in a clean and tidy way (because arduino doesn't support new and delete). So I went back to your idea and the answer came to me:

Menu const* get_current_menu() const;

Yup! The function returns a pointer to a const. I made a lot of functions do the same, so if users try silly things, it won't work without them being extra silly and const_casting.

So, you'll be pleased to know that I've applied a slightly modified version of your idea and uploaded it to github. I've also included some examples. Thanks for the idea! Enjoy!
10  Development / Other Software Development / Re: New Arduino library: MenuSystem on: May 25, 2012, 12:55:31 am
Ok, this is a safer and easier (for the user) way to do it.

The only little disadvantage i see if i understand correctly is that MenuSystem has to iterate through items to create the array, and then the user has to iterate again through array to print names, what is little slower, but... all have a price.

Another cuestion: Why do you pass a pointer to MenuItem in the callback funtion?

Thinking about this library.. it could be used for anything that needs a tree structure, noy only a menu system.

I pass a pointer to the menu item to the callback so it knows what invoked it.

You're right about the double iteration. Still, optimising early is generally considered a bad idea. That said, I'm not totally against you're approach. I will try them both out smiley

Finally, you're right again, this could be used for any tree structure. That is the intent of the composite design pattern. I wouldn't use this library for anything other than a menu system though.
11  Development / Other Software Development / Re: New Arduino library: MenuSystem on: May 24, 2012, 06:57:02 am
Looks interesting. I'll test it and see if it fits well with the original design. It's nice that you can display multiple items and show the highlighted one, what I don't like is having to iterate over the menu components outside of the library - those should stay internal.

Perhaps a function in the menu system like so would be better:

char** MenuSystem::get_current_menu_options();

This will return an array of the menu options for the current menu. What do you think?

Not sure if this is possible without doing changes, but i needed another function in MesuSystem class:


I see more ineresting have getter: MenuSystem::get_current_menu() intead of MenuSystem::get_current_menu_name(), with the first i can access to anything i need in the current menu, not only name.

12  Development / Other Software Development / Re: New Arduino library: MenuSystem on: May 24, 2012, 06:45:07 am
Not entirely sure how this is relevant to the MenuSystem I've created. Looks to me like a shameless plug!

When I developed my menu class, I faced two difficulties: displaying the menu and defining the options.

A menu is declared this way:
// menu declaration and size
item myMenuItems[] = {
  {     0x0000, "Menu 0"        }  ,   
  {     0x1000, "Item 1"        }  ,
  {     0x1100, "Item 11"       }  ,
  {     0x1200, "Item 12"       }  ,
  {     0x2000, "Item 2"        }  ,
  {     0x2100, "Item 21"       }  ,
  {     0x2110, "Item 211"      }  ,
  {     0x2120, "Item 212"      }  ,
  {     0x2121, "Item 2121"     }  ,
  {     0x2122, "Item 2122"     }  ,
  {     0x2200, "Item 22"       }  ,
  {     0x2300, "Item 23"       }  ,
  {     0x3000, "Item 3"        }

Learn more about the menu and the Serial_LCD library suite  smiley
13  Using Arduino / Sensors / Re: Led matrix brightness changes temperature sensor reading on: May 24, 2012, 05:52:26 am
I'm don't understand fully what you mean, but you're spot on. I moved the temp. sensor ground away from the same ground as the led matrix and no more fluctuations. I also moved a thin speaker as well as I noticed it was actually buzzing ever so slightly (barely audible). Thank-you very much.

Does this mean that nothing should share a ground pin, or is the LED matrix an exception?
Also, I'm not an electronics engineer, but my first thought is: can't I just stick a diode between the temp. sensor ground and shared ground pin?

What's most likely to be happening is that the current flowing round the LED matrix circuit is at some point flowing along some of the GND wiring.  The high currents mean that the finite resistance of the wiring develops a small voltage across it, a few 10's of mV.

The ADC that is measuring your temperature sensor is seeing a ground potential that is lower than the ground potential of the actual LM35/TMP35 sensor.

So this could be because you've wired it all up on a breadboard and there is one ground wire returning to the Arduino from the breadboard carrying the LED current?

Make sure the Sensor ground is not connected to the LED ground, but is routed only to a GND pin on the Arduino.

Try to ensure that the current from the LED array doesn't share that pin - and better still doesn't even reach the Arduino but comes straight from the power source (not really possible if USB though).
14  Using Arduino / Sensors / Led matrix brightness changes temperature sensor reading on: May 23, 2012, 02:11:01 pm
I have a sure electronics 16x32 led matrix wired up to an Arduino Uno, along with a LM35/TMP35 temperature sensor.

The temperature reading seems correct, or is at least close to correct, and quite stable. As I turn the brightness up on the LED matrix, however, the temperature reading starts fluctuating. At the lowest brightness it's steady at around 26 degrees. Put the brightness up to about 50%, and the reading is now flipping between 26 and 28 degrees. When the brightness is as far as it can go, the reading is then flipping between 27 and 32 degrees; the higher the brightness, the less it sticks to a single temperature.

What could be causing this?
15  Development / Other Software Development / Re: New Arduino library: MenuSystem on: May 22, 2012, 03:08:27 pm
So this means, I need to write a procedure which renders the menu on an output device. This procedure also has to take care to highlight the "current" menu item, correct?

Thanks for clarification,

Yes, you need to render the menu to a device. Bear in mind that this library manages which item is current for you, and that is the only item you should display. This means that you can only show one option on your output device at a time. If you want to display all menu items and highlight the current one, this library isn't for you. I've written some pseudo-code below to explain this, I hope it makes sense:

def process_input():
  if next_button_pressed:
  else if prev_button_pressed:
  else if select_button_pressed:
  else if back_button_pressed:

def update_menu():
  current_item_text = menusystem.get_current_menu_name()

def loop():
Pages: [1] 2