Hello all! Just a quick question about GCB:
I have a program waiting for a trigger character
as well as some bytes and a checksum.
with HSerReceive and no blocking, My MCU can poll
it's ports to have the data waiting, and since I can't
afford a 'log jam', The read itself isn's suitable for
a checksum.
Without interfering with the HSer functions,
What is the surefire way to tell characters have been just
received by the USART.
My binary data might be anything, So the 255
returned by HSerReceive isn't going to work out.
I might need it!
I can't just turn blocking on, either.
I'm sure there's an address, but I'm uncertain of the procedure, bit, order of events, etc...
Where's my Basic EOF(1) function?
Last edit: Mikorians 2016-03-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can I check a few things? version of Great Cow BASIC?
What level of expertise? Have you looked in the Help for the Serial Ring Buffer? The latest version of Great Cow BASIC has some great enhancements for hardware serial - what are you using? Hardware or software serial?
Can you post some code to show us what you have tried?
Lots of people will help - just a little more information first.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Again these are not complete solutions for your application but contain the pieces you will need.
What is you Baud? what is your Processor speed?
What is the surefire way to tell if data is available?
"USARTHasData" is a variable that is set by the USART when it has data avaible. For the '887 "RCIF" is the bit in the PIR1 register that sets the "USARTHasData" variable.
value of EOF is system-dependent but is commonly -1, which is 255
Mike
Last edit: mmotte 2016-03-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, latest version .95
I was unaware of Serial ring buffer example.
I'll check it out!
Baud is 115k. Hardware serial.
Didn't know what to try. I had actually tried just reading
the value of RCIF, but it didn't seem to return useful results.
I examined the USART.h file a bit and assumed there must be another way.
So GCB will set USARTHasData to... 1 ? 2 ?
I can use this? Does GCB clear it too?
I've had bad luck with the hardware interrupts
and just need a way to perform a quick check in my loop.
Another posting uses an interrupt based on 'UsartRX1Ready'.
Simple need:
All I need is a flag that serial data is waiting to be read from the USART.
I cannot use blocking in my loop or a 255 receive result.
Adittional:
The USART has what- A 2 byte buffer?
it also has overflow and other flags (quite complicated)
I hope it won't stop scrolling new bytes in without stopping...
I haven't noticed any trouble, yet. Missing bytes I expect maybe. Reasonable to assume.
Last edit: Mikorians 2016-03-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Try the ring buffer. It handles most things very quickly as it uses interrupts. You need to think about optimisation of the 'other' and how you handle the incoming data.
Recommend also a good scan of the new help. There is masses of new functionality that you can leverage in the libraries.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Added to top of Sub HSerReceive(Out SerData):
Set EOF On
and just before each SerData = xxxx:
Set EOF Off
Now with Rx blocking off, I can use HserReceive var
in a loop and know if a 255 character was received WITHOUT interrupt usage
or other synchonizatipn bytes.
I hope someone can benefit from this suggestion.
Thanks all!
Last edit: Mikorians 2016-03-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Some general advice, strongly advised to do stuff in this posting.
As usart.h can be updated (it will be in the next few days) I strongly recommend a better approach to ensure your changes are not lost during upgrades.
Add Dim OEF in your main program,
then, take a copy of Sub HSerReceive and place in your mail code. Change the sub name to Sub myHSerReceive
Then, may your changes,
then, finally add some at the top of the main program #define HSerReceive myHSerReceive.
This will redirect all calls to HSerReceive to your routine.
Downside? there is... if you wanted to use any of the other HSerReceive routines (there is more than one in the later versions of Great Cow BASIC) you would have to copy and rename to myHSerReceive.
Upside? You do not loose theses critical changes when you upgrade.
We will issue a compile upgrade and a lot on .h files are refreshed often... make these changes recommended and you will not risk losing your good work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I re-read carefully what Anobium suggested again- It's very clever.
I just love this language.
I can compare the source with the asm, and use in-line asm too.
So cool. Makes using Pics a breeze. I have 9 networked together now
with a 3-wire pull-up, then a hardware serial to a Raspberry Pi.
If only pyserial weren't so slow. Even at 115k.
Can't figure out what I'm doing wrong.
Last edit: Mikorians 2016-03-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello all! Just a quick question about GCB:
I have a program waiting for a trigger character
as well as some bytes and a checksum.
with HSerReceive and no blocking, My MCU can poll
it's ports to have the data waiting, and since I can't
afford a 'log jam', The read itself isn's suitable for
a checksum.
Without interfering with the HSer functions,
What is the surefire way to tell characters have been just
received by the USART.
My binary data might be anything, So the 255
returned by HSerReceive isn't going to work out.
I might need it!
I can't just turn blocking on, either.
I'm sure there's an address, but I'm uncertain of the procedure, bit, order of events, etc...
Where's my Basic EOF(1) function?
Last edit: Mikorians 2016-03-15
Hello,
Can I check a few things? version of Great Cow BASIC?
What level of expertise? Have you looked in the Help for the Serial Ring Buffer? The latest version of Great Cow BASIC has some great enhancements for hardware serial - what are you using? Hardware or software serial?
Can you post some code to show us what you have tried?
Lots of people will help - just a little more information first.
Anobium has pointed you to the Serial Ring Buffer Example which gives an example of Serial Interrupt driven input.
Another example in in the Contributors forum https://sourceforge.net/p/gcbasic/discussion/629990/thread/b8141e3b/
written by Thomas Henry using ring buffer jargon like head and tail.
Again these are not complete solutions for your application but contain the pieces you will need.
What is you Baud? what is your Processor speed?
What is the surefire way to tell if data is available?
"USARTHasData" is a variable that is set by the USART when it has data avaible. For the '887 "RCIF" is the bit in the PIR1 register that sets the "USARTHasData" variable.
value of EOF is system-dependent but is commonly -1, which is 255
Mike
Last edit: mmotte 2016-03-16
OK, latest version .95
I was unaware of Serial ring buffer example.
I'll check it out!
Baud is 115k. Hardware serial.
Didn't know what to try. I had actually tried just reading
the value of RCIF, but it didn't seem to return useful results.
I examined the USART.h file a bit and assumed there must be another way.
So GCB will set USARTHasData to... 1 ? 2 ?
I can use this? Does GCB clear it too?
I've had bad luck with the hardware interrupts
and just need a way to perform a quick check in my loop.
Another posting uses an interrupt based on 'UsartRX1Ready'.
Simple need:
All I need is a flag that serial data is waiting to be read from the USART.
I cannot use blocking in my loop or a 255 receive result.
Adittional:
The USART has what- A 2 byte buffer?
it also has overflow and other flags (quite complicated)
I hope it won't stop scrolling new bytes in without stopping...
I haven't noticed any trouble, yet. Missing bytes I expect maybe. Reasonable to assume.
Last edit: Mikorians 2016-03-16
Try the ring buffer. It handles most things very quickly as it uses interrupts. You need to think about optimisation of the 'other' and how you handle the incoming data.
Recommend also a good scan of the new help. There is masses of new functionality that you can leverage in the libraries.
I have generated my own solution:
Dim EOF as Bit
Set EOF On
Set EOF On
and just before each SerData = xxxx:
Set EOF Off
Now with Rx blocking off, I can use HserReceive var
in a loop and know if a 255 character was received WITHOUT interrupt usage
or other synchonizatipn bytes.
I hope someone can benefit from this suggestion.
Thanks all!
Last edit: Mikorians 2016-03-18
Some general advice, strongly advised to do stuff in this posting.
As usart.h can be updated (it will be in the next few days) I strongly recommend a better approach to ensure your changes are not lost during upgrades.
Add Dim OEF in your main program,
then, take a copy of Sub HSerReceive and place in your mail code. Change the sub name to Sub myHSerReceive
Then, may your changes,
then, finally add some at the top of the main program #define HSerReceive myHSerReceive.
This will redirect all calls to HSerReceive to your routine.
Downside? there is... if you wanted to use any of the other HSerReceive routines (there is more than one in the later versions of Great Cow BASIC) you would have to copy and rename to myHSerReceive.
Upside? You do not loose theses critical changes when you upgrade.
We will issue a compile upgrade and a lot on .h files are refreshed often... make these changes recommended and you will not risk losing your good work.
Everyone, yes, heed Anobium.
My example is only that- Not meant for permanent use.
(aside) But I am 'settled in' I don't update until major versions release,
and keep copious notes and backup copies. As everyone should.
I re-read carefully what Anobium suggested again- It's very clever.
I just love this language.
I can compare the source with the asm, and use in-line asm too.
So cool. Makes using Pics a breeze. I have 9 networked together now
with a 3-wire pull-up, then a hardware serial to a Raspberry Pi.
If only pyserial weren't so slow. Even at 115k.
Can't figure out what I'm doing wrong.
Last edit: Mikorians 2016-03-18
☺
Do you still have issues? I cannot tell from your last sentence.
Nope. Not with GCB. Just my RPI.