Linx RF Modules

[Macgman2000]

Hello,

I used these modules several years ago and coded in PicBasic Pro https://www.linxtechnologies.com/en/products/modules/es-rf-transmitter-receiver.

The Debugin / out commands would sit in a tight loop waiting for the first byte of a certain value (like 55 or 85...etc) of data before receiving the rest of the bytes of data.

This is an example of the code:

DEFINE DEBUGIN_REG GPIO ' Set as software RX in
DEFINE DEBUG_BAUD 2400 ' Set bit rate
DEFINE DEBUGIN_BIT 0 ' Set GPIO bit 0
DEFINE DEBUGIN_MODE 0 ' Set Debugin mode: 0 = true, 1 = inverted

debugin 400,Alloff,[wait (85), Duty, Rudder,checksum]

400 is a time out in milliseconds, where if nothing is received it jumps out to execute Alloff.
Wait(85) is waiting for value 85 before packing the rest of the received bytes into Duty, Rudder, Checksum.

Does GCB have the same feature ? How would I accomplish the above example if this feature does not exist in GCB?

Thanks!
Nick

[Macgman2000]

OK I think I partially answered my own question....but still need clarification.

I found this code below...

Not sure how this works.....I understand all the arguments except 1 + waitforStart.

Can this be a number like 55 or in my above example 85 before the serial rx bytes are read in?

Trying to bridge Picbasic Pro and GCB to reuse my older codes.

Best Regards,
Nick

chip 16F88, 8

#config Osc = Int

#define RecAHigh PORTB.2 ON
#define RecALow PORTB.2 OFF
#define LED PORTB.0

Dir PORTB.0 Out
Dir PORTB.2 In

InitSer 1, r9600, 1 + WaitForStart, 8, 1, none, normal
Do
    SerReceive 1, Temp
    If Temp <= 50 Then Set LED Off
    If Temp > 50 Then Set LED On
Loop

[Anobium]

Morning.

The Help is good for the serial communications. I am assuming you are using the latest build.

Why would you not use the hardware serial solution?

There are many examples of hardware (and software) comms in your demo folder.

I just ported one of the demos to the 16f88.

; ----- Define Hardware settings
'''A demonstration program for GCGB and GCB.
'''--------------------------------------------------------------------------------------------------------------------------------
'''This program sends characters from microprocess using the GCB Hardware-UART methods drect to the PC terminal.
'''Asynchronous mode:
'''•1 - Transmit inverted data to the B.5/TX/CK pin; and
'''•0 - Transmit non-inverted data to the same pin.

'''
'''@author  Evan R. Venn
'''@licence GPL
'''@version 1.0a
'''@date    8.7.16
'''********************************************************************************

; ----- Configuration
  #chip 16F88, 4

; ----- Define Hardware settings
 ' THIS CONFIG OF THE SERIAL PORT TO A PC TERMINAL via a TTL Converter
 ' USART settings
 #define USART_BAUD_RATE 9600
 Dir PORTb.5 Out
 Dir PORTb.2 In
 #define USART_DELAY 5 ms
 #define USART_TX_BLOCKING

; ----- Variables
  ' No Variables specified in this example. All byte variables are defined upon use.

; ----- Main body of program commences here.
  'Message after reset
  wait 500 ms
  do Forever
   HSerPrint "Hello World"
   ' "Carriage Return"
   HSerSend 13
   ' "Line Feed"
   HSerSend 10
  Loop

There may be reasons to use software serial but you should be using the latest build as there are some great features included to achieve your wait command.

See HSerGetNum and the other related commands in the Help file.

[Macgman2000]

Thanks! I have the compiler installed on my work PC windows 7. I run Ubuntu 14.04 LTS at home on all my other machines, I dislike windows and the plethora of crutch software you must get (virus scan for example).

I would love to install GCB at home, but so far I only have access to online help files and code examples. I tend to write code and come in the next day to cut and paste into GCB.

Best Regards,
Nick

[Anobium]

Have a look at the Linux build. All works great! You do need the latest build but a number of folks have the Linux build working.

[Chris Roper]

And, having just done it myself, I can confirm that the latest build works well in Wine under Linux Mint / Ubuntu. I have the compiler , IDE, help System and Xpress Evaluation board all running with out a single hickup.

[Macgman2000]

Hello Chris,

I need to set up WINE on my laptop. Do you have any suggestions on setup? Meanwhile I am going to watch some youtube videos to set Wine up.

Best Regards,
Nick

[William Roth]

Nick Asked:

Not sure how this works.....I understand all the arguments except 1 + waitforStart.
Can this be a number like 55 or in my above example 85 before the serial rx bytes are read
in?

The answer is no. The 1 is simply the number of stop bits. "Waitforstart" is a constant with a value of 128. "Waitforstart" sets a bit in the software serial receive function(sub) to tell it to wait until a start bit is received before proceeding to process the data. If nothing is received the program will wait forever at "SerReceive" There is no provision for a timeout.

Nick Commented:

Trying to bridge Picbasic Pro and GCB to reuse my older codes.

While GCB and PBP are both BASIC, the differences are quite significant. Your PBP code will
need to be highly modified or in many cases completly re-written for use with Great Cow Basic.

I would suggest that you spend some time in the GCB help and get familiar with syntax and
commands. Then just play around with some of the demos.

Now to your specific application .....

Why use bit-banged software serial, when hardware serial is so much better? Your chip has a USART, so why not take advantge of it and of the powerful features of GCB?

For your application I would set up hardware serial to receive data in the background using an interrupt. This way the microprocesor program can do other stuff while waiting to receive serial data from the receiver.

You have given us bit and pieces of what your application is, but few specifics so I have to make some assumptions. I am assuming that this if for RC control of something that has a rudder. and since you mentioned PWM maybe a throttle control. (Without specifics I can only quess) .

So for grins, I will assume that the transmitter sends a data packet of 4 bytes to the receiver. These bytes represent: 1) a qualifier byte, 2) a rudder control byte, 3) a PWM duty byte and 4) a checksum byte.

Heres how I would do it :

1: Configure Hardware Serial
2. Create an Array ( buffer) to hold received data
3. Set up constants & variables as needed
4. Configure an interrupt to quicky move received data into the array/buffer
5. Poll a variable to determine if a data packet has been received

Here is some sample code (generalized) that will hopefully get you on the right track and help to demonstrate the power and flexibility of GCB. Instead of controlling a rudder, etc we will just turn on off 2 LEDs based upon the values of 2 received data bytes. I used the 16F18855 so you will need to modify the code for your specific chip.

; Example of Simple RC Control
; Using HardWare Serial (USART)

#chip 16F18855,32
#Config FEXTOSC_OFF, RSTOSC_HFINT32
#Config WRT_OFF, CPD_OFF, MCLRE_ON

#Define USART_BAUD_RATE 2400
#Define USART_TX_BLOCKING
; no blocking for RX data.

#define LED1 PORTC.1
#define LED2 PORTC.2
DIR LED1 OUT
DIR LED2 OUT

#define Qualifier    Hser_Buffer(0)
#define LED1_CTRL    Hser_buffer(1)
#define LED2_CTRL    Hser_buffer(2)
#define Checksum     Hser_Buffer(3)  'Not used in this Demo

DIM hser_buffer(8)  'Create an 8 byte buffer array to hold received data
DIM hserptr         'Pointer for above buffer array
DIM  ms_cntr        'Counter - Counts milliseconds

'Starting values
hserptr = 0         'Clear pointer to location 0 of the array
Qualifier = 0
LED1_CTRL = 0
LED2_CTRL = 0
Checksum = 0

'interrupt when a byte is received into USART RX
ON Interrupt UsartRX1Ready Call Byte_Received

'MAIN PROGRAM LOOP
'---------------------------------------------------------
  Do
     'poll hser_pointer to see if data has been received
     IF hserPtr  <> 0 then ' a byte has been received
        Call Process_Data
     End if

     'Poll Status/Error Flag
     if flag <> 1 then
         If LED1_CTRL  >= 127 then
           set LED1 ON
         else
            Set LED1 OFF
         end if

         If LED2_CTRL >= 127 then
           Set LED2 ON
         Else
           Set LED2 OFF
         End IF

     end if

  Loop
'-------------------------------------------

Sub Process_Data
    ms_cntr = 0  'clear milliseconds counter

    'wait for all 4 bytes to be received
     do until hserptr > 3
        wait 1 ms
        ms_cntr++  ' increment counter
         if ms_cntr > 25 then    ' taking too long
             flag = 1
             hserptr = 0
         end if
     loop

   ' now test the qualifier byte
     if qualifier <> 85 then  'bad packet
        hserptr = 0    'reset pointer
        flag = 1       'Set the error flag
        exit sub
     end if

     if qualifier = 85 then  'qualifier must be good
       flag = 0
       hserptr = 0
     end if

End sub

SUB Byte_Received    'Interrupt Service Routine
'''This routine quickly gets a received byte from USART
'''and places it into the hser_buffer array.

  hserreceive (hser_buffer(hserptr)) 'get the byte and put it in
                                     'the buffer at location pointed
                                     'to by hserptr

  hserptr ++    ' increment the pointer by 1 for next byte
  if hserptr > 7 then hserptr = 0 'make it a circular buffer
END Sub

END

[Macgman2000]

Hello William,

You are correct on your assumptions. Wow, this is quite a bit to chomp on. I need to go through your code and understand what all it does. Thanks for the demo code, I may have questions :)

I have used PBPro for almost a decade. When the price jacked up to > $250.00 I decided to get out of my comfort zone. I can pretty much write any code off the top of my head in PBPro....but time to learn new syntax and think of code writing slightly differently. They do a good job at encapsulating, but it's not worth the premium they are asking, Especially when GCB can do the same thing.

Best Regards,
Nick

[Chuck Hellebuyck]

Nick,
I agree completely. I've written books on PBPro and used it since it was first released so I can also write it in my sleep. It get a lot of syntax errors in GCB because I still use both. I would have expected the price of PBPro to come down as even PIC C compilers are cheaper now. GCB has expanded in features so much and the fact you get a pure assembly code file that can be imported into MPLAB X and run through a full debugging session makes it superior to PBPro. At the price of FREE, GCB is an absolutely amazing value thanks to the work done by Hugh, Evan and the rest of the contributors.

[kent_twt4]

I have followed this conversation with interest. I will need a hardware serial data receive routine from a datalogger anyway, so I dived in. I was hung up for quite a while until I realized that that a "wait 1 s" was in the main loop and messing things up timing wise. So a tight loop is required for the speed of my example.

The device used was a enhanced midrange 16f1704, which is kind of weird because it has a peripheral pin select for the digital output/input pins.

The basic flow uses the principles already touched on in earlier posts. Use the hardware serial module and the On Interrupt UsartRX1Ready to pick off the last byte from the serial receive buffer RCREG (or RC1REG in my case). The synch byte is the ampersand "&". The data bytes are built char by char in the interrupt until a comma (NewByteIn) is encountered. The BytesIn is then processed in main and echoed back to the terminal to verify correct USART reception. The terminal is used to mimic a PIC sending the data. My terminal transmit window uses "&,64,153,208," The commas are essential.

Here is the setup with a 16MHz internal clock:

'*****setup Hardware UART*****
#define USART_BAUD_RATE 115200
#define SerOutPort PortA.0
#define SerInPort PortA.1
dir SerOutPort Out
Dir SerInPort In
Dim RxByte(3)
On Interrupt UsartRX1Ready Call ReceiveData

And here is the Main:

'test communication
For count = 0 to 10
  HSerPrint count
  HSerSend 10
  HSerSend 13
  wait 100 ms
Next
  HSerSend 10
  HSerSend 13
wait 1 s

Main:
'ignore synch byte (i.e. ByteIn = 1)
'a comma was encountered and a new "numerical"
'byte is to be processed
If BytesIn > 1 AND NewByteIn = True Then
   NewByteIn = False
   If charcount = 3 Then
      TempNum = (RxByte(1) - 48) * 100
      TempNum = TempNum + (RxByte(2) - 48) * 10
      TempNum = TempNum + (RxByte(3) - 48)
   End If
   If charcount = 2 Then
      TempNum = (RxByte(1) - 48)  * 10
      TempNum = TempNum + (RxByte(2) - 48)
   End If
   If charcount = 1 Then
      TempNum = (RxByte(1) - 48)
   End If
   'restart counting characters
   charcount = 0

  If BytesIn = 2 Then Duty = TempNum
  If BytesIn = 3 Then Rudder = TempNum
  If BytesIn = 4 Then
    checksum = TempNum
    HSerPrint Duty
    HSerSend 44
    HSerPrint Rudder
    HSerSend 44
    HSerPrint checksum
    HSerSend 44
    HSerSend 10
    HSersend 13
  End If
'wait for the next NewByteIn
charcount = 0
NewByteIn = False
End If
goto Main

The interrupt sub:

sub ReceiveData
'Pull received byte off USART buffer
'adjust to RCREG,RCR1REG,RCREG1 as required
InData = RC1REG
NewByteIn = False
'start of header ampersand "&"
If InData = 38 Then
  BytesIn = 0
  exit sub
End If
'Comma delimited
If InData = 44 Then
  'and now done counting characters
  NewByteIn = True
  BytesIn += 1
  Exit sub
End If
'log in characters
If NewByteIn = False Then
  charcount += 1
  RxByte(charcount) = InData
End If
end sub

[Chuck Hellebuyck]

William Roth:
"The 1 is simply the number of stop bits. "Waitforstart" is a constant with
a value of 128. "Waitforstart" sets a bit in the software serial receive function(sub) to tell it to wait until a start bit is received before proceeding to process the data. If nothing is received the program will wait forever at "SerReceive" There is no provision for a timeout. "

That is a great summary. I looked for a definition in help and elsewhere and could not find it. If this doesn't exist, then this should be added to the help file for serial communication.