Sounds Promising. I will be keen to know what the results may be.
Attached is my project before I started experimenting with the PIC18F16Q40. I still plan on staying with this new chip, but I'm curious if I could get this board to work in Great Cow Basic.
The PIC is a PIC18F46K22 and it looks like PPS does not cover this chip currently. The closest is the PIC18F46K40 which is covered, but it looks like the PPS needs an exact match.
How easy would it be to ad the PIC18F46K22 to the PPS setup? The board has the same components has my dev board (GPS, 2 USARTS, 1 I2C, Northern software programmer).
Both chips are setup in the same way:
One USART provides 2 way communication from the microcontroller to the GPS
2nd USART provides 2 way communication from the microcontroller to the Northern software serial USB (NS handles the USB part)
I2C provides communication to the Si5351a Clock generator. (breadboard is using the Adafruit version, while my board is directly using the Si5351a)
The code for my board was written in MikroElekronica's MikroBasic compiler, but I've grown VERY fond of GCB is a very short amount of time!
Anyway, I apologize if you lost sleep over the frequency count issue. I can tell you I'm having real fun now that I switch compilers
There is only 1 Usart.h in the install and you found it.
Looks correct to me unless I am missing something. In any case the Word and integer variables are now printing correctly. No missing digits and no extra digits.
IF there is still an issue please describe in as much detail as possible.
Edit: I see that there are digits missing still. Did you recompile and reprogram?
Suggest you apply the most current patch to get completely up to date. This will contain the latest usart.h as well as fixes and additions.
I think I'm going to move on. By multiplying by a factor of 10 the true frequency is only a few tens of hertz off. 1 hertz accuracy is not needed in my application. I've spent too much time on this already and I've coaxed you to spend too much time on it as well! Maybe its a bug in the chip even though the chip is only slightly different.
I tried another frequency generator and still the same truncation. If you have an extra DIP Q41 lying around that you tested with I'll certainly try over here and send it back.
I'm losing the plot on the project overall frequency calibration is just a small part of the project as a whole. I do have a manual way of adjusting the crystal reference offset if I do want to achieve 1 Hz accuracy but its really overkill in my application.
Again I'd be willing to test over here what you have been working with if you are curious.
Jeff
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There was definitely a bug in usart.h causing the output to be incorrect for Word and Integer variables when using hserprint . This affected both USART1 and USART2 but only when USART2 was used. The new usart.h corrects that.
Attached is a .gcb program that will test the USARTs and put them through the paces.
Make no changes to this program. Connect TX1 and TX2 (C.6 and C.0) to Serial Adapters/Terminal Apps.
Program and view/compare the output of each USART. Outputs should match my screen shots.
I redownloaded the usart.h and confirmed it is indeed the latest. I see the following comment in the usart.h file:
' 22/08/2022 Revised HSerPrint and HSerPrintRC to ensure HSerSend uses Byte, Byte overloaded method. Fixes USART1 and USART2 overwrite/corruption issue
Attached are my runs on both USART1 and USART2. I had to make a hardware wiring temporary change to get USART1 to send to the Northern Software serial usb. Both captures show the same result.
I re-ran the PulseCount and still have a 10s truncation.
Here's what I read and send to USART2 currently :
SMT1CPWU = 10
SMT1CPWH =189
SMT1CPWL = 251
Frequency Count = 703995
It seems to get a value of 7039950,
Byte SMT1CPWU has to be at LEAST in the 100s ...
SMT1CPWU = 107
SMT1CPWH =107
SMT1CPWL = 110
Real Frequency Count = 7039950
I did hard code this and sent through USART2:
PulseCount = 7039950
and my readout is : 7039950 I suspect its not the USART as this hard code did not truncate at all. I saw the correct value coming over from HSerPrint.
I think you should be reading the SMT1TMR registers since it is set up as a COUNTER. This will give you the number of leading edges for 1 second. In your case it should be ~ 7,000,000. So you need a long ALIAS for these. I will call this ALIAS "SMT1_COUNTER"
Dim Dummy_Byte
Dim SMT1_COUNTER, as Long ALIAS Dummy_Byte, SMT1TMRU, SMT1TMRH,SMT1TMRL
SMT1_COUNTER = 0 '// Clear all bytes to zero.
Place this in you code then read out these individual bytes like you did with the PW register.
SMT1_COUNTER = 7000000
Should be:
SMT1TMRU = 106
SMT1TMRH = 207
SMT1TMRL = 192 (or close depending upon the accuracy of the 1 second gate pulse)
In operation, If the actual frequency is 7.003950MHz, then the SMT1TMR registers will be close to:
Didn't make any changes to original way SMT was configured from your code - Still a Gated Counter.
The original variable PulseCount was set up with the SMTTMR bytes as you authored:
'Orginal - Existing
Dim DUMMY as Byte : Dummy = 0
Dim PulseCount Alias DUMMY,SMT1TMRU,SMT1TMRH,SMT1TMRL AS LONG
'New from last post
Dim Dummy_Byte as Byte: Dummy_Byte = 0
Dim SMT1_COUNTER, as Long ALIAS Dummy_Byte, SMT1TMRU, SMT1TMRH,SMT1TMRL
SMT1_COUNTER = 0
Both sets of variable return exactly the same numbers:
Edit: I also switched bands and now counting on the 20 meter (14Mhz) frequency band. Whatever is happening, it is extremely consistent throughout the bands I'm testing, all the way to 50 Mhz. All band show the degree of accuracy are only a few 10s of Hz off the true frequency as read by a commercial frequency counter.
(Assuming I apply a x10 multiplier after)
Last edit: Jeff Weinmann 2022-08-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sounds Promising. I will be keen to know what the results may be.
Attached is my project before I started experimenting with the PIC18F16Q40. I still plan on staying with this new chip, but I'm curious if I could get this board to work in Great Cow Basic.
The PIC is a PIC18F46K22 and it looks like PPS does not cover this chip currently. The closest is the PIC18F46K40 which is covered, but it looks like the PPS needs an exact match.
How easy would it be to ad the PIC18F46K22 to the PPS setup? The board has the same components has my dev board (GPS, 2 USARTS, 1 I2C, Northern software programmer).
Both chips are setup in the same way:
The code for my board was written in MikroElekronica's MikroBasic compiler, but I've grown VERY fond of GCB is a very short amount of time!
Anyway, I apologize if you lost sleep over the frequency count issue. I can tell you I'm having real fun now that I switch compilers
Jeff
The K22 are NOT PPS chip. This means the functionality is locked to the pins specified in the datasheet. So, you cannot 'add' PPS to a non PPS chip.
Hope this helps.
Yes another reason not to go back to that chip. Thanks for the info
@Jeff
I believe I have isolated a bug in the usart.h that is causing the issue you have with missing digits and extra digits in the serial outputs.
Attached is a new usart.h file testing. ( Works well on my end)
EDIT: File was updated! Please download again if downloaded before this edit.
Please test and let us know how it does.
William
Last edit: William Roth 2022-08-22
Morning William,
I get similar numbers:
40 Meters (7 Mhz):
SMT1CPWU = 10
SMT1CPWH =189
SMT1CPWL = 251
Frequency Count = 703995
20 Meters (14 Mhz):
SMT1CPWU = 21
SMT1CPWH =130
SMT1CPWL = 144
Frequency Count = 1409680
Now I may have not replaced the correct include file. I'm assuming this path to the usart.h:
C:\GCB@Syn\GreatCowBasic\Include\lowlevel\usart.h
The new file shows a size of 57,344 bytes (size on disk)
Jeff
There is only 1 Usart.h in the install and you found it.
Looks correct to me unless I am missing something. In any case the Word and integer variables are now printing correctly. No missing digits and no extra digits.
IF there is still an issue please describe in as much detail as possible.
Edit: I see that there are digits missing still. Did you recompile and reprogram?
Suggest you apply the most current patch to get completely up to date. This will contain the latest usart.h as well as fixes and additions.
https://sourceforge.net/projects/gcbasic/files/Release%20Candidates/Patches/
If you are using GCStudio it should automatically update
William
Last edit: William Roth 2022-08-22
William,
I think I'm going to move on. By multiplying by a factor of 10 the true frequency is only a few tens of hertz off. 1 hertz accuracy is not needed in my application. I've spent too much time on this already and I've coaxed you to spend too much time on it as well! Maybe its a bug in the chip even though the chip is only slightly different.
I tried another frequency generator and still the same truncation. If you have an extra DIP Q41 lying around that you tested with I'll certainly try over here and send it back.
I'm losing the plot on the project overall frequency calibration is just a small part of the project as a whole. I do have a manual way of adjusting the crystal reference offset if I do want to achieve 1 Hz accuracy but its really overkill in my application.
Again I'd be willing to test over here what you have been working with if you are curious.
Jeff
Hi Jeff,
There was definitely a bug in usart.h causing the output to be incorrect for Word and Integer variables when using hserprint . This affected both USART1 and USART2 but only when USART2 was used. The new usart.h corrects that.
Attached is a .gcb program that will test the USARTs and put them through the paces.
Make no changes to this program. Connect TX1 and TX2 (C.6 and C.0) to Serial Adapters/Terminal Apps.
Program and view/compare the output of each USART. Outputs should match my screen shots.
Last edit: William Roth 2022-08-23
@Jeff,
As Bill is stating - there was an issue in the library. You must update the library else you will get inconsistent results.
No need to * 10... use the revised .H library
I redownloaded the usart.h and confirmed it is indeed the latest. I see the following comment in the usart.h file:
' 22/08/2022 Revised HSerPrint and HSerPrintRC to ensure HSerSend uses Byte, Byte overloaded method. Fixes USART1 and USART2 overwrite/corruption issue
Attached are my runs on both USART1 and USART2. I had to make a hardware wiring temporary change to get USART1 to send to the Northern Software serial usb. Both captures show the same result.
I re-ran the PulseCount and still have a 10s truncation.
Here's what I read and send to USART2 currently :
SMT1CPWU = 10
SMT1CPWH =189
SMT1CPWL = 251
Frequency Count = 703995
It seems to get a value of 7039950,
Byte SMT1CPWU has to be at LEAST in the 100s ...
SMT1CPWU = 107
SMT1CPWH =107
SMT1CPWL = 110
Real Frequency Count = 7039950
I did hard code this and sent through USART2:
PulseCount = 7039950
and my readout is : 7039950 I suspect its not the USART as this hard code did not truncate at all. I saw the correct value coming over from HSerPrint.
Head scratcher!
Last edit: Jeff Weinmann 2022-08-23
I think you should be reading the SMT1TMR registers since it is set up as a COUNTER. This will give you the number of leading edges for 1 second. In your case it should be ~ 7,000,000. So you need a long ALIAS for these. I will call this ALIAS "SMT1_COUNTER"
Dim Dummy_Byte
Dim SMT1_COUNTER, as Long ALIAS Dummy_Byte, SMT1TMRU, SMT1TMRH,SMT1TMRL
SMT1_COUNTER = 0 '// Clear all bytes to zero.
Place this in you code then read out these individual bytes like you did with the PW register.
SMT1_COUNTER = 7000000
Should be:
SMT1TMRU = 106
SMT1TMRH = 207
SMT1TMRL = 192 (or close depending upon the accuracy of the 1 second gate pulse)
In operation, If the actual frequency is 7.003950MHz, then the SMT1TMR registers will be close to:
SMT1TMRU =106
SMT1TMRH = 223
SMT1TMRL = 46 ( or thereabouts)
This is what the microcontroller's USART2 should be sending to the GPS if this is in the range of what the GPS is looking for.
I am assuming that you made no changes to SMT mode that I set up originally. If you did then all bets are off.
William
Last edit: William Roth 2022-08-24
William,
Didn't make any changes to original way SMT was configured from your code - Still a Gated Counter.
The original variable PulseCount was set up with the SMTTMR bytes as you authored:
Both sets of variable return exactly the same numbers:
SMT1_COUNTER= 1409711
SMT1TMRU = 21
SMT1TMRH = 130
SMT1TMRL = 175
Very consistent
Edit: I also switched bands and now counting on the 20 meter (14Mhz) frequency band. Whatever is happening, it is extremely consistent throughout the bands I'm testing, all the way to 50 Mhz. All band show the degree of accuracy are only a few 10s of Hz off the true frequency as read by a commercial frequency counter.
(Assuming I apply a x10 multiplier after)
Last edit: Jeff Weinmann 2022-08-24