N38400_32 BaudMode between 18M2 and 20M2 with qualifier

#1
Hi,
I'm trying to figure out why my comms isn't working between a master 18M2 and a slave 20M2. Both are set to 32MHz clock freq via SetFreq M32 command.

I'm only sending two bytes from my master : Serout c.6,N38400_32,("M",1)

The receiving 20M2 code is actually via the Serin pin : Serrxd [P_4000ms,Timeout],("M"),b6
The receiving code times out.


My understanding is that if the normal baud rate of the Serin pin using Serrxd is 4800 at 4MHz default clock freq, so it would be 4800 * 8 = 38400 at 32MHz clock. So I can't see anything wrong.


I've attached a picture of the received signal from my scope, but with a test of sending Serout c.6,N38400_32,(1,1).
The time to send one byte (10 bits taking acount of 1 start, 1 stop and 8 data bits) seems to be 0.33ms. So in 1 second this would be 1000/0.33 * 10 bits = 30303 bits (baud rate).

I might be miscalculating somehow or it might be the scope but this seems low compared to the 38400 it should be. So is it this?

Or is it that the picaxe can't receive properly using a qualifier at N38400_32.



Maybe I'm missing something obvious. Has anyone else used a qualifier successfully at N38400_32 ?
Thanks
 

Attachments

Technical

Technical Support
Staff member
#2
We assume the 0V's are linked?

The total time is actually 10 bits + 'inter byte delay' due to firmware processing (fetching the next byte from memory etc.). The transmitted bytes are therefore not back to back, so the stop time is effectively longer than with back to back signals. This means your baud calculation is not correct.

The faster the clock speed/baud the less time available for the firmware to process the inter byte code (ie decide whether it is the qualifier or not and then start decoding the next byte). Start off with a much lower baud and then work your way up.
 

Goeytex

Senior Member
#3
Try adding a delay between the qualifier and the data byte.

Code:
Serout c.6, N38400_32,("M")
Pause 8      '// 1 ms@ 32MhZ 
Serout c.6,N38400_32,(1)
If this works, then reduce the delay until it just stops working. Then add back enough until it works reliably.

My testing has shown that at 38400_32, serin cannot reliably receive back to back data bytes at a true 8N1. Rev Ed has added extra space between sent data bytes with serout to help mitigate the problem with Picaxe to Picaxe Comms. But, with a qualifier more time needs to be added between the qualifier and the data bytes.
 
#4
Thanks both. Yes the 0v are defnitely connected.
I understand what you're saying Technical about inter byte processing. I didn't realise the extension of the stop bit time would actually change the baud rate calculation though.
One thing I don't understand : Is the timeout at the receiving end on a 'per byte' basis or for the start of the reception? If I implement a delay between qualifier and the data byte does the receiving serrxd wait (up to the timeout value) for each byte received? I had always thought (probably incorrectly) that the receiving end would expect back to back bytes once reception was underway.


It's not imperative that I have a qualifier in this case but I'm just wanting to understand what's gong on. Everything else is working brilliantly.
 

Technical

Technical Support
Staff member
#5
I didn't realise the extension of the stop bit time would actually change the baud rate calculation though.
Instead of 10 bits = 0.33, it is 10 bits + extra processing time = 0.33

One thing I don't understand : Is the timeout at the receiving end on a 'per byte' basis or for the start of the reception?
Per byte, the timeout timer 'resets' between each byte.

I had always thought (probably incorrectly) that the receiving end would expect back to back bytes once reception was underway.
Each byte is synced upon the start bit edge, so a long gap between bytes does not matter - in fact a longer gap helps the PICAXE get all it's 'between byte' firmware processing done. As Goeytex says, it may struggle to get this processing done at very high baud/clock speeds. If this is the case its then time to look at hardware solutions such as hserin etc. on X2 parts.
 

Goeytex

Senior Member
#6
The diagram below may help a bit for checking baudrate.

Have the Picaxe send two bytes ("UU") or (85,85) and then measure per the diagram below.

Code:
#Picaxe 18M2
Setfreq M32

Low C.6  '// Make Serout Pin as output and set low  


Do
    Serout C.6, N38400_32,(85,85)
    pause 16     '// 2 ms
Loop
Inverted Serial.png
 
#7
Thanks very much for that. Plus the diagram Goeytex. It all makes complete sense. It's also simple enough to add a slight delay to give the receiving end time to process.

My 20M2 needs to run at 32MHz because I'm using it with a rotary encoder. It works really well but when I drop the clock frequency I have noticed it skips detection of rotation sometimes. Plus as I'm using serrxd then I 'think' the baud is fixed at N38400_32 on this pin (at this clock frequency). It would be nice to know if there are any clever tricks to change this? For example although I need the picaxe to run at 32MHz to catch all the encoder transitions I don't really need it to communicate at N38400_32 at all. It could be slower. My slave is a little 'UI module' in effect that receives setup commands and also sends it's position back to the master.
 

Goeytex

Senior Member
#8
On the 20M2 Serin Pin you are stuck with whatever the default baud rate is for the given processor speed. Slowing the clock down to M8 temporarily will set the serin baud to 9600. However this may not buy you much since the instruction times will increase.

Are you committed to using serrxd and the serin Pin? It would be preferable to use a different pin for serin and then N9600_32 where reliable comms can be assured.
 
#10
Well it would be more sense to use another pin. Diagram attached shows what I'm doing and as you can see it's almost a full house ! B.1 is free though and I 'could' have used this had I thought of the potential problems before doing the PCB. Lesson learnt. Although in this case a delay after the qualifier isn't a problem. Plus I might have a use for B.1 in my next version.


Anyway, thanks for the explanations, they really help.
 

Attachments

hippy

Technical Support
Staff member
#11
You could jumper the Serial In leg to the B.1 leg with a bit of wire, issue a DISCONNECT at the start of the program, then SERIN on B.1.
 

AllyCat

Senior Member
#13
Hi,

Yes, it's unfortunate that SerIn on a 20M2 doesn't have a Port.pin name. AFAIK, with an 08M2 or 14M2 you could just use SERIN with the Programming Input pin.

FWIW, the SerOut pin does have an alternative name (A.0) which can be used with some (but not all) instructions, and both pins can be accessed via SFR peeks and pokes as (base PIC) Port A.0 (SO) and A.5 (SI) on all three chips.

Cheers, Alan.
 
Top