Menu

Linx RF Modules

2016-07-07
2016-07-10
  • Macgman2000

    Macgman2000 - 2016-07-07

    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

      Macgman2000 - 2016-07-08

      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

        Anobium - 2016-07-08

        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.

         

        Last edit: Anobium 2016-07-08
        • Macgman2000

          Macgman2000 - 2016-07-08

          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

            Anobium - 2016-07-08

            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

    Chris Roper - 2016-07-08

    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

      Macgman2000 - 2016-07-08

      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

    William Roth - 2016-07-08

    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
    
     

    Last edit: William Roth 2016-07-08
    • Macgman2000

      Macgman2000 - 2016-07-08

      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

    kent_twt4 - 2016-07-09

    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.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.