Best non blocking serial input strategy?

[cloudy]

I'm looking to pick up serial input from an ID-12 RFID reader - but whilst the PICAXE is normally performing other tasks, this means I can't use the blocking serin command as I don't know when the RFID is going to be presented.

The ID-12 chip has an RFID in range logic output, but when I try to use this or the serial input pin itself as an interrupt, I only catch the end of the transmission with the serin (9600bps)

Could the hardware serial input peform this function? (PICAXE 18M2+ and the data packet is 11 bytes long)

Many Thanks,
James

 

[AllyCat]

Hi James,

It might be possible, but depends on many factors and I don't have any experience with the ID-12 RFID reader:

Are you using an elevated clock frequency for the PICaxe? What is the polarity of the serial data? What are the "other tasks" that the PICaxe is performing? "How "advanced" a PICaxe user are you?

9600 baud is often a "struggle" with PICaxe becuse the interpreted Basic is so slow and the "interrupts" are only polled by the operating system. Other problems are that the HSERIN buffer is only two bytes deep (at best) in M2s and the input signal is of fixed polarity (Microchip "forgot" to put an Exclusive Or gate on the input to make the polarity configurable). Also there is a poorly documented "bug" in the handling of (the first line of) interrupts with M2 devices (and maybe other issues as well).

Eventually, I did get a similar configuration working with an 08M2, but only by using numerous workarounds, including avoiding certain PICaxe commands. Some of the issues are discussed in this thread.

Cheers, Alan.

 

[srnet]

B

est non blocking serial input strategy?

Use a 28X2 which has a large background serial receive buffer.

 

[cloudy]

Thanks both for the suggestions - the ID-12 has both an inverted and non inverted serial output, but it's locked at 9600. Am running the PICAXE at 8mhz.

After reading that, I've attacked it a different way this morning, by flipping the program around - looping round a serin with a very short timeout - checking for inputs that require the picaxe to do something else amongst that - the timeout is short enough that button inputs are still picked up in adequate time for my application...

I guess there's the risk of the serial input arriving during the loop, but I would assume at 8mhz a tight loop checking two inputs isn't going to take too long, and the user can always re-present the tag if that occurs...

James

 

[AllyCat]

Hi,

I would assume at 8mhz a tight loop checking two inputs isn't going to take too long,

About the same time as taken by 3 bytes at 9600 baud. Provided that you don't use any excessive or "slow" instructions such as a Return.

Cheers, Alan.

 

[Flenser]

cloudy,

It would probably be worth you while checking out using HSERIN in place of SERIN, as Alan already hinted at in post #2.

The 18X2 chip has a hardware UART that can receive serial data in the background, completely independantly of the CPU running your picaxe program. i.e. your program and the hardware UART will both run in parallel without one blocking the other.

The hardware UART has a two character FIFO buffer that allows reception of two complete characters and the start of a third character before your picaxe program must start handling the received characters, or risk missing them.

Your program must keep up with the received data, of course. If a third character, in its entirety, is received before reads the full FIFO to free up one spot then the UART stops receiving any additional characters until the overrun condition is cleared.

The hserin command is non-blocking. It only has to read the head of the FIFO buffer, it doesn't need to wait for anything.

 

[inglewoodpete]

Use a 28X2 which has a large background serial receive buffer.

Since you're currently looking at an 18-pin PICAXE, how about the 20X2? Just a little larger and much more powerful. It has background (hardware) serial reception and a 128-byte scratchpad that can be used as a receive buffer.

P.S. Flenser is referring to the 18M2 - there is no 18X2!

 

[hippy]

Another alternative, with only slightly more complicated hardware and extra cost, but far easier in software terms, is to add a second PICAXE which can act as a front-end buffer between the ID-12 and the master PICAXE. An 08M2 can probably do the job here.

That front-end PICAXE can spend all its time doing nothing but waiting for an ID-12 packet to be received and then raise a signal for the master PICAXE to see when it gets one. The master can meanwhile do whatever it wants, taking however long it wants, and only interact and get the data from the front-end when it chooses to.

 

[BESQUEUT]

Another alternative, with only slightly more complicated hardware and extra cost, but far easier in software terms, is to add a second PICAXE which can act as a front-end buffer between the ID-12 and the master PICAXE. An 08M2 can probably do the job here.

That front-end PICAXE can spend all its time doing nothing but waiting for an ID-12 packet to be received and then raise a signal for the master PICAXE to see when it gets one. The master can meanwhile do whatever it wants, taking however long it wants, and only interact and get the data from the front-end when it chooses to.

I never understand how can one more Picaxe resolve this kind of problem...
As the 08M2 spend all its time waiting for ID-12, it cannot listen to the master Picaxe, and will never "interact" with it.
Do we have to add a Picaxe front-front-end ?

 

[westaust55]

I never understand how can one more Picaxe resolve this kind of problem...
As the 08M2 spend all its time waiting for ID-12, it cannot listen to the master Picaxe, and will never "interact" with it.
Do we have to add a Picaxe front-front-end ?

The 08M2 does not specifically need to listen to the Master continuously.

The 08M2 waits for the initial signal from the ID-12 and immediately receives the mentioned 11 bytes of data.
Once the data is received the 08M2 sends a signal to the 18M2 (or other chip) as an interrupt.
The 18M2 when ready send back a response to indicate ready to send the data.
08M2 sends data to the 18M2. 18M2 reads then goes about interpreting and acting on that data resuming its "normal" activity cycle.
08M2 then goes back to monitoring the ID-12.
All that should be faster than one could swipe an RFID card past for another pass/read.

 

[hippy]

As westaust55 describes. Here's one example. Note the T2400 baud rate used to communicate between the Front-End and Master ...

;         Front-End                        Master
;       .-----_-----.                  .-----_-----.
;      -| V+     0V |-                -| V+     0V |- 
;      -| SI    C.0 |-                -| SI    C.0 |-          
;      -| C.4   C.1 |--< ACK <- RDY <--| C.4   C.1 |-
; RX >--| C.3   C.2 |--> DAT -> DAT >--| C.3   C.2 |-
;       `-----------'                  `-----------'

FrontEnd:

  Symbol ACK = C.1 : Symbol PIN_ACK = pinC.1
  Symbol DAT = C.2
  Symbol RX  = C.3

  Do
    Low   DAT
    SerIn RX, N2400, b1, b2, b3
    High  DAT
    Do : Loop Until PIN_ACK = 1
    Pause 1
    SerOut DAT, T2400, ( b1, b2, b3 )
  Loop

Master:

  Symbol DAT = C.3 : Symbol PIN_DAT = pinC.3
  Symbol RDY = C.4

  Do
    If PIN_DAT = 1 Then
      High  RDY
      SerIn DAT, T2400, b11, b12, b13
      Low   RDY
    End If
    Gosub Whatever
  Loop

 

[BESQUEUT]

The 08M2 does not specifically need to listen to te Master continuously.

The 08M2 waits for the initial signal from the ID-12 and immediately receives the mentioned 11 bytes of data.
On the data is received the 08M2 send a signal to the 18M2 (or other chip) as an interrupt.
The 18M2 when ready send back a response to indicate ready to send the data.
08M2 sends data to the 18M2. 18M2 reads then goes about interpreting and acting on that data resuming its "normal" activity cycle.
08M2 then goes back to monitoring the ID-12.
All that should be faster than one could swipe an RFID card past for another pass/read.

OK : thanks for the explanation.