Hi guys,

Got a small problem when trying to test what data has been received by the PIC. What i am doing is sending out data, when the receiving end processes the data, it sends "ok" back allowing the PIC to know when it is clear to send more data. I am having trouble reading in and testing the "ok"
The way i am testing the incomming message is by moving the contents of RCREG into a file called store. From here i subract d'79' which is "o" in ascii and test the zero flag bit i.e. if it is "o" then the zero flag will be set. Then i go on to test the "k" part of the message.
This is where the program gets held up, it sends out the required data perfectly, but then stops when testing for "ok" Heres a snippet of code where i test the zeroflag bit:

UART MOVF RCREG, W ;
MOVWF STORE ;
GOTO MODE ;

MODE
BCF STATUS, Z
MOVF STORE, W ;
SUBLW D'79' ;
BTFSC STATUS, Z ;
GOTO SENSOR2 ;

Any pointers would be greatly appreciated thanks

 

hi,
Can you say what the 'receiving end' is, example PC ??

If you are using a MAX232 on the PIC uart i/o and its talking to say a PC, the PC program could control the CTS line, which the PIC could read.

If not, why are using 'ok' as ok to send, why not a single used ascii control code or one of the ascii commands for clear to send?

Eric

 

It would be a lot simpler if you used the assembler to convert from ascii to decimal.

Use,
sublw "o"

Doing this ensures that you compare with 111 which is "o" and not 79 which is "O".

Mike.

 

sorry i should have said,

I am using two telegesis wireless modules, one connected to my sensor circuit via MAX232 and PIC16F74, and the other connected to the PC where the telegesis terminal software is running. I am sending out the at+bcast:00,"data" from the sensor circuit, which broadcasts the message to the network. This part works since the pc end is recieving the data but for a limited time i.e. the sensor circuit is sending out too much for the node to handle. When the sending node completes the transmit it confirms by sending "OK" which is what i am trying to read with the PIC. So that the PIC is synchronised with the wireless node.

Hope this clears up what i am trying to do

Thanks again guys

 

hi,
I follow your description.
Have looked over the telegesis site, for some reason at the moment my downloads from that site hang up, I'll try later.

As Mike points out the 'AT' protocols are upper case "OK".

Software control of 'clear to send' can be source of problems in a asychronous TX/RX serial system.
Problem is, by the time the transmitter gets/decodes the 'acknowledge' its transmitting.

Is it possible you can modify the receiving program in the PC, so that it forms a data string when it detects the 'at+bcast' identifier,, any partial unsynched string would be dumped?

Can you post your full code as an attachment, I'll run it thru my simulator to see if I can find any obvious bugs.?

Does your system work ok, if the PIC and PC serial ports are connected by a cable,,, hardwired?

Eric

 

Hi eric,

Thanks for the help, iv attached the asm file for you to have a look at. When i dont check for the received "OK" The program works perfectly, but the wireless node cant cope with the amount of data being sent out. When i check for the "OK" it only transmits the first set and hangs up when testing for "OK".

Tnaks again, greatly appreciate this

Attached Files

WiFi.asm (8.8 KB, 5 views)

 

hi,
Found a number of problems with your code, amended, runs ok on my simulator.

I did see that you are using 0x0C register as your Store,,, this is the PIR1 reg!. moved to 0x20....

I will post the amended code later today.

When I input dummy ADC data, it coming out as hex, needs bin to ascii conversion

Eric

Attached Images

screenhunter17.jpg (21.6 KB, 7 views)

 

hi,
This amended code work ok on the sim..

marked the changes with ##### on lines.
Changed some of your repeated routines to 'calls'

You require to convert the ADC values to ascii?, before sending.

Operation:
Power up, Init.
Send 'A' block, wait for 'OK'
Send 'B' block, wait for 'OK'..............
etc.

Lets know how it goes.

Eric

Attached Files

WiFi3.asm (7.5 KB, 3 views)

 

hi,
Found that your ADC channel select codes wrong, corrected also
added a simple byte2asci subr.

Eric

Attached Images

screenhunter.jpg (20.0 KB, 9 views)

Attached Files

WiFi4.asm (8.7 KB, 4 views)

 

Thanks for the code eric,

That is some piece of code you have written there I havnt tested it yet, i am just reading through it all, making sure i understand what is going on with all the new sub routines. I will let you know how it goes. You deserve a beer or two for this

Many thanks

 

Just tested the program,

It manages to send out the first set of data, this is what the receiving node displays: "BCAST:000D6F0000063D1C=AA106" but it hen does nothing, it seems as if the program isnt receiving the OK from the node. I tried looking for LF/ OK/ CR/ to no avail

 

hi,
Is there any way you can confirm that the PC is sending the "OK" back to the PIC??

I would test it by using a second PC/Laptop and using a cable connection between the PIC and PC's serial port.

If you have upgraded the asm, post a copy and I will re-run it for you.

Eric

 

What i reckon is happening, is the sending nodes buffer is getting over run with data, so even if the "OK" is being sent back it wont be able to continue sending. I was thinking of implementing the xon xoff handshaking, but unsure how to set this up. Any ideas?
This is from the telegesis data sheet:

"When using a channel there are no limitations to the payload, so a buffer overflow can occur when sending too much data at once or where the recipient is temporarily out of reach. To avoid a buffer overflow XON/XOFF handshaking is used"

The only changes i did to the program was to change the receive characters to D'13' and D'10' looking for LF and CR.

Thanks again

 

Hi,
The problem with XON [ctrlQ] and XOFF [ctrlS] is that they also take time in the sending [receiver] to be detected.

As the 1st block of data dosn't over run the PC's RX buffer, I cannot see why a following data block will do so, as its not sending a second data block until it gets the "OK". You get the 1st block "BCAST:000D6F0000063D1C=AA106" which appears to be complete!.
IMO I dont think its an over run problem.

I would recommend that you get PROCOMM in your PC, set it to 'chat' mode and drive the serial port from the PC's keyboard in order to prove that the system works without the radio link and the telegesis software.

Eric
Can you say where you are posting from?

EDIT: if you can post the telegesis model number I will look thru their documentation.

 

I will go and find the PROCOMM and try that out. The module is the ETRX1. Im posting from work in the uk