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
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
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
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.
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
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
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.
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.
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
Nick Asked:
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:
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.
Last edit: William Roth 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
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.
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:
And here is the Main:
The interrupt sub:
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.