Drive 1 LCD with multiple PICAXE's?

[dmaxben]

Sorry if this is a stupid question...I tried searching but the closest topic/search-result I could find was the "opposite" question (which was "drive multiple LCD's with one PICAXE").

I just started playing around with LCD's for the first time today...I basically made my own "AXE133" with a breadboard, 8x2 LCD, and an extra 18m2 (to drive the parallel LCD) I had. I started with the AXE133 code and now I can get the 18m2 to initialize the LCD and display a welcome message. Very cool!!! Im completely new to microcontrollers and programming in general so I was pretty ecstatic when I flipped the switch and saw ASCII text come up on the LCD.

I still have yet to try hooking up a second "Master" PICAXE to send serial (ASCII) data to the 18m2 slave/LCD driver.

However, it got me wondering...is it possible to have multiple PICAXE "co-processors" send serial data to the single display driver? Maybe put a diode on each of the serial-out pins on each Picaxe so when one Picaxe co-processor sends serial data to the LCD driver, it doesnt "backfeed" into the second Picaxe co-processor.

For example, say I have two Picaxes ("widget A" and "widget B") each doing their own thing/performing their own separate functions. Then the third Picaxe (the AXE133) simply listens to the serial-input and drives the single 8-bit-parallel-LCD. 99% of the time, "Widget A" is sending miscellaneous ASCII text to the LCD...but every once in a while, I want to have "Widget A" shut-up for a couple seconds while "Widget B" sends a line of text to the LCD for a couple seconds...then after that, "Widget B" goes back to doing its own "non-LCD-oriented" thing and "Widget A" goes back to its normal job of sending text to the LCD.....

Does that make sense, what I am trying to do? As long as I make sure that the two Picaxe's are not trying to send serial data to the LCD at the same time (and isolate each serial output so one Picaxe doesnt try to backfeed into the other output), will it work?

thanks,
Ben

 

[nick12ab]

If you are only going to be using two PICAXEs to control the AXE133 PICAXE, then one I/O line per PICAXE is used to connect the two together and then the one that uses the LCD the most has to grant the other PICAXE (the one that uses it less) permission to use the LCD which is connected to both PICAXEs through diodes or an OR gate. The PICAXE which uses the LCD the most simply makes its output line high when the other PICAXE can safely send data.

 

[srnet]

As long as I make sure that the two Picaxe's are not trying to send serial data to the LCD at the same time

Electrically multiple transmitters feeding into a single serial reciever is not a big problem.

So how do you detect or make sure that two devices do not transmit at the same time and corrupt the display ?

The general solution to this is well known (look up how Ethernet works, binary exponential backoff etc) but how to implement the same collison detection and avoidance between multiple PICAXEs ?

 

[g6ejd]

You could run two programmes in parallel in one picaxe e.g. 18m2 then the two processes listen to each others status through a shared byte to decide who's currently transmitting data to the display and when finished hand control over to the other process

 

[westaust55]

A forum search can help you find the answer to many questions already exists.

The two PICAXE to one LCD has been discussed before.
Have a read of this thread: http://www.picaxeforum.co.uk/showthread.php?15883-Two-Picaxe-to-one-LCD

 

[mrburnette]

FROM AXE134Y.bas
symbol spare0 = C.0 ; spare output 0
symbol spare1 = C.1 ; spare output 1
symbol spare2 = C.2 ; spare output 2 (or optional backlight)

It appears that up to 7 senders can be supported by using the 3 spare lines as address lines for senders (address x0 would be idle. ) ,.. add a little code to the 18M2 to generate sequential addresses 0-7 and only send when the specific address is valid... the receiver can then control the polling duration, etc.

- Ray

 

[mrburnette]

A forum search can help you find the answer to many questions already exists.

The two PICAXE to one LCD has been discussed before.
Have a read of this thread: http://www.picaxeforum.co.uk/showthread.php?15883-Two-Picaxe-to-one-LCD

Sometimes rehashing provides new insight. I did not think the previous answer was all that creative or expandable. There is tremendous code space in the 18M2 that can provide a more flexible solution for RevEd LCD & OLED displays.

 

[dmaxben]

A forum search can help you find the answer to many questions already exists.

The two PICAXE to one LCD has been discussed before.
Have a read of this thread: http://www.picaxeforum.co.uk/showthread.php?15883-Two-Picaxe-to-one-LCD

Ahh I feel stupid now...I searched for a while, but I was using phrases like "multiple PICAXE LCD" and "several PICAXE LCD" and "several PICAXE's one LCD"....stupidly it seems like the ONE variation of the search phrase I did NOT try would have resulted in me finding that thread. Honestly though, I did try to search first rather than the lazy/knee-jerk reaction of posting a new thread without even looking.

 

[dmaxben]

You could run two programmes in parallel in one picaxe e.g. 18m2 then the two processes listen to each others status through a shared byte to decide who's currently transmitting data to the display and when finished hand control over to the other process

The problem with this though is the real-world "jobs" that I need the picaxe to perform require more inputs than there are pins available. I want to use the M2 chips because of the native/hardware support for a DAC, and the M2 chips are cheaper than the bigger 28/40 pin X2 chips. So, for example, "widget A" requires using all of the available I/O's (of a 20M2). Which is why I needed to have the separate "widget B" (running on an 08M2 or 14M2) in the first place. Also, "widget A" has some PWM stuff, which, if I remember correctly, gets goofed a slight bit if you try to run multiple programs at once on an M2 (while doing PWM), because the M2's dont have a true hardware PWM setup...or maybe Im wrong?

 

[dmaxben]

FROM AXE134Y.bas
symbol spare0 = C.0 ; spare output 0
symbol spare1 = C.1 ; spare output 1
symbol spare2 = C.2 ; spare output 2 (or optional backlight)

It appears that up to 7 senders can be supported by using the 3 spare lines as address lines for senders (address x0 would be idle. ) ,.. add a little code to the 18M2 to generate sequential addresses 0-7 and only send when the specific address is valid... the receiver can then control the polling duration, etc.

- Ray

Hmmm this is a very interesting idea!! So you are saying use one of the extra 18M2 LCD-driver outputs as a serial-out that broadcasts a "go/no-go for sending serial data to the one LCD" message to ALL of the other Picaxe's at once....then each of the other Picaxe's simply listens to the serial out from the 18M2 LCD-driver and only broadcasts a serial-out to the LCD when its own address is called? Although im a bit confused as to how that would work, because the 18M2 LCD driver would not know when it should listen to which particular PICAXE??

Or do you mean that the 18M2 LCD-driver would constantly listen for a serial-in message from ANY of the external PICAXE's, and then as soon as one of the PICAXE's starts sending it serial data, the 18M2 LCD-driver would OUTPUT a serial message to all of the external PICAXE's that basically says "ok now everyone shut up except for Widget-B, then when Widget-B is done speaking, then Ill send all you guys another message saying that the data bus is 'open/free' again for anyone else to start sending a message". Am I correct in that understanding of it? Like I said, I pretty much taught myself Picaxe's/BASIC just by trial and error...I have no advanced programming background so it would probably be tricky [for me; but easy for someone who knows programming] to code all of that and set it up 'easily' (meaning, set it up without taking months of stupid trial-and-error).

Either way though, definitely a cool idea...thats actually the way the common "Class-2/J-1850 Variable Pulse Width" data bus works in the GM trucks/SUV's...all of the ~15+ modules in the vehicle (radio, amplifier, window motors, climate control, onstar, XM satellite radio tuner, Engine control module, etc) have a common single-wire (and common ground) data line...(theoretically any module can talk to any other module, the engine computer could talk to the driver side window motor, but in reality it would never have to/never does) When a module wants to send a signal (say the driver turned the volume knob on the radio, so the radio has to send a data message to the amplifier in order to actually make the music/speakers louder), FIRST the radio 'listens' on the bus to see if anyone else is talking, AND it listens to the message's priority level...if another module is already busy talking (say the Engine computer is in the middle of telling the doors to lock because the vehicle starts going over 15mph) AND has a higher priority level written into that message, the radio waits for the engine control module to finish sending its "higher priority" message, then once the bus is confirmed "quiet/clear" again, the radio then assembles the actual message it wants to send ("Hey, amplifier, increase volume level 2 notches!"), then it assigns a "priority level" (IE, a message broadcast from the airbag computer is going to be more important than turning up the radio volume) and broadcasts it to ALL of the modules in the truck....but only the amplifier "picks up the phone and listens" because thats what the address header says.

Only with my Picaxe Widgets and LCD-driver here, its going to be a little less complex then that!

Ben

 

[geoff07]

This is very similar to the problem of receiving several temperature readings from remotes and multiplexing them into one master device. My solar controller in the projects section does this. The mechanism is quite simple: several 08ms each send a serial signal with a temperature reading. The input lines are diode multiplexed onto one pin, which has interrupt and serial receive capability. When the pin interrupts, the master immediately reads the serial stream that follows on the same pin. Any corruption caused by clashes is simply ignored. The senders repeat their message every few seconds at, in this example, prime number intervals of 2, 3, 5, 7 seconds (to reduce the clashing). In practice, at 4800 baud and with a short packet, the number of clashes is around 2-3%.

 

[hippy]

FROM AXE134Y.bas
symbol spare0 = C.0 ; spare output 0
symbol spare1 = C.1 ; spare output 1
symbol spare2 = C.2 ; spare output 2 (or optional backlight)

As the AXE133Y driver can be completely reworked it would be possible to use those pins as inputs or outputs and have each sending PICAXE tell the AXE133Y that it wants to send and wait for an acknowledgement to do so. The request to send could also be used as the serial data transfer line so it would be a two wire solution for each sending PICAXE, something like ...

SendData:
High TX
Do : Loop Until OKAY_TO_PROCEED = 1
Low TX
SerOut TX, N2400, ( 254, $80, "Line 1 Text", 255 )
Do : Loop Until OKAY_TO_PROCEED = 0
Return

The 255 for the modified firmware being a 'finished' flag so the AXE133Y then goes and looks for who is sending next.

That should be quite simple to add to the AXE133Y driver.