Transceiver-linked 40X2s

[Circuit]

I would be most grateful for some guidance from the experienced forum experts with this project. I intend linking two PICAXE 40X2s via a serial link over XBee transceivers. My aim is to map PORT D as inputs on one unit to PORT B as outputs on the other. This arrangement to apply both ways; i.e. Press-buttons on PORT D on unit one map to PORT B on unit two and the buttons on PORT D on unit two map to PORT B on unit one. The rate of switching is very low - indeed almost occasional. I think that this can be achieved using the hardware serial ports on the 40X2 devices, but, although I am very familiar with the use of SERIN and SEROUT and PICAXE in general, I am having some trouble understanding the depths of the hardware serial commands.

The problem is that I cannot use the simulator to check the operation of the program because the hardware serial function is not simulated. So before I commit a soldering iron to a stripboard, could I request comments on the viability of this concept and my proposed code?

'Serial transceiver switching using XBee and 40X2
'Hardware serial output on pin C.6
'Hardware serial input on pin C.7

#picaxe 40X2
#no_data

setfreq m16

SYMBOL REQUESTED_OUTPUT = b0        'reserve w0 and w1 for handling incoming serial data sent to PORT D
symbol port_switches = b4     	'reserve w2 and w3 for handling local switch data from PORT B
SYMBOL last_switches = b5

hsersetup b2400_16,%001       	'2400 Baud - True IN & True OUT - Background Receive On - 
setintflags %00100000,%00100000     'Interrupt on background serial input

let dirsb = $FF   			' set Port B as outputs
let pinsb = $00   			' initialise Port B outputs low
let dirsd = $00   			' set Port D as inputs

#macro send_switches

	hserout 0,(PORT_SWITCHES)     'transmit value to XBee transceiver
	Last_switches=port_switches   'record last switch change
	do until pinsd=$00
	pause 100   			'pause to debounce switch return
	loop
	
#endmacro   

interrupt: 
pause 50   			 	'Is this needed?

let ptr=0
get ptr, REQUESTED_OUTPUT
let pinsb = REQUESTED_OUTPUT
				
flags = 0   				'Clear interrupt flags
hserptr = 0       			'Reset pointer
setintflags %00100000,%00100000     'Reset interrupt on background serial  
return  

MAIN:
DO
	do 
		let port_SWITCHES = pinsD
		pause 100   		'Debounce switches
		if port_switches>0 then EXIT  
	loop
	send_switches 
LOOP

 

[Roman505]

The problem is that I cannot use the simulator to check the operation of the program because the hardware serial function is not simulated. So before I commit a soldering iron to a stripboard, could I request comments on the viability of this concept and my proposed code?

Could you not commit parts to a breadboard, being a non-committal sort of thing to do?

While checking your code may be easy and even highly reliable when done by an expert here, it seems to me odd from two points of view that you should make the request not for a mere review of your code but for effectively authorising you to solder. Firstly, you are making someone else responsible for your possible errors. Secondly, isn't some of the fun working out how you think you can do something, then testing it to success?

I do not mean to be critical. Rather, I am suggesting you might be more rewarded by testing and showing the result or questions, instead of moving from "trouble understanding" straight to "final" on someone else's say-so.

 

[Circuit]

it seems to me odd from two points of view that you should make the request not for a mere review of your code but for effectively authorising you to solder. Firstly, you are making someone else responsible for your possible errors.

I have developed many PICAXE circuits and written the code for them very successfully; the normal process of things is that I outline the code, check it runs on the simulator and then get out the soldering iron. The simulator does not YET support HSERSETUP and therefore I am simply "requesting comments on the viability" and "guidance" from the many most helpful experts on this forum who often offer such input most graciously. I am merely looking for pointers in the right direction for this project, not "authorisation to solder".

I continue, therefore, to ask if our most collegial experts on this forum would be helpful and guide my thinking within the spirit of the forum.

 

[Roman505]

You are welcome to do so and I did not seek to deny it. I note that you replied to my post quite selectively though, so I remain content with my entire views as expressed.

All the best with your project.

 

[hippy]

What you want should be possible and without having to use interrupts. Simply send data when pins have changed, update the outputs whenever new data is received. Untested and does not debounce inputs -

#Picaxe 40X2
#No_Data
#No_Table

Symbol currentD = b0
Symbol lastD    = b1

#Macro Initialise
  SetFreq M16
  HSerSetup B2400_16, %001
  dirsB = $FF
  dirsD = $00
#EndMacro

#Macro SendInputPins
  currentD = pinsD
  If currentD <> lastD Then
    HSerOut 0, ( currentD )
    lastD = currentD
  End If
#EndMacro

#Macro ReceiveOutputPins
  Do While ptr <> hSerPtr
    pinsB = @ptrInc
  Loop
#EndMacro

Initialise
Do
  SendInputPins
  ReceiveOutputPins
Loop

In terms of constructing hardware that shouldn't be a problem as the circuit is fairly simple. The main purpose of breadboarding and/or hardware (VSM) simulation is to check there are no mistakes in wiring things up such as connecting RX to TX and TX to RX when it should be RX to RX and TX to TX or vice versa, miscounting PICAXE leg numbers and using the wrong pins, using a pin for an input or output when it cannot be used as that and so on. It's usually easier to change a breadboard or simulation than physical hardware.

In terms of software simulation (PE, Logicator) the usual purpose is to ensure the logic of the code is correct and it does what it is meant to. That can get a bit tricky when it is software and hardware which needs to be simulated together as here as a pure software simulation does not necessarily know about the hardware intricacies.

One way to test high-speed serial background receive for simulation is to remove the HSERSETUP command and fake data having been put into the background receive buffer. That works well for the above because interrupts are not being used, data present is determined using 'ptr' and 'hserptr' ...

#Macro FakeReceivedData
  ptr = 0
  @ptrInc = %00000001
  @ptrInc = %00000010
  @ptrInc = %00000100
  @ptrInc = %00001000
  @ptrInc = %00010000
  @ptrInc = %00100000
  @ptrInc = %01000000
  @ptrInc = %10000000
  hSerPtr = ptr
  ptr = 0  
#EndMacro

Initialise
FakeReceivedData
Do
  SendInputPins
  ReceiveOutputPins
Loop

Simulate that and the output pins B will go high in turn, set as per the data specified by the FakeReceivedData macro.

Macros are quite useful but there can be gotchas when it comes to simulation. Because they specify code to be used elsewhere in the program, the lines of the macro are never executed where they are specified within the source code. That means a breakpoint set within a macro will never be triggered. You can however set a breakpoint on the 'ReceiveOutputPins' line within the DO-LOOP to see the output pins being set however.

 

[Circuit]

Hippy, that is immensely helpful - spectacularly so. Precisely the assistance I was seeking and more. Your suggested code gives me a superb outline to work to and the trick with the workaround for HSERSETUP is as useful as it is ingenious. It is also particularly enlightening to see the code optimised for the new Program Editor 6. I must say that I find the new editor to be quite superb; a few teething troubles of course, but that is why it is a beta. The concept for the underlying redesign is simply excellent.

I do appreciate the time you spent in analysing my aims and providing the guidance that you have, many thanks indeed.