Inaccuracy with background serial receive on 20X2

amdunn

New Member
Something rather odd with background serial receive on a 20X2.

I'm driving the HSERIN pin (aka B.6) from the output of a 74F00 logic gate, that itself receives the serial signal from an opto-isolator.

If I connect the gate output directly to HSERIN, then I get wildly inaccurate serial reads - it seems to mis-read 10% to 40% of the received characters.

If I put a 4.7K resistor between the gate and HSERIN, the accuracy greatly improves to pretty much 100%.

I can't find any logical reason why I'd need to do this, but it really does influence the read accuracy. I stumbled upon it by accident (accidentally connected the gate through the same resistor circuit - 22K and 10K to ground - normally used with a direct PC serial connection when I didn't mean to, but noticed that the inaccuracy disappeared when I did this; then I progressively whittled it down to the single 4.7K resistor).

Why would this be so?
 

inglewoodpete

Senior Member
I found that with data rates up to 76800 baud, the 20X2's background data reception was reliable. It could occasionally drop a character at 115200 baud. Note that optoisolators can distort pulses at fast date rates.

Edit: As you've mentioned, the 10k + 22k network is only essential if feeding serial by RS232 (+/- voltages). Many people incorrectly wire the 10k+ 22k as a voltage divider.

Please post the code you are using that demonstrates the problem.
 
Last edited:

amdunn

New Member
The code is really simple:

hsersetup B300_8,1
gosub ledon
pause 100
gosub ledoff
pause 1000
MAIN:
do
pause 50
do while ptr <> hSerPtr
b0 = @ptrInc
if b0 = 65 then gosub ledon
if b0 = 66 then gosub ledoff
loop
loop
;
ledon:
high B.0
return
ledoff:
low B.0
return

The code should respond to 'A' by turning the LED on B.0 "on" and to 'B' by turning it off.

The inaccuracy is that sometimes it doesn't respond.

And I don't think it's a distortion in the optoisolator -- I also feed the data signal that has come through the opto and the 74F00 NAND gate back out to the sending PC via several other gates (and for testing, even another couple of optos) and that's 100% correctly received. The PC receives the A or B back every single time -- but sometimes the 20X2 fails to recognize the letter and display the appropriate change to the LED on B.0

I've also noticed something else... that the inaccuracy is greatest at low baud rates like 300. Pushing the rate up to 2400 greatly improves accuracy of reception, which seems counter-intuitive.
 

amdunn

New Member
Some further digging on the "inaccuracies" at 300 baud... 4D (01001110) received as E9 (11101001) or D3 (11010011). 41 (01000001) received as D0 (11100000). 43 (01000011) received as A1 (10100001). So looking at the mis-read bit patterns, it looks like a read bit time synchronization issue. It looks like the read bit time period is on the edge of being a bit off the transmit bit time period. At 300 baud I get an error about every third or fourth character. At 1200 baud I get very rare errors but exactly the same ones. At 2400 baud it seems to be flawless.

That's pretty counter-intuitive. I would have thought the accuracy would be better at lower baud rates and worse at higher baud rates.
 

Goeytex

Senior Member
@Andy,

Many years ago I discovered serial inaccuracies on several Picaxe chips. The thread can be read HERE. As a result, Rev-ed did eventually revise the Firmware on the 20X2, there may have been other updates, but I have not kept up.

Hserin uses the PIC USART peripheral. This hardware peripheral determines when the 'bit read' time happens is not independently adjustable. What firmware/software can control is baud rate, bits, parity and a few other parameters not exposed to the user.

I have an idea that you could try.

Hsersetup uses a constant to set baud rate, for example "B300_8". This constant equates to a value 6,666. This is a binary WORD value of
00011010 00001010 where the SPBRGH:SPBRG Register pair correlate to the MSB:LSB of this constant. These Registers control the USART Baud Rate Generator.

Hsersetup is not limited to fixed values. You can tweak the baud rate with HSERSETUP using your own value. The formula for doing so is in Manual 2.
So "Hsersetup 6666, %001" is valid and is the exact same as "Hsersetup B300_8, %001.

What I am suggesting is that you experiment with custom baud rates and see if adjusting it up or down improves or eliminates the behavior you are seeing.

Here are some values to try. I suspect that either 295 Baud or 305 Baud may provide interesting results

7142 ........ 280 Baud @8MHz
7017 ........ 285 Baud @8MHz
6896 ........ 290 Baud @8MHz
6779 ........ 295 Baud @8MHz
6666 ........ 300 Baud @8MHz
6557 ........ 305 Baud @8MHz
6451 ........ 310 Baud @8MHz
6349 ........ 315 Baud @8MHz
6250 ........ 320 Baud @8MHz

If you are using two Picaxe chips where one is the sender and the other is the receiver, then only adjust the baud on the receiving unit for this experiment.
 

Technical

Technical Support
Staff member
1) Going back to the original post, a 4k7 series resistor in series with your circuit should not be necessary. So the main question is, why is this resistor making a difference? Solve this hardware issue properly and the timings may well solve themselves, as the resistor is obviously affecting the timing (and shouldn't). Does the type of logic circuit used need a pull up/down?

2) How much decoupling do you have on the PICAXE supply rail? Physically close to the PICAXE?

3) What is the device supplying the serial data?
 

amdunn

New Member
The Hardware receive on the 20X2 is being driven by the output of a 74F00 NAND gate. The original source of the serial data is either a PC or another 20X2 (both situations can exist and both have been tested with the same result) through a fast optoisolator (TLP2662F) and a few NAND gates. The waveform out of the last gate is very square (almost no rise/fall) with a total delay of about 6 us through the whole opto/gate circuit and precisely 50% cycle observed on a letter 'U'... so very clean serial waveform.

Yes, I can't think of a reason the resistor makes a difference either... but it does.

I've used either 0.1uF or 0.022uF decoupling literally within millimeters of the VCC/GND pins on the 20X2. I have not seen any behavioral differences in the circuit between the two choices of capacitor value.
 

Buzby

Senior Member
I too can not think of any reason where a series resistor will 'cure' a timing problem, especially as the problem seems worse a low baud rates, which is not usual at all.

However, 'clean' when fast, but 'dirty' when slow could be caused by some kind of capacitive charge/discharge issue.

Are you sure the power and return are adequate, with all the devices have good connections to a common 0v ?.

Also, a missing +ve might go unnoticed due to parasitic powering, which could be further masked by the reduced current required when using the series resistor.

I've use 20X2's with herserin/out on lots of projects, at lots of baud rates, and have never seen this kind of behaviour at all.

That series resistor is just masking the real issue, and if not found, that issue will rear it's head again when you're least expecting it.

It's a mystery that needs solving.

Cheers,

Buzby
 

AllyCat

Senior Member
Hi,
Some further digging on the "inaccuracies" at 300 baud... 4D (01001110) received as E9 (11101001) or D3 (11010011). 41 (01000001) received as D0 (11100000). 43 (01000011) received as A1 (10100001). So looking at the mis-read bit patterns, it looks like a read bit time synchronization issue. It looks like the read bit time period is on the edge of being a bit off the transmit bit time period. At 300 baud I get an error about every third or fourth character. At 1200 baud I get very rare errors but exactly the same ones. At 2400 baud it seems to be flawless.
Not to me it doesn't. IMHO those examples are not "frequency" or bit-time issues, they're just plain random "garbage". There's the old addage: "The more you open the window, the more the **** flies in", and 300 baud gives you a big (33 ms) window. :)

But there are so many questions: Why are super "Fast" components being used for 300 baud (i.e. fundamentally 150 Hz and lower) and what test equipment is available? Why are flashing LEDs being used for "analysis" instead of PICaxe's embedded features such as SERTXD? And what does SERIN (which can probably be run in parallel on the same pin as HSERIN) indicate? Trying to analyse background-received data with LEDs and 50 ms to 1 second Pauses scattered about in the program doesn't seem likely to help.

It sounds more likely that it could be "nanosecond glitches" in the system, which a 4k7 resistor, combined with stray capacitance, to give a "low(er)-pass filter" might well "fix". But we've been given no indications of the purpose, or why these apparently "strange" design decisions have been made. :(

Cheers, Alan.
 

amdunn

New Member
I initially thought it was random garbage... but then discovered the pattern noted above that the mis-reads are always the same data. When 41 hex ('A') is mis-received it is ALWAYS mis-received as hex D0. When 43 hex is mis-received it is ALWAYS mis-received as hex A1.

The super-fast components are being used because the design involves a potentially long chain of devices and I had previous (bad) experience with slope and rise/fall issues on long runs of serial devices, so selected the fastest devices I could to ensure the cleanest signal down the line. And checking with a scope, it is very clean and square and proportional even 20+ gates/optos down the line.

The LEDs were only the first attempt... had expected the design to work and the evidence of that would be the board responding to the proper received characters and that was easiest to indicate (cutting the code down to the minimum) using the LEDs. But the analysis of the mis-received characters was in fact done with SERTXD.

If it truly were nanosecond glitches I'd expect random corruption, but the mis-reads are VERY consistent... and they go away completely when the resistor is in the circuit.
 

Flenser

Senior Member
Andy,

I can see how 0x41 can be mis-received as 0xD0 if the stop bit is missed and the serial hardware interprets bit0 and bit1 of the character as the stop and start bits:
Code:
                +- stop bit
                |+- start bit
                ||    +- character in reverse bit order
                ||    |   +- stop bit
                ||    |   | +- serlal line idles high
                ||    |   | |
                ||----+---|-+-
01000001(41)    1010000010111111111
                  10000010111       <- stop bit, start bit, D0 in reverse bit order, stop bit
                        10111111111 <- stop bit, start bit, FF in reverse bit orde,r, stop bit
I can't see how 0x43 can be mis-received as 0xA1 if the stop bit is missed, no matter which pair or 1 & 0 bits the character are interpreted as the stop and start bit by the serial hardware:
Code:
                +- stop bit
                |+- start bit
                ||    +- character in reverse bit order
                ||    |   +- stop bit
                ||    |   | +- serlal line idles high
                ||    |   | |
                ||----+---|-+-
01000011(43)    1011000010111111111
                   10000101111      <- stop bit, start bit, E4 in reverse bit order, stop bit
                        10111111111 <- stop bit, start bit, FF in reverse bit order, stop bit
 

Flenser

Senior Member
Andy,

My suggestion is that you try to isolate where the problem is.

For example. Try sending single characters from a PC through the full circuit that has the 74F00 NAND gate and the optoisolator but receiving using serin instead of background HSERIN:
Code:
main:
    SERRXD b0
    SERTXD b0
goto main
- If the characters are still being corrupted then it is not the HSERIN code or the PIC serial receive hardware that is causing the problem
- If the characters are never being corrupted then that would seem to indicate that neither the 74F00 NAND gate or the optoisolator can be causing the problem.
 

Goeytex

Senior Member
It does not appear that guessing will effectively resolve this one. It may be a good idea to get one of those cheap 8-bit Logic Analyzers and actually look at the serial data being sent to the PICAXE. Even better, buy borrow or steal a scope for troubleshooting. With a scope you can see the actual waveshape and voltage levels of the serial signal. I could not imagine doing a project like this one without one, especially when there are logic gates, optos, resistors in odd places, and long runs that could all potentially corrupt the serial data.
 

Buzby

Senior Member
My money is still on a wiring error, until we get confirmation one way or the other from the OP.

I think the OP has a scope, and knows how to use it. I'd view the signals at both ends of the resistor, and if the scope is dual trace view the 'difference' signal.
 

amdunn

New Member
I have checked it with a scope. Clean, square, symmetrical waveform.

And the PC that is injecting the data at the start of the train of gates can correctly read the data that comes out the other end of the chain.

Think a single long serial chain like this:

PCTX - opto - 3 gates - opto - 1 gate - feed 20X2 - 2 gates - opto - 3 gates - PCRX


It's really like a multi drop series of boards, each with a 20X2 on it, and the PC can transmit down the whole chain and the appropriately-addressed 20X2 takes action.

Each board has 1 opto, 3 gates and one 20X2 on it.
 

Buzby

Senior Member
Hi Andy,

Have you checked closely the power and ground paths ?.

Are you saying that your system has multiple 20X2 'targets', but only the 'last target' exhibits this effect ?.

Cheers,

Buzby
 

amdunn

New Member
Hi Andy,

Have you checked closely the power and ground paths ?.

Are you saying that your system has multiple 20X2 'targets', but only the 'last target' exhibits this effect ?.

Cheers,

Buzby

Power and ground check out fine.

I've only tried with one 20X2 target (I've only wired up one) but I have wired up a string of the gates and optos to simulate the environment the 20X2 would be in with multiple real boards... and to see how the signal looked at the end of the chain (and it looked very clean... just delayed a few microseconds).
 

Buzby

Senior Member
What is the behaviour like without the 'simulated environment' ?.

In a parallel multi-drop system each node would not see any difference depending on it's location, the bus would look the same to all nodes.

Even with a daisy-chain, where each node RXs the data and then TXs to the next node, each node just 'sees' one other node either side.

I'm struggling to see how any node would ever get its signals via a 20-step path. It should only be 2 or 3 no matter if you use multi-drop or daisy-chain.

Can you give us a sketch of the circuit ?

Cheers,

Buzby
 

amdunn

New Member
It is "series wired" not "parallel wired"... but It's not a daisy-chain where each node retransmits... the goal was to not have every board having to retransmit everything.

Each board in effect sees what the PC transmitted... just buffered further down the line (more gates and optos).

The long chain of gates doesn't seem to influence the serial receive errors at all. Even doing the HSERIN at the start of the chain (one opto and two gates away from the PC) I get the same behaviour as if I put it at the far end of the chain (3 optos and 8 gates away from the PC) so it isn't the long chain that is affecting the serial receive. And as stated above, taking the far end of the line and feeding back to the PC receive results in the PC reading perfectly what it transmitted.
 

Technical

Technical Support
Staff member
What value pull up resistor is being used on the TLP2662F optoisolator (between the output pin and V+, before it gets to the logic gate). They are open collector devices. It still sounds to us like something is corrupting the signal, and the optosiolator is a prime candidaie. Have you tried with just logic, no opto?. A microcontroller will be far less tolerant to baud stretching than a PC will.
 

Buzby

Senior Member
Also, have you put decoupling on each opto ?. ( Datasheet says it needs it, so I'd do it ! )
 

Flenser

Senior Member
Andy,
Your problem is an unusual one and the more info the forum has the better chance that someone might be able to spot what the issue is. It will help if you post the code you are running, a schematic of the circuit, and a photo of the circuit.
 

amdunn

New Member
Opto pull-up is 10K.

A simplified version of the circuit schematic is attached (there's also a bunch more I/O - sensor inputs, output LEDs, and so forth... but they're not even exercised in my testing so far). The intent is that every 20X2 in the chain receives what the PC sends (as long as C.1 is high, which it normally is), and every 20X2 can grab the line circuit (by taking C.1 low) and transmit, and that data is received by the PC and by every 20X2 further up the line. The 20X2 then puts C.1 back high and is all set to receive, and pass on data up the line. That part works flawlessly (with the exception of the odd receive problem).

I've tried it with three sections of the line circuit (opto + 3 NAND gates) and the behaviour doesn't change, whether I connect the first, second or third section to the 20X2. The PC always receives all the data correctly whether sent originally from the PC or from the 20X2's transmit circuit.

R3 is the resistor that shouldn't be necessary... but somehow is.

20X2_HRX_HTX_circuit.png
 

inglewoodpete

Senior Member
There is a cloud in my mind relating to the way you inject serial out into the data stream at U2.2. How do you change the polarity of hSerOut (Pin C.0/Leg 10)? Can you post the code directly relating to how this is set and reset?

Edit: I just checked the input type for hSerIn (Pin B.6/Leg 12) and the manual says it is TTL, which should be compatible with a 7400 gate's output.
 
Last edited:

Goeytex

Senior Member
After doing a bit of research I will offer the following (my opinions mixed with some facts)

1) 74F logic is speed oriented at the expense of high power consumption. Certainly would not be recommended for any type of battery operated device.

2) 74F logic may be too fast to directly connect to a PIC CMOS Input without some interface circuitry (R3?)

3) Having to add a 4K7 current limiting resistor to the RX input to eliminate data corruption highly suggests that the output of the 74F may be rising too fast for the Picaxe input pin.

4) You may want to consider making R3 10K and adding 10K pull down so that the circuit looks like the Picaxe Download Circuit. If this resolves data the corruption issue then go with it. Problem solved. I would not presume the resistor is unnecessary especially when mixing different logic types.

5) Per the PIC 18F14K22 Datasheet, when set as USART RX, Physical Pin 12 on a Picaxe 20X2 (PIC 18F14K22) is a Schmitt Trigger input and can handle relatively slow rise times no need for extreme speed or super fast rise/fall times.

6) Sub 2ns propagation delays are unnecessary with RS232/TTL Data, and may even be too fast. Consider using 74HC(T) series logic instead of 74F. If you have long runs and need more output current than 74HC can provide then consider using a dedicated line driver IC for that purpose instead of counting on the high current 74F Logic for long runs.

7) Unused inputs on Logic ICs should never be left floating. U2-4 (not shown in the diagram) should have its inputs tied to ground. This prevents potential ringing/glitches. This also includes unused PIC inputs. Alternatively set unused/unconnected PIC I/O pins as outputs. Should be standard practice but this is ignored by many folks. Floating inputs on Logic ICs can and will cause flaky operation.

8) Suggest 100nf (.1uF) decoupling caps on all ICs instead of 22nf (.022uF). 100nf is "Standard Practice" in most cases. 022uf may not be effective.

9) Suggest 4K7 or 3K3 Pullup resistor on OPTO to reduce the slope/Rise time a bit. 10K might be OK but I would reduce it.

10) Why 300 baud for this project?. That seems agonizingly slow and buys very little if anything in the way of reliability. I would probably kick the Baud rate up to 9600 and set the PICAXE speed to 16 MHz unless there is a really good reason for 300 baud.

11) If it were me I might consider using RS485/Modbus for this project instead of RS232/TTL. It is much more robust.

That's my 11 cents.

(Edited to correct some typos)
 
Last edited:

AllyCat

Senior Member
Hi,

+1. That's what I was "hinting at" twenty posts ago :
Why are super "Fast" components being used for 300 baud ...... more likely that it could be "nanosecond glitches" in the system, ....
It's 30 or 40 years since I used "FAST" chips ("Fairchild Advanced Schottky TTL") , i.e. whenever they were "State of the Art" - a significant improvement on the alternative Schottky (74S series) or ECL (Emitter-Coupled Logic) , which both used currents that were in no way compatible with battery operation (except perhaps a car battery). Technologies probably now best forgotten. ;)

As indicated by Goeytex, there is only a degree of "compatibility" between the various logic families and some "interfacing" may indeed be needed. But also, my eye is drawn to that connection of U2.1 and U2.2 to two pins on the PICaxe. I don't know if it's been described how those pins are being used (by the software/internal hardware), but that's a classic "gotcha" configuration to produce nanosecond glitches due to a "race" condition.

Detecting "glitches" has always been difficult even with high quality 'scopes (I started with Tektronix's when you could use one in place of a 2 kW room heater), but these days the majority of 'scopes use digital sampling techniques, which (IMHO) gives even greater opportunities to "hide" what is actually happening. :(

Cheers, Alan.
 

amdunn

New Member
Some clarifications on points raised above. First it is not a battery operated project, so the power issue wasn't considered.

Also, it's only a partial circuit diagram. All device inputs everywhere are terminated correctly. There are no unused gates as the extras are used for other things in the circuit, and all the PICAXE I/O pins are used either to read inputs or drive outputs or LEDs.

I have tried changing the 10K opto pull-ups to 4K7 and it seems to behave the same either way, so I may leave them at 4K7.

I've tried both 0.022 and 0.1 decoupling caps and observed no change in the behaviour. 0.022 is what I happen to have in the circuit at the moment but I'll probably build it with 0.1 at each chip.

The use of the multiple pins connected to the two NAND gates is this: the first gate in the sequence is used to block any received data if the 20X2 wants to transmit, to avoid corruption if something else happened to transmit at the same time. Taking the C.1 pin low forces the output of U2.1 high (the same as it would idle if C.1 was high but the input from the line circuit was low, as it will be with an idle high input to the opto, which inverts to a low) and keeps the input idle. Then U2.2 is used to replicate the idle-high hardware TX from the 20X2 which then is an active low at the output of U2.2, which U2.3 inverts so the output of the line circuit is idle-high again.

So the protocol is to take C.1 low, wait one full byte time (say, 50 ms), then transmit, then take C.1 high again when done. That guarantees the transmitted data does not get stepped on.

That part of the circuit doesn't seem to be germane to the receive corruption issue... which can be experienced even if the 20X2 is not transmitting at all.

I will try the 10K hardware receive with pull-down change and see if it makes a difference.

And why 300 baud? It's because one of the things these boards send commands to, further up the line, is an older designed device that was built as a 300 baud serial input. The goal was to avoid having to change those, although it wouldn't be impossible.

The boards will send two-byte datagrams in response to a poll less frequently than once every couple of seconds, so 300 baud will suffice. But so would 1200 baud or even 9600 baud.

The connections between the boards are not particularly long distances and sometimes fairly short. With the opto-isolated inputs, they are intended to be immune to ground loop effects if boards are powered from different sources - which they sometimes will be.
 

tmfkam

Senior Member
Some years back I modified one of the PicAxe serial LCD modules so that I could use it to monitor serial communications. I set it so that it simply echoed the bytes transmitted on the serial "bus". For tracking down confusion like you are suffering I found it invaluable. It can be connected in parallel with the existing connections to allow real time monitoring.

I would try something similar. Connect it at the source and check what is being sent. Connect it at the first board input and check. Connect it at the outputs of the logic gates (with polarity inverted if needed) and check. Connect it at the input to the 20X2 and check.
 

Technical

Technical Support
Staff member
Looking at the circuit is the logic gate U2.3 sourcing all the current required by the 'next' opto isolator LED when the gate output is 'high'? if so we wouldnt be surprised if the gate is collapsing from over-current draw and hence attempting to draw current from the PICAXE pin, hence the resistor making a difference. In general logic gate outputs are better at sinking current than sourcing.
 

amdunn

New Member
And that could finally make sense as to why the resistor makes a difference... I'm going to swap out the last inverter for a 2N2222 driver and see what effect that has. The serial gate/opto chain works fine and returns a good, clean, square round trip signal all the way down the line... but it's the nagging question of why the resistor makes serial receive more accurate on the 20X2. Will report back once that is tested.
 

AllyCat

Senior Member
Hi,

I'd forgotten how low is the pull-up current of (even) F-series TTL gates, the "maximum" rating appears to be 1 mA pullup and 20 mA pulldown, which seems incompatible with the 330 ohms in series with the LED of your opto-coupler. The reason for the low pullup current is because TTL inputs are intrinsically NPN Emitters, which themselves act as a (pull-up) current source.

But to my mind, the 4k7 resistor is acting as a low-pass filter with the (say) 5pF "stray" capacitance of a typical pin/PCB track to ground or between pins. That's a time constant of 25 ns, compared with the potential rise/fall or propagation delays of around 2 - 5 ns of a 74F series gate (which needs a really decent 'scope or Logic Analyser). All three of your gates appear to be allocated to pins 8, 9 and 10 , so it's not possible to guess where stray couplings might occur, but with both polarities of edge available on the same package (at the same time) , there are definite possibilities for instability due to "positive feedback". In particular, the 10k pullup resistor on the optocoupler output seems (far) too high (50 ns risetime ? ) ; THIS LINK (the first that Google found for me) suggests 1k - 4k7 , but seems mainly concerned with "leakage" (thermal) currents, whilst stray (capacitive) coupling is only referred to as "noise".

Another factor to consider is: suppose that "something" (unknown) causes a random glitch once every 100 ms. Then there's a 33% chance that it will occur during one of your 300 baud characters. Put the baud rate up to 9600 baud and the probability drops to 1% for a given character. I also have some "suspicions" about the use of the background receive; do you even need to use it, as the base PIC chip has (at least) a two-byte "silicon" buffer (which can be accessed via SFR commands) ?

Cheers, Alan.
 

marks

Senior Member
Ideally all inputs (Rx) should be properly terminated with a low impedance termination.
This will greatly improve signal quality especially when used for data.
For TTL speeds 4.7k ohms pullups are commonly used (just like whats recommended when using Hi2C)
Ideally we want too see the same rise and falltimes .

So maybe all you need is a 4.7k pullup on pin12 of your 20x2
if you feel you still have a problem with ringing or oversyhoot or reflections from
that other 7400 gate input perhaps try a 4.7k pullup with a 430 ohm series resistor.

your circuit is interesting but does seem over complicated and your transmitting back into background receive
which you will need to ignore or perhaps this is by design?
If I was doing this i would isolate the master with opto's
and the second picaxe take advantage of its drive cabilities which are upto 50ma (would only need 10ma)
still have two seperate supplies.if a next stage was needed add opto's again.
all picaxes too receive at he same time(you wouldn't have to halt like your circuit does)
and each could transmit when requested by the master.

I would think when using the Eusart any errors caused noise ,frame errors or baudrate etc
it would reject the frame so you would appear to loose characters
but it may only check this at the start and stop bit positions.

your code in post#3 looks like it could also cause problems
your not addressing the pointer properly
your just reading the last one
you could have missed quite a few characters by the time you get there'
and if you advance the pointer while also receiving in the background(a bit at a time lol)
it just chops the character (advances midway to a new starting point.)
once you go back to the start of the scratchpad the character that you read
could have part of the old or new data within it..
so its a mess @300 baud it could do this a few times
@2400 8mhz is a sweet spot usually just enough time without using background receive
so will appear to work better.
 
Last edited:
Top