multiple serial inputs to one LCD

[springer]

how can i multiplex the serial out's from 4*8M's to display in turn on a serial lcd display.

The Problem... I've got 4 * PC type fans, each a different size and airflow. all are 3 wire (power and tacho). I want to use differing sizes of fans to understand the ratio of airflow to noise to speed etc.

4 identical 8m's are to be used to pwm control these fans, dependant on temperature read from a ds18b20 or thermistor on each 8m channel.
The temp measurement, fan speed, and tacho signal stuff is mostly done and quite simple, but I've no idea how to read 4 serial channels in turn.

all suggestions welcome

Thanks...

 

[SilentScreamer]

Easy way that I can think of is to have another 08M, connect each 08M to a different input then you still have an output to play with.

 

[hippy]

You can probably diode mix all the 08M's outputs into the single LCD receive line ( how depends on if using Nxxxx or Txxxx baud rates ) and the only thing you need then is to ensure that only one PICAXE communicates at a time or LCD data will get garbled.

This can be done by using another PICAXE as an arbitrator; a PICAXE asks for access to the bus the arbitrator grants one access until it has finished. That requires a larger PICAXE with an I/O line for each requester and another I/O to acknowledge.

SilentScreamer's solution also works but you will need to synchronise the PICAXE's so they don't talk over each other as the 'funnelling PICAXE' can only listen to one at a time. With a DS18B20 taking in the order of 750ms to get an update if they do start clashing there may be long periods where one doesn't get a look-in to do updates.

Alternatively ( using diode mixing for the serial ), each PICAXE can link to the next and indicate, "I've done my display update, now you do yours". That is probably what I would use. It also has the advantage that fan control PICAXE's can fairly easily be added or removed. That needs each PICAXE to have an I/O input to see when it should update the LCD and an I/O output to tell the next PICAXE to do its update.

All PICAXE's would run the same program program. In this example pin 3 is the input from previous PICAXE, pin 4 the signal to the next ...

b0 = 0
Do
ReadTemp ...
Gosub SetPwmAsRequiredEtc
Do : Loop While b0 = pin3 ' Wait for signal to transmit to LCD
b0 = pin3
Gosub UpdateLcd
Toggle 4 ' Tell next PICAXE to update LCD
Loop

One PICAXE would have slightly different code to initialise the LCD and display any fixed text or 'splash screen' at the start of the code and the initial 'b0=0" would be "b0=1" for that one .

 

[BeanieBots]

If each PICAXE outputs some text that identifies itself within the display,
eg "Sens1 = ..." then the other PICAXEs could use the "Sens1" part to identify who was the last to "speak" by using a preamble on serin.
It would of course 'lockup' unless all PICAXEs were connected and working.
Just a thought.

 

[manie]

The easiest way for me to understand and execute such a system would be have a 28x1(ample I/O pins) to call the other Picaxes to "do it's thing", be it temperature read/report or whatever. The other Axe would only execute it's function when told to do so by the master 28x1. This could easily go via a diode mixer circuit and clashes can be prevented. Just the way I understand it.

 

[inglewoodpete]

If an input pin is available on each 08M, it could be used with interrupts and a software timer for each 08M to manage their serial transmissions.

Hardware
The LCD serial in line will need a pullup resistor (say 4.7k) and each 08M would connect it's serial output line to this via a diode (cathode to 08M). This creates a serial 'or' function (like 'open collector'). You will need this to mix the serial streams anyway.

The new 'sense' pin on each 08M connects to the LCD's serial in line via a (say 4.7k) resistor. Ie 4 resistors

A second input pin (if available) could be used with a resistor divider and ADC input to provide device ID, making the software in each 08M standard. There should be enough I/O pins on an 08M to do this, unless you are doing additional things.

Software
Each 08M would normally have interrupts enabled on its sense pin. A timer byte would be set to a value > 0 whenever an interrupt occurred. This byte would be decremented to zero in the program's main loop.

Each 08M would only transmit serial when its timer byte was zero. To ensure that the sending 08M did not interrupt itself, it would disable its own interrupts while sending.

Finally, to avoid serial data collisions, each 08M's timer initialisation value would have to differ from the other 08Ms so that 2 or more chips do not send at once. This could be done by multiplying the timeout period by the chip ID. Eg standard delay period for 08M #1 = 1 * 20mS; 08M #2 = 20mS * 2; 08M #3 = 20mS * 3 etc

Conclusion
Total additional cost: 4 resistors and coding time.

 

[hippy]

The problem with self-timed interrupts, even with staggered periods, is that there will be some clock drift from the internal oscillators so they will likely end up being synchronised and accessing the LCD at the same time at some point.

A single master PICAXE, using slave 08M's only as PWM generators, could handle all DS18B20's and marshall the data to the display and update the slave 08M's but would need to use OWIN/OWOUT commands to parallel up temperature reads or accept sequential READTEMP's taking around three seconds.

There are a number of ways to configure a system like this, each having their own advantages and disadvantages.

 

[inglewoodpete]

hippy, I think you have misunderstood my concept.

A self-timed count of a few seconds is not going to be troubled by drift, unless it is greater then 50% out (for 4 PICAXEs). The counter/timer will only run for a few 10s of milliseconds after serial activity from other 08Ms is detected.

No need for a complicated hierachy or multiple layers of chips (unless you're trying to market them - which I don't think is your motive here).

 

[hippy]

Yes, I misunderstood. Monitoring the serial comms gives the necessary synchronisation and cuts down on the 'handshaking' lines. Good solution.

That could be further extended so the same line is used for SEROUT and as a monitoring input ( no diodes, just pull-up/pull-down, low value R in series on each line ).

 

[BeanieBots]

Do you mean something along the lines of post #4?

 

[inglewoodpete]

hippy, good idea in using just 1 pin for serial output and sensing.

BB, there is no need for any chip to monitor and identify another's serial; is that what you suggested in post #4? Any 08M only needs to know that the LCD serial line is busy, with a small added timeout period to prevent collisions.

 

[BeanieBots]

My concept was that each 08M could use serin to identify 'who' had spoken last and then send accordingly, but you are right, just monitor the line for activity and wait a set period (different for each 08m) before sending.
Although, unless all are started at the same time, it could get confused.

 

[inglewoodpete]

Although, unless all are started at the same time, it could get confused.

They would be better off if they didn't all start at the same time: that way would give a more random 'first in' and less likely to clash on the first serial transmission.

The solution would be to also have differing delays at bootup to ensure they are not running in parallel/sync. Actually, 1 of the 08Ms would have to initialise the LCD anyway.

 

[BeanieBots]

Sorry, but I don't see how that can avoid a potential clash or hogging.
Can you explain in more detail? Maybe a timing sequence.

 

[hippy]

The easiest is for every PICAXE ( assuming four ) to wait until it has seen three sets of transmissions then it knows it has its turn to talk. A bit like going round a table with four people having a conversation with their eyes closed. After three people have spoken it's your turn again.

Initialising is the key here. At start-up each has to wait a different number of transmissions before going into the 'every fourth turn' mode. PICAXE #1 doesn't wait, clears display puts up initial text etc, PICAXE #2 waits for one transmission ( that from #1 ) then transmits, PICAXE #3 waits for two ( #1 and #2 ), PICAXE #4 waits for three ( #1, #2 and #3 ).

Or you could have a different delay time at startup so the number of transmission is guaranteed to have passed, but as one has to count transmissions later it makes sense to use the same technique at start-up.

Each PICAXE does need to be programmed differently or has to take its number from external connection; a voltage divider and READADC can do that or a couple of input pins.

 

[inglewoodpete]

Back from my dinner [insert smilie licking its lips].

Each 08M, DS18B20 temp sensor and fan driver would be a separate unit. Apart from regular interrupts occurring due to serial from other 08Ms, the only interraction between them would revolve around sharing the LCD.

Since the LCD is to be read by a humans, you would not want it to be updated too often, otherwise it would be unreadable. So the outputs from the 08Ms would need to be periodic.

Each 08M would have interrupts enabled on their serial lead, so that when any one output some serial, the others would get interrupts caused by the toggling serial data.

The interrupts would initialise a variable which acts as a simple decrementing loop counter. The data stream would cause a number of interrupts, each setting the timer byte. The timer byte, while non-zero would prevent serial transmissions.

The main loop of the 08M's programme decrements the counter to zero. Once the timer/counter reaches zero, the 08M is allowed to send serial if it needs to. In sending serial, it would cause interrupts in the other 08Ms, blocking their serial for a period.

Edit: hippy has come up with a different solution while I was away.

 

[hippy]

BeanieBots post #4 will also work and would be simpler. It relies upon the previous having sent some unique code, pausing a while to allow transmission to complete, then sending its own unique code and transmission. Each PICAXE waits until who should have spoken previously has spoken.

That 'unique code' could be the LCD character positioning command if one didn't want extraneous data on the display eg ...

Do
Serin TX_PIN, BAUD, (254, posPrevious )
Pause 100
Serout TX_PIN, BAUD, ( 254, posSelf, #b0 )
Input TX_PIN
ReadTemp ...
PwmOut ...
Loop

 

[inglewoodpete]

springer said in his original (and only) post:

all suggestions welcome

Thanks...

Well he's got a few to sort through. The poor guy is probably hiding under his bed

 

[springer]

not hiding, just resting.....
thanks for all the suggestions, I've considered them all.
I'll probably opt for a master 20M or 28x1 as a polling arbitrator. (i'm better at hardware than software!)
then all the 8M's can have identical code, and i can add more as required.
that way i can also have a set of switches (one per sensor) near the LCD panel for 'on demand' reading of that sensor.

ps. but then it doesn't really matter, as its only an experiment in temp control and serial mux'ing

Once again thanks for all the reply's.....

 

[lanternfish]

Something that I successfully used was the idea of each 08M having a unique identifier and ring cascading them. In my application updating was not critical so the the first 08M read its pins, sent identifier and data to second. It then sampled, sent it's identifier, plus previous 08M identifier and data. And so on ... For your application, the final 08M could process it's own data, output to serial LCD, and triggering first 08M. Starting the whole cycle again.

i have found this system excellent in non-timw critical apps.

 

[inglewoodpete]

springer wrote:

I'll probably opt for a master 20M or 28x1 as a polling arbitrator. (i'm better at hardware than software!)
then all the 8M's can have identical code, and i can add more as required.

While good for PICAXE sales, this will require the complete development of 2 pieces of software.
My design has identical software in all 4 08Ms. Each 08M would have a different resistor in a voltage divider, which is read to give it its unique address.

that way i can also have a set of switches (one per sensor) near the LCD panel for 'on demand' reading of that sensor.

Surely, each 08M could write to its 'part' of the LCD every couple of seconds. Eg Sensor 1: Top Left; Sensor 2: Top Right etc. Why the need for 'demand' switching?

Only you know what you want but your proposed solution seems to be quite complicated in both a hardware and software context.

 

[BeanieBots]

@inglewoodpete

its only an experiment in temp control and serial mux'ing

The 28X1 could do it all on its own plus some.

 

[springer]

i didn't think that any of the picaxe chips couls support more than 2 (hwpwm and pwm) on a single chip.

 

[BeanieBots]

You are quite right. Only 2 background PWM outputs.
I was more concerned with the serial aspects and lost sight of the PWM aspect. However, I'm quite sure it could be done all in one 28X1 with little or no compromise on fan speed control using code driven PWM.
But that's another issue.