Go Down

Topic: Modular Stackable Microcontroller System (lots of pics) (Read 19642 times) previous topic - next topic


Yes, size issues. How about scrolling text area instead of relying on the size of the screen?

Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter


Dont get me wrong, scrolling is very cool and has its uses, however if you have this on a machine and need lots of readouts on the screen and your hands are busy operating the machine, then you dont want to have to scroll down to see something - ideally.

But yes, a scrolling menu will be useful for alot of things.


Having multiple smaller screens could be an option I suppose, if a RS485 backpack was made for each one - so one serial port can service multiple screens.

In my system I2C isnt really suitable for LCD's as I2C is already tied up doing the backbone. SPI is used for the Ethernet so not really ideal either unless there was a dedicated LCD board, but then all values to put onto the screen would need to be sent from the main processor board over i2c to the display board, which isnt ideal either.

Alot of cases 1 screen will be plenty though.


Just FYI, here is a link to an old post of mine showing the large digits I made in that library.


Agreed. I do have scrolling menu/list with many rendering options :)

You can run two 40X2 displays or 2 20X4 displays with one arduino, just use different EN lines and make two lcd objects.

RE: number, nice and big! Here's my version, not only numbers are large, so are all other characters including letters and symbols :)



Again same set of lcd functions are required.
Serial LCD keypad panel,phi_prompt user interface library,SDI-12 USB Adapter


Nice - yeah I didnt get up to making characters large, only did the numbers.
Normal sized numbers are both characters and numbers, it takes char*, int, long, float etc. Large versions only support int and long at this stage.

It is all on the cards to finish, I just havent gotten around to it yet.
The library was just proof of concept.


Had some more time to play with this, and have managed to implement the EEPROM addressing system.

Each module after its initial program download, will be given the address of 119, which is the last I2C address that is not in the 'reserved' range.
By attaching each module one by one to a powered processor board, and the processor board being in an 'Addressing Mode', which is just a function of code I have written, each new module attached will be checked if it is address 119, and if so assign it a new number starting from 1. This number is then stored in EEPROM so the next startup it knows its address by loading the EEPROM etc.

If for some reason the configuration is needing to be changed, starting another mode in the Processor will clear all addresses on the modules by way of a broadcast to Address 0. Each module will therefore be changed to address 119, and the EEPROM address is cleared. This is an undesirable state as there will be many modules with the same address. At this stage, the only way to correct it is to unplug each module, start the Addressing Mode again and plug them in 1 by 1, and they will be reassigned an address.

If anyone has any other ideas for doing this, I am all ears.

I have tested the above with a range of different modules connected, and now have a configuration which works reliably and repeatibly.

Thanks to Nick Gammon for the broadcasting method from his website, worked a treat.



May 21, 2011, 03:07 pm Last Edit: May 21, 2011, 03:09 pm by Graynomad Reason: 1
starting another mode in the Processor will clear all addresses on the modules by way of a broadcast to Address 0.

If you only want to reset one board pull all the others before you broadcast this.

OR (and better)

You'll have some form of monitor running on the main processor I assume, so you can see what boards are there etc. And you already have code to get a board to change from 119 to N, can't you just get it to change from N to 119 and do this as a command in the monitor.

Rob Gray aka the GRAYnomad www.robgray.com


Yeah true
I could make another command which does a single change of an address, and leave the broadcast for if I need to clear all the boards.
Will do that now.

Had the worst night sleep :( Party over the road playing 'doof doof' music till 4am.


If you give every CPU board a serial number (in EEPROM) then you can just make a protocol where you broadcast something like "board X change your I2C address to Y).

There should be no reason to ever change serial numbers (just keep allocating them) and that way you can reconfigure a board without having to take it out of the stack.

Again, setting the serial number initially can just be done by a small sketch which is uploaded before the main sketch is uploaded.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics


You are full of great ideas Nick :)
That is a very cool idea.


May 22, 2011, 02:14 am Last Edit: May 22, 2011, 02:23 am by WanaGo Reason: 1
I suppose then I could implement the 'Scanner' to not only see who is there, but to return the serial numbers and type of the boards which are there, so I can figure out who is allocated what address.

Another step I suppose would be to make each board a master of some sort for initial startup, and for them to scan who else is on the bus too, and allocate themselves the next free address so they never start up with an address that is already taken, and therefore I should never need to unplug. The Processor Board could be the normal master, but also a slave with address 1.
This may not achieve anything more than just having the Serial Number approach and the master allocating addresses...

I will put some thought into this.



I'm not sure about the multiple masters. There is an I2C protocol for resolving multiple attempts to take control of the bus, but it could get messy. I'm inclined for simplicity to have the "main CPU" (which I think you said you had) to take on that role, and do the querying. But I agree that in addition to finding out serial numbers you could find out device types (and firmware versions, too, huh?).

I can't recall if you brought out the programming pins for each processor, but I can see that you probably need an easy way to update them without pulling the stack apart.
Please post technical questions on the forum, not by personal message. Thanks!

More info: http://www.gammon.com.au/electronics


Yep I'd stick with a single master.

On my modules I have them report all sorts of "vendor" info such as serial #, SW and HW revision, revision for the system the board is tested for, plain English name for the board, full vendor name, abbreviated vendor hame, unique board type number so a plug in diagnostic device can know exactly what the board should do etc. 

I suppose you will only have one "vendor" so don't need lots of that but I'd certainly add revision numbers etc. If you make lots of these you'll quickly lose track of what's what.

Rob Gray aka the GRAYnomad www.robgray.com


Thanks guys.

I have just written some crude code and now the master can do the scan of the bus and each slave reports back its address, its serial number and some information. At this stage is all very loose, but the information is 20 characters of information, such as "Opto Input - Rev 01".

I just started with that too see how it would be transfered over I2C etc.

In my slaves I have onReceive and onRequest interrupts, and all that appears to work fine.

So the Master has the following modes:
The ability to auto assign addresses as the modules are plugged in 1 by 1.
The ability to clear addresses from all modules and assign them to 119.
The ability to specify a specific serial number and assign it to a specific address.
The ability to interigate the bus, and receive back each modules information (Address, Serial and Information).

All these appear to work correctly.

I have only implemented this on 1 module so far, so will copy and paste in the bits to the rest now.

Go Up