18m2 VERSION "A" hSERIN problem

[SAborn]

Is there a problem with the 18m2 firmware version "A"and background receive, as from my testing with 2 x 18m2 chips , its garbage that is received from one chip to the other.

Using the same code in a pair of 08m2 chips all works perfect as one would expect.

The basic code is a byte via serout from one chip to a hserin on the receiving chip, and all i get is garbage on the
hserin.

And yes the hsersetup is correct.
And yes i have tried "T" and "N" baud polarities, to no benefit.

Im not a school kid learning picaxe, and have been around for a while now.

Im getting a little tired of picaxe functions that dont work from picaxe chip to chip due to software bugs, and needing to find a work-a-round to solve what should be a given function out of the box.

Can anyone confirm the problem or am i just going mad with trying to make a useless function work.

 

[rossko57]

If you won't share a code snippet or the nature of the data expected and garbage recieved, how about clock and baud rates involved?

 

[SAborn]

I think i have been around long enough to not need to share my socks and undies draws to express a problem.

If i send a one and get a 21 back, then to me its a problem, regardless of the code i use. (not an actual example)
And yes i have done the tests of different baud rates, different data bytes sent, "N" & "T" polarity, etc ,,,etc. so to me there is a bug in the 18m2 on Hserin.

Im sure this will get run around in circles with demands for code and other crap, but all that is needed is others to test 18m2 to 18m2 via serout to Hserin and see what results you get, and note what version chip you have.

 

[JimPerry]

But test with what?

 

[SAborn]

Just send serial data from a 18m2 or any chip to a 18m2 hardware serial input and see what data you actually receive, for me its garbage i receive.

Is that so hard to follow, serial data out..>>>>>>... Garbage in via Hserin, using just serin works fine , its just Hserin that has a problem.

 

[Technical]

Is there a problem with the 18m2 firmware version "A"and background receive,

If there was a known issue, which there isn't, it would be listed on the revision history.
http://www.picaxe.com/Hardware/PICAXE-Chips/PICAXE-18M2-microcontroller/

So yes, your code samples are indeed required. Particularly as there is no such thing as background receive into scratchpad on the M2 parts, there is only a silicon 2 byte buffer.

 

[hippy]

This worked for me using a single 18M2 (D.A) to send (SEROUT) and receive (HSERIN). I would have expected it to work between two 18M2's ( with the SEROUT/PAUSE removed on the receiver ), and that did work sending from an 08M2 to 18M2 (D.A) -

#Picaxe 18M2
#Terminal 4800

; Link B.2 To B.3 ( leg 8 to leg 9 )

High B.3
HSerSetup B2400_4, %000
Do 
  w0 = -1
  HserIn w0
  If b1 = 0 Then
    SerTxd( #b0, " " )
  End If
  SerOut B.3, T2400, ( b9 ) : Pause 1000
  b9 = b9 + 1
Loop

 

[SAborn]

Thanks for the replys, a little busy during the week, so perhaps on the weekend i can retest and supply some code to suit.

I find it strange the 08m2 works perfect and thus far the 18m2 will not.

And yes Techenical i do understand the M2 has a 2 byte buffer, although if i sent 123 i would expect to read back 123 as a single byte, which is not happening with the 18M2 but will with the 08M2.

 

[Technical]

Actually Hippy proved above that the 18M2 D.A does work, so let's see your code and hardware layout to help.

 

[rossko57]

... although if i sent 123 i would expect to read back 123 as a single byte

That is rather context dependent; you know what method you are using to verify it, etc., but is that where the single byte expectation goes wrong? I'm thinking some consequence of using SERTXD or whatever you do use to verify, but no doubt all will be revealed in due course.

 

[Circuit]

Has this issue been resolved? It would be interesting to hear where the discrepancy between Hippy's demonstration of the correct operation of the function lies in relation to the issues that SABorn seems to be having.

 

[Goeytex]

I have an 18M2 Rev A here and it works fine as far as it goes. But with the 2 byte buffer the received data must be processed immediately or else the data in the buffer will be overwritten.

The M2 background receive is good for receiving only 2 back to back bytes at a time. In one project I tied C.5 to the serin pin and then set an interrupt for c.5 to indicate data activity. In the interrupt routine it first waits 20ms for both bytes to arrive, then processes the bytes, clears the data, and returns to the main loop to wait for the next two bytes. The sending device MUST wait at least the time it take to process the data and get of the ISR before sending the next two bytes.

M2 HSERIN is limited and clunky, but it can be made to work.

 

[SAborn]

I must admit i have not got back to retesting it, life/work duties have limited my time to getting back onto the test bench to retest the problem.

From the tests i done there was good cause to ask the question i have, but from hippy's tests the problem dont exist, so no the problem has not been answered or confirmed as far as i have tested.

There has since been several threads that might have encountered a similar problem, but thus far no problem has been identified as fact.

 

[Circuit]

The M2 background receive is good for receiving only 2 back to back bytes at a time. In one project I tied C.5 to the serin pin and then set an interrupt for c.5 to indicate data activity. In the interrupt routine it first waits 20ms for both bytes to arrive, then processes the bytes, clears the data, and returns to the main loop to wait for the next two bytes. The sending device MUST wait at least the time it take to process the data and get of the ISR before sending the next two bytes.
.

Gentlemen, thank you.
@SAborn - I look forward to your further investigations when you time becomes available to you.

@Goeytex - Inspirational, as ever; what a good idea! My problem is that I would like to receive two bytes of serial input sent as a control signal through the transparent serial connection afforded by XRF modules; but I cannot afford to lock up the chip waiting for a serin because I also want the PICAXE to monitor its inputs looking for a press-button change that would cause it to transmit a command out instead. Your idea of setting up an interrupt by tying the two pins together is inspirational and may do just what I need. Thank you!
Do you just connect the two pins together, or do you put an intervening resistor in place to protect against programming cock-ups and overloading the pins with a high/low situation?

 

[Goeytex]

A 330R resistor between the pins will do fine.