Absolute certainty with SERIN/SEROUT when plugging into the circuit.

mortifyu

New Member
Hello Guru's, hope you are all well.

I am currently working on a project that requires one PICAXE to communicate with another when plugged into the circuit. I have my circuit working just fine and the entire system operates excellently other than initial communication not being 100% absolute when initially plugging in a 'slave chip'. Depending on which 'slave chip' is plugged into the circuit, will depend on what functions take place. As it stands, this does work, but only about 98%-99% of the time. When it doesn't work it drops to the 'failed' subroutine seen in the 'slave' CODE.

The connector is 4 pin: +5V, RX, TX, GND.

Below are code snippets that should give you the clear understanding to my dilemma...
I have no doubt in my mind you guys/gals will offer much smarter suggestions, hence why I am here and all ears 👂👂👂;)

MASTER CHIP (14M2) Always Powered:
Code:
init:
setfreq m32
#define qualifier "7A654GHDLYSYTN529YN"

symbol baud=N38400_32
symbol in=c.3
symbol out=b.1
symbol CHIP=b0

main:
let CHIP=0

serin [500],in,baud,(qualifier),CHIP

if CHIP=123 then low c.2 sertxd("CHIP1 Detected",cr) gosub chip1 endif
if CHIP=213 then low c.2 sertxd("CHIP2 Detected",cr) gosub chip2 endif
if CHIP=188 then low c.2 sertxd("CHIP3 Detected",cr) gosub chip3 endif

goto main
.
.
.

SLAVE CHIP (08M2) Is Powered when plugged into the circuit
Code:
init:
setfreq m32
#define qualifier "9W654GXDMYSRYN529YN"

symbol baud=N38400_32
symbol in=c.1
symbol out=c.0
symbol CHIP=b0
symbol Variable=b1

pause 6000    'Allow a good second for slave to be fully plugged and seated to socket.

main:
serout out,baud,(qualifier,CHIP)
serin [33,failed],in,baud,(qualifier),Variable
.
.
.
.
failed:
high c.2
end

In case you may be wondering, 'serin [33,failed],in,baud,(qualifier),Variable' in the slave CODE '33' is more than enough time. (Tested and checked with a Bitscope).
The Master responds in good time when it has successfully received the SEROUT command from the slave.

I anticipate BG serial receive with interuppt suggestions from you folk, but was hoping to be able to stick with SERIN/SEROUT to avoid a high volume of re-coding.


Regards,
Mort.
 
Last edited:

techElder

Well-known member
I think your "qualifier" is unnecessarily too long, and why do you need it anyway? Why didn't you simply use a variable to value "qualifier?"

Also, in your "slave" snippet, I don't see a set value for "qualifier" or "CHIP".
 

PhilHornby

Senior Member
The thing to note, is that there is no 'buffering' whatsoever of your data - if the Serin hasn't been executed before the data starts to be transmitted, some or all of it will be lost.

I would say: add a short Pause between the Serin and the Serout in the master (to give the slave time to execute the next statement).

Also, in the slave, change the 'failed' processing to retry a few times (in case the master was busy when the data was sent).
 

mortifyu

New Member
I think your "qualifier" is unnecessarily too long, and why do you need it anyway? Why didn't you simply use a variable to value "qualifier?"

Also, in your "slave" snippet, I don't see a set value for "qualifier" or "CHIP".

Hi Tex,

My bad missing those couple items. The CODE snippets are practically what I am working with, but for the sake of IP, I have partly modified things for this forum post.

Crazy long qualifier... Crazy long so there is 0% chance of inferior chip connectivity. In the actual program, every data transmission is also severely encrypted.


Regards,
Mort.
 
Last edited:

mortifyu

New Member
The thing to note, is that there is no 'buffering' whatsoever of your data - if the Serin hasn't been executed before the data starts to be transmitted, some or all of it will be lost.

I would say: add a short Pause between the Serin and the Serout in the master (to give the slave time to execute the next statement).

Also, in the slave, change the 'failed' processing to retry a few times (in case the master was busy when the data was sent).

Hi Phil,

I previously did try pauses as you suggest, it did not help things as can be seen on my scope.

As previously mentioned, everything does work to perfection 'when' the initial communication is successful. This is where the problem lies.

Further in the program, I have serial communication being maintained in a loop between Master/Slave so as to be able to detect when the slave has been removed from the circuit. This purposely causes a Reset. There are 20 retries in both master and slave that ensures the serial link/looping is reliably maintained where the number of retries is reset to 0 upon a single success and that does indeed work flawlessly.

Perhaps you are right with the suggestion of retries.


Regards,
Mort.
 

mortifyu

New Member
I may have solved my issue!!!

As per Phil's suggestion of implementing retries (HIGHLIGHTED IN CAPS)...

Code:
init:
setfreq m32
#define qualifier "9W654GXDMYSRYN529YN"

symbol baud=N38400_32
symbol in=c.1
symbol out=c.0
symbol CHIP=b0
symbol Variable=b1

SYMBOL RETRIES=B2

pause 6000    'Allow a good second for slave to be fully plugged and seated to socket.

main:

INC RETRIES
IF RETRIES=20 THEN GOTO FAILED

serout out,baud,(qualifier,CHIP)
serin [33,MAIN],in,baud,(qualifier),Variable
.
.
.
.
failed:
high c.2
end
Additionally I have also now placed 47K pull down resistors on the TX(b.1)/RX(c.3) pins of the master(14M2) keeping any possible unwanted noise that may occur on the serial lines during physical plug connection time far below the threshold that the master 14M2 Serin may consider as a HIGH pulse.

Thus far approx. 300+ connect/disconnects one after the other flawless. Previously there were 1 or 2 fails within 100 connects/disconnects.

I am still very much interested to hear further suggestions from more Guru's floatin' about this forum.



Thank you.

Regards,
Mort.
 

hippy

Senior Member
I am still very much interested to hear further suggestions from more Guru's floatin' about this forum.
I think most things have been covered. I personally wouldn't ever END on a failure in the slave but just keep going. That wouldn't then need any additional retry counting. Your C.2 can then be used as a trying to connect LED ...
Code:
; Slave
Main:
  SerOut out, baud, ( qualifier, CHIP )
  SerIn [33,FailedToConnect], in, baud, (qualifier), Variable

Connected:
  Low C.2
  ...
  Goto Main

FailedToConnect:
  High C.2
  Pause 80 ; 10ms at 32MHz
  Goto Main
In your master code it's best not to fall through the SERIN if you don't get anything ...
Code:
WaitForConenction:
  serin [500,WaitForConnection], in, baud, (qualifier), CHIP
 

mortifyu

New Member
I think most things have been covered. I personally wouldn't ever END on a failure in the slave but just keep going. That wouldn't then need any additional retry counting. Your C.2 can then be used as a trying to connect LED ...
Code:
; Slave
Main:
  SerOut out, baud, ( qualifier, CHIP )
  SerIn [33,FailedToConnect], in, baud, (qualifier), Variable

Connected:
  Low C.2
  ...
  Goto Main

FailedToConnect:
  High C.2
  Pause 80 ; 10ms at 32MHz
  Goto Main
In your master code it's best not to fall through the SERIN if you don't get anything ...
Code:
WaitForConenction:
  serin [500,WaitForConnection], in, baud, (qualifier), CHIP

Hi Hippy,

Thank you for your insights. I goto 'END' upon failure at that early point because there is quite a lot of further communications that go on beyond that point. So long as the initial communication is successful, everything else operates fine. If there is an initial communication failure, there is no point going any further.



Regards,
Mort.
 

PhilHornby

Senior Member
I am still very much interested to hear further suggestions ...
A couple of thoughts:

You could swap to using Hserout, rather than Serout. On the 08M2 and 14M2, it's the same pin, so no hardware change is needed. Hardware generated serial is possibly better controlled, wrt to baud rate, but also, it's slightly asynchronous - it completes when the last character starts to be transmitted, rather than when it completes. OK, this is only 1mS @ 9600 baud, but sometimes, it's helpful :)

You can use Run 0 instead of Reset. This resets the software (i.e. it restarts with the first instruction), but doesn't do a full hardware reset. All the variables are left intact - which may or may not be useful.
 

mortifyu

New Member
A couple of thoughts:

You could swap to using Hserout, rather than Serout. On the 08M2 and 14M2, it's the same pin, so no hardware change is needed. Hardware generated serial is possibly better controlled, wrt to baud rate, but also, it's slightly asynchronous - it completes when the last character starts to be transmitted, rather than when it completes. OK, this is only 1mS @ 9600 baud, but sometimes, it's helpful :)

You can use Run 0 instead of Reset. This resets the software (i.e. it restarts with the first instruction), but doesn't do a full hardware reset. All the variables are left intact - which may or may not be useful.

Hi Phil,

Thanks for that. We learn something everyday here on this forum. Run 0 is something I did not know. However a Reset in this case is required because I do indeed want all variable values to be reset.

Hserout... Funny you mention this, The pins used were in fact selected for that very reason with BG receive in mind at the time. Thus far the current method appears to be working perfectly now.

It will take me a couple days to get back to making a test jig, but I am going to make a test jig that will repeatedly switch a relay switching the slave in/out of the circuit whilst monitoring and counting the number of times there was a failure (c.2 of slave going HIGH) and will report the results here when done. But as it now stands, approx. 500+ connect/disconnects flawless.



Regards,
Mort.
 

mortifyu

New Member
OK....

I managed to make a test jig much sooner than I anticipated I'd get the time to make it.

It is a very simple test jig that basically has a 4 pole relay connecting and disconnecting the 4pin connector which brings the 08M2 into the circuit.
I have made and used a hardware random noise generator and fed the output into a ADC input thus providing myself with a randomly changing ADC value from 0-1023. With a bit of simple math the end result is that the disconnected period varies between 1.0s-3.0s. Also, not that I have mentioned anywhere earlier in this thread, the 'Actual' circuit also has an output pin on the slave that confirms a successful communication.

The results....

10,000 test connects.

0 Fails.


I am now more than happy to call this 100% flawless!!!! WooHoo!!! 🥳🥳🥳🥳


Thank you to ALL for your suggestions and thoughts. PICAXE FORUM #1 on the internet!!!!



Regards,
Mort.
 
Last edited:
Top