Thank you MikeyBoo great to get some info from industry, seems i'm best using something like the RS232 converter chips like Phil says and only going 2m seems i hope i will be fine, if i manage 9600 baud then great, i don't understand Baud rate other than it being a transmission speed, like can you work out how long a byte will take to be sent etc?
In practice, I think it's always misused to mean bit rate: I've never heard it used in any context other than 'the simplest digital communication links', i.e. serial comms.Wikipedia said:
But are you sure it was RS232 and not 20mA current-loop ?
. The results were hilarious - with the VDU/Printer or whatever switched off, the now floating line picked up all the interference possible and played havoc with the poor VAX at the other end of the link ...
Each of the inputs from the 'Masters' is a Picaxe output, so you'll need (at least) a diode mixer to multiplex the signals together. Inverted serial (i.e. normally LOW), with a single resistor to GND should do the trick. This is to protect the Picaxe outputs, should two of them transmit at the same time.
I don't see any issues at the Masters end, as each Master will have its own RS232 max3232, but at the slave display end not sure if the 3x RS232's will be connected together before the convertor (max3232) then after the convertor its just tx and rx, of if i have 3x max3232 with the TTL side linked together?
Note: the MAX232 datasheet show that the TTL/CMOS inputs are pulled-UP weakly via 400K and RS-232 inputs are pulled DOWN by 5K (the 4.7K resistor in my previous tale!)
Phil
I think that would only work for a TTL link - not RS-232, with its ± voltages...
Yes i expected that and its fine, i have ordered 2x max3232's and the caps that the data sheet speaks about for the input voltage
After reading this multiple times, the diagram will fit at the output of the 3x MAX3232's and mix the signals to the HSERIN, which diodes you thinking, something like 1N4148 signal diodes?
Ignore me - finger's going faster than brain
Yes. (and I think virtually any diode will do.)
The conventional wisdom is to put a 1K resistor in series - I always forgot though (with no ill effects ... yet).
Thinking further - it needs to be low enough to produce a logic "1", in the absence of any input "0"s, so it probably does need to be 470R, or thereabouts.
Phil thank you, yep i had seen that, i will draw up how i see the connections before i start, its still confusing me, remembering tx to rx and rx to tx etc etc
Yes, ancient, full RS232 using shielded cables with 25 pin connectors to terminals and printers all over the building.
Normally one would use some mechanism so a sender can request sole access to the bus, detect it is able to send, then release the bus when done. That's usually done by using three wires.
The best way to do unknown projects is to prototype them. Start with the simplest, see how it goes, then extend once it's working or to make it work. There often isn't an 'off-the-shelf, will work for you' solution so it has to be found.
Only one background serial receive is available. SERIN is blocking, so if you issue a SERIN on one pin, until you time out or receive what you're looking for, anything sent on another pin will be lost. You may need to set up a call-and-response regime. For instance, your slaves could even be M2s with 2-byte serial background buffers (or 20X2s with 128 bytes). You send an address byte (HSEROUT pin can be disabled, then you can use any pin for SEROUT) that indicates: "anything for me?"; then responder sends NACK or whatever it has. After NACK or timeout or response is processed, you move to the next slave.
So looks like I'm maybe better having my display picaxe being the master and the 3x other all being slaves, so the master can ask each slave in turn for data? And have that done in a loop basis?
As per post #126
:-As an alternative, you could use interrupts...
serin using a timeout and a qualifier. serin is posted (I used Linefeed, because it came in handy for display on my debug device). There (probably) still needs to be a delay - to give the Master time to respond - before the qualifier and data is sent.
That would seem the best way to do it with all slave outputs being diode mixed to a single serial input on the master display unit.
There is, however, a potential issue, in that the 'slaves' are the ones doing time-sensitive work AIUI. They are going to have be 'interrupted', either literally or figuratively, if the Master polls them.
As far as the slaves are concerned its data logging, further down the road so to speak, i want the master to stop the clock when a fault is received from any of the slaves and note the time, after which when the fault has cleared the master will restart the clock at the correct time again
I think it should toll one of the church bells
as well, to bring the villagers running There's a way of catching events, without actually using an interrupt for them - in the shape of the Interrupt-on-change FLAGS. This might simplify the logic used in the slaves. (@Hippy posted some demo code for using them - but I can't find it
)Perhaps because it got attached (post #3) to another thread.There's a way of catching events, without actually using an interrupt for them - in the shape of the Interrupt-on-change FLAGS. This might simplify the logic used in the slaves. (Hippy posted some demo code for using them - but I can't find it
That's not the one I was looking for ... but it's pertinent.Perhaps because it got attached (post #3) to another thread.
Phil yes that was what i was thinking also by
Seems the more involved the project the more the care needed in selecting the picaxe to start with, not just a case of have i got enough pins, more the need of a deep knowledge of what each picaxe can do
I didn't want to overload the project by saying everything i wanted from it, as Hippy says best to build a project with success's, but seems for this one would have been best to said all requirments at the start?Interestingly, the IOC flags (and interrupts in general) are available on ALL of the I/O pins of the 08M2, but on a more restricted range (perhaps only port B) on the other M2s (and apparently even fewer on the X2s). Also the "mapping" of the port pins on the 14M2 and 20M2 makes the SFR pin calculations a little tricky.
So diode mixing all autodrives to the display, mixing being done after the RS232 convertor i assume, with the display have a RS232 convertor for each slave?
"Call and respond" should solve this. Presumably you're in a tight loop (no PAUSEs in the main loop--all timing done by other means)--you're likely to be able to query each slave several times a second (and perhaps usually receive a NACK if nothing has changed). If you need instantaneous response (e.g., to hitting an end stop), you can use interrupts.
Ibenson, i tend to be using loops and counters for time function rather than pauses, the ability to query once a second would be plenty, the fault conditions i am trying to get from the slaves won't matter to a second, most of the responces will be nothing has changed, not sure if there is any advantage of reading the voltage at the slave, could be the only thing that would alter slightly
The Picaxe Manual documents
SETINT restrictions (for the M2's) :-| 08M2 | only inputs C.1 to C.4 may be used |
| 14M2 | only inputs C.0, C.1 and C.2 may be used |
| 18M2 | only inputs C.0, C.1, C.2 and C.4 to C.7 may be used |
| 20M2 | only inputs C.1 to C.5 may be used |
I know, but in many cases, needing to know that something happened, is not the same as needing to respond to it immediately. (User presses switch, while program is waiting for a DS18B20 ... that sort of scenario).
IMHO that is a gross over-simplification (probably intended for novices) but it depends very much on your definition of "Work". Processing "data" can be fine (maybe even essential), so my "rule" (recommendation) would be that the ISR should (almost) NEVER use a PAUSE , and/or "Waiting" loops (e.g. DO : LOOP UNTIL <pin> ) except with great caution.
That is indeed unfortunate but it's part of the silicon design which we have no control over. I have never understood why Microchip would support inversion on output but not on input.. I don't think anyone else has figured out their reasoning either.
HSERSETUP Bbaud_mhz, %rtb
|||
||`--- Background receive
|`---- Tx polarity : 0=T, 1=N
`------Rx polarity : 0=T, 1=N
T = Traditional UART idle high
N = Normal RS232 idle low .-------------.--------------.--------.------.
| HSERIN T/N | HSEROUT T/N | Rx Buf | %rtb |
.------|-------------|--------------|--------|------|
| 08M2 | C.1 T | C.0 SO T/N | 2 | %0t0 | -.
| 14M2 | B.1 T | B.0 SO T/N | 2 | %0t0 | -'
| 18M2 | B.2 T | B.5 T/N | 2 | %0t0 |
| 20M2 | B.6 T | C.0 T/N | 2 | %0t0 | -.
|------|-------------|--------------|--------|------| |
| 20X2 | B.6 T/N | C.0 T/N | 128 | %rtb | -'
| 28X2 | C.7 T/N | C.6 T/N | 1024 | %rtb |
| 40X2 | C.7 T/N | C.6 T/N | 1024 | %rtb |
`------^-------------^--------------^--------^------' |
|
These have HSERIN/HSEROUT pins in the same |--'
position relative to the top of the chip |As an ex-IC designer, I suspect that it was just a "mistake". Either they "forgot" to include the XOR gate, or more likely the design that they implemented didn't work correctly (so they "corrected" the data sheet, rather than the Hardware).
However, it can be "fixed" with just a single external transistor (bipolar or FET) on the 08M2, or by using the internal DSM or a comparator (and a few "spare" pins) on the larger M2s.
I was thinking in terms of caveats, that the firmware may switch things back to its desired defaults. I am sure I ran into that with some interface but cannot recall which. Trying to turn 18X inputs to outputs failed because of that, though the outputs could be made inputs.