I recently bought a couple of DSD TECH BT-05 Bluetooth Serial Modules as I was finding it increasingly difficult to debug my PIC project – before I was using LEDs as flags. So much better when you can get values back !
Then the realization that you can now communicate with the PIC from your phone and voilà a new world – so if you’ve not looked at serial comms then you should – the BT-05 modules are so good and easy to configure.
Then came a problem that I’ve not tracked down in the compiled code. I needed to convert RPM to timer count values and vice versa so I could use the phone to receive measured RPM and to send RPM setting.
The 15000000 came from 10000000 * 60 / Timer1Interval and the Timer1Interval is 4 (uS) and cAdjust is a byte – 132 that compensates for a timing error caused by a few instruction cycles and interrupt latency.
rxRPM was received from an HSerGetNum.
Madness prevailed – I discovered that the PIC (16LF18323) could send the calculated RPM or it could receive the RPM setting … but not both !
The compiled code resulted in corruption where nothing worked properly and the chip ended up going through a watchdog timer reset loop and lots of “strange” behaviour.
No matter what I tried, if the two calculations existed together then the compiled result didn’t work and had nothing to do with using serial comms.
Not to be defeated, I solved it by using script to calculate constant values and reducing the complexity of the calculations :
So, amazingly, from a solar powered tiny novelty motor, I can actually interrogate and control it from my phone – and it’s now consuming less than 50uA !
Question ? At chip startup, the USART sends one undefined character – any ideas why and how I can stop it ?
I just love PICs ... a constant source of mental challenges ... maybe prevents dementia too ?!
Cheers,
Andrew
Last edit: Andrew Jameson 2024-08-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These devices are just so cool. The compiler is very impressive - I'm a purist, so I often go through the compiled code to optimize it ... however, I usually find that the compiler's output is very good and better than mine !
Tried using ChatGPT and it too can be damned good but often it's not optimal code and it takes some "tweaking" with the query to get ChatGPT to produce efficient code .
Cheers
Andrew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm ... found it but don't know why !
The test program loops through a WDT reset every 8 seconds ...
During my initialization, OSCCON1, OSCFRQ registers are set (you may recollect that, ever the purist and for the sake of portability, I like to know what registers are set). But in order to utilize the "real" power of GCBasic, I had to remove my overloaded blank call to InitSys, that now means that there are exact duplicate register initialise settings. Obviously the solution is that I will comment them out and keep them in the main body for reference but why is it triggering a couple of garbage characters ?
The other thing that I found was that the register settings T1CON, CCP1CAP, CCP1CON actually stop the serial communication - on my main program this is not the case but in this test program they do.
Been a long day - thought that I'd play with the code to read battery volts via a serial link but that code was really minimal and of course no garbage characters ! Bad thing is that I failed to read battery volts - but that's over in another thread.
#config RSTOSC = HFINT1 // Power-up default value for COSC bits->HFINTOSC (1MHz)
Then, I would remove all the OSC code.
And, you have killed the PPS routine by adding the PPS stuff at the bottom. PPS needs be added very early in the process. Hence, the #startup initpps. So, put that back. And, I would add the PPS to the CCP1 is required.
So try this does this put the bad char on serial? This is a baseline I could test against. There are many issues in the code above. So, start with this.
#chip 16lf18323, 1#option explicit ; All variables must be declared#config RSTOSC = HFINT1 // Power-up default value for COSC bits->HFINTOSC (1MHz)#config BOREN = Off ; BOREN - Brown-out reset disabled#config CP = Off ; Program memory code protection disabled#config MCLRE = Off ; MCLR - Reset function disabled#config WDT = On ; Watchdog Timer support enabled'#config LPBOREN = On ; Enable low power BOR - Brown-out reset#config BORV = Low ; Brown-out reset voltage (VBOR) set to 1.9V#config PWRTE = On ; Enable powerup delay timer - approx. 64mS#Startup initpps, 85subinitppsCCP1PPS=0b00000010;���xxxPPS[4:0]RXPPS=0x0013'RC3 --> RXRC4PPS=0x0014'RC4 <-- TXendsub#scriptT1CON_TICKS=PS1_1cWDTCON_8Secs=0b00011010cCCP_Compare=0b10001010;CCPComparemode.cCCP_Capture_CW=0b10000100;CCPCapturemode,everyfallingedge-Clockwise.cCCP_Capture_CCW=0b10000101;CCPCapturemode,everyrisingedge-Anticlockwise.;^xxxx;^-CCP1Enable.#endscriptWDTCON=cWDTCON_8Secs;SetWatchdogTimerto8secs.#define USART_BAUD_RATE 9600#define USART_BLOCKING#define USART_DELAY Off;-------------------------------------------------------------------------------;MAINPROGRAMLOOP;-------------------------------------------------------------------------------HSerPrintCRLFWait1sHSerPrint"Starting ..."HSerPrintCRLFdoforeverHSerPrint"Hello World"HSerPrintCRLFWait1sloopend
Last edit: Anobium 2024-08-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have just tried the code above. The WDT activates and I get no odd characters when the WDT happens. I am using a serial TTL and terminal and not the BT thing. I have made a video.
Maybe try a serial terminal to see if this isolates the issue to the BT connection.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I may have found the issue in the errata for that chip.
When the EUSART module is enabled (SPEN =
1) with the transmit function disabled (TXEN =
0), the TX assigned pin is driven low.
Work around
Load the desired logic level into the
corresponding LATx register and assign the I/O
function via the PPS output register.
subinitppsCCP1PPS=0b00000010;���xxxPPS[4:0]RXPPS=0x0013'RC3 --> RX RC4PPS = 0x0014 'RC4<--TXTXEN=1SPEN=1end sub
As initpps is called at the appropiate time setring TXEN and SPEN here will workaround any issue with the TX assigned pin being driven low.
NOTE: I am not seeing this issue here but my revision of the chip may be different.
#chip 16lf18323, 1#option explicit ; All variables must be declared//#config RSTOSC = HFINT1 // Power-up default value for COSC bits->HFINTOSC (1MHz)#config BOREN = Off ; BOREN - Brown-out reset disabled#config CP = Off ; Program memory code protection disabled#config MCLRE = Off ; MCLR - Reset function disabled#config WDT = On ; Watchdog Timer support enabled'#config LPBOREN = On ; Enable low power BOR - Brown-out reset#config BORV = Low ; Brown-out reset voltage (VBOR) set to 1.9V#config PWRTE = On ; Enable powerup delay timer - approx. 64mS#Startup initpps, 85subinitppsCCP1PPS=0b00000010;���xxxPPS[4:0]RXPPS=0x0013'RC3 --> RXRa5PPS=0x0014'RC4 <-- TXSPEN=1TXEN=1endsub#scriptT1CON_TICKS=PS1_1cWDTCON_8Secs=0b00011010cCCP_Compare=0b10001010;CCPComparemode.cCCP_Capture_CW=0b10000100;CCPCapturemode,everyfallingedge-Clockwise.cCCP_Capture_CCW=0b10000101;CCPCapturemode,everyrisingedge-Anticlockwise.;^xxxx;^-CCP1Enable.#endscriptWDTCON=cWDTCON_8Secs;SetWatchdogTimerto8secs.#define USART_BAUD_RATE 9600#define USART_BLOCKING#define USART_DELAY Off;-------------------------------------------------------------------------------;MAINPROGRAMLOOP;-------------------------------------------------------------------------------HSerPrintCRLFWait1sHSerPrint"Starting ..."HSerPrintCRLFdoforeverHSerPrint"Hello World"HSerPrintCRLFWait1sloopend
Last edit: Anobium 2024-08-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for making you feel like that! Apologies. I was getting a fast response out - my fault.
Issues with the code.
Initsys was being called anyway. This means that the OSCON registers are being set twice and there is no check the the OSC is running when the registers are changed the second time.
Initsys can be prevented from running but it is a hack.
PPSInit needs to be called early in the start of the chip. Some critical PPS items must be set first. Specifically, the serial registers. Having PPS run on line 90,91 may work but anything that is dependent on the serial working will fail.
Setting the interrupt bits... you have no interrupt handler. I actually do not know what will happen when an interrupt event occurs. I would always recommend ON INTERRUPT blabla CALL blablaISR - this will ensure the interrupt handler is correctly managed.
I would recommend not using TRISx. Why? Because DIR works it it 100% more readable.
All the PORTx set to 0. Repeated as this happens in INITSYS. Same of ANSEL.
I love the use of the script. Very good usage.
My quick review,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tried adding :
TXEN = 1
SPEN = 1
but no different - actually think that a lot of it might just be the BT serial interface itself and the terminal software on my phone ... tried one on my PC and the characters aren't displayed but are there when viewed as hex.
Thank goodness for CookFood.net - wife's away at the moment - so "home alone" just me and the dog !
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'll do what I can ... Jane's home tomorrow, so she becomes my priority (without any programmed interrupts) ... cancer keeps us busy but still positive and I do need a distraction.
To explain, I collated all my register calls into one block from my project - the complete project has all the interrupt handlers ... I'll get a video done soon and maybe share the project code ... I'm too old to think about selling physical products ... still got 3D Scrabble just lying around and need to think about getting that back out there - 4 years of my life creating that !
Someone else pursued a similar idea : https://www.tomlawton.com/uplift-20
They no longer make them but I got one ... my idea though is pure engineering, spinning slow takes no power - something running at 1000 - 2000 RPM at 2.5V / 50uA 24/7 is the challenge and to be self-starting.
Last edit: Andrew Jameson 2024-08-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for explaining. This code is trying to find a root cause of an issue so it is important to ensure the program is minimal/good practice. Typically, I am debugging some odd conditions and i do try to make the code understandable for the time I work on it. I am old and I need it easy.... :-)
What a cool project!! wow
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well as they say up North ... "I'll go t' foot of our stairs !" ... Don't know what they say up here in Perthshire - should do as I'm Scottish and from near Edinburgh (which never really was recognized for being Scottish ... ).
Couldn't find a 100K ... too popular a value in home projects so tried a 910K pullup on the RX pin (RC4) and it worked immediately ! (The TX pin (RC3) actually has a 1M pulldown - only when the BT interface is connected does the pin test high.) I have to be careful and frugal with pullup / down usage - 100K can represent 30uA consumption.
That was a brilliant thought !
I'll get back to some domestic chores and make it look like I've been busy !
Many thanks,
Andrew
❤️
2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Amazing !
I recently bought a couple of DSD TECH BT-05 Bluetooth Serial Modules as I was finding it increasingly difficult to debug my PIC project – before I was using LEDs as flags. So much better when you can get values back !
Then the realization that you can now communicate with the PIC from your phone and voilà a new world – so if you’ve not looked at serial comms then you should – the BT-05 modules are so good and easy to configure.
Then came a problem that I’ve not tracked down in the compiled code. I needed to convert RPM to timer count values and vice versa so I could use the phone to receive measured RPM and to send RPM setting.
TargetRPM = (1000000 * 60 / (rxRPM * Timer1Interval)) - cAdjust
HSerPrint (15000000 / (RotateTimer + cAdjust))
The 15000000 came from 10000000 * 60 / Timer1Interval and the Timer1Interval is 4 (uS) and cAdjust is a byte – 132 that compensates for a timing error caused by a few instruction cycles and interrupt latency.
rxRPM was received from an HSerGetNum.
Madness prevailed – I discovered that the PIC (16LF18323) could send the calculated RPM or it could receive the RPM setting … but not both !
The compiled code resulted in corruption where nothing worked properly and the chip ended up going through a watchdog timer reset loop and lots of “strange” behaviour.
No matter what I tried, if the two calculations existed together then the compiled result didn’t work and had nothing to do with using serial comms.
Not to be defeated, I solved it by using script to calculate constant values and reducing the complexity of the calculations :
TargetRPM = (cRPMFactor / rxRPM) - cAdjust
HSerPrint (cRPMFactor / (RotateTimer + cAdjust))
So, amazingly, from a solar powered tiny novelty motor, I can actually interrogate and control it from my phone – and it’s now consuming less than 50uA !
Question ? At chip startup, the USART sends one undefined character – any ideas why and how I can stop it ?
I just love PICs ... a constant source of mental challenges ... maybe prevents dementia too ?!
Cheers,
Andrew
Last edit: Andrew Jameson 2024-08-10
Sounds like you are enjoying yourself! Too much. :-)
I use Scripts to do this type of heavy lifting. The constants are then very useful.
When you making a video ?
Re startup. I would have to see the full program. It could be several things but I do not know enough about program.
I am sure we can resolve.
Video in production ... Might be a week or so.
These devices are just so cool. The compiler is very impressive - I'm a purist, so I often go through the compiled code to optimize it ... however, I usually find that the compiler's output is very good and better than mine !
Tried using ChatGPT and it too can be damned good but often it's not optimal code and it takes some "tweaking" with the query to get ChatGPT to produce efficient code .
Cheers
Andrew
The compiler optimises what you write. If you write tight GCBASIC then the compiler will do its best.
Send me your code and I will have look at the errant serial characters.
Hmm ... found it but don't know why !
The test program loops through a WDT reset every 8 seconds ...
During my initialization, OSCCON1, OSCFRQ registers are set (you may recollect that, ever the purist and for the sake of portability, I like to know what registers are set). But in order to utilize the "real" power of GCBasic, I had to remove my overloaded blank call to InitSys, that now means that there are exact duplicate register initialise settings. Obviously the solution is that I will comment them out and keep them in the main body for reference but why is it triggering a couple of garbage characters ?
The other thing that I found was that the register settings T1CON, CCP1CAP, CCP1CON actually stop the serial communication - on my main program this is not the case but in this test program they do.
Been a long day - thought that I'd play with the code to read battery volts via a serial link but that code was really minimal and of course no garbage characters ! Bad thing is that I failed to read battery volts - but that's over in another thread.
Cheers Andrew
Ok. I see.
This could be resolved by adding
Then, I would remove all the OSC code.
And, you have killed the PPS routine by adding the PPS stuff at the bottom. PPS needs be added very early in the process. Hence, the
#startup initpps. So, put that back. And, I would add the PPS to the CCP1 is required.So try this does this put the bad char on serial? This is a baseline I could test against. There are many issues in the code above. So, start with this.
Last edit: Anobium 2024-08-13
I have just tried the code above. The WDT activates and I get no odd characters when the WDT happens. I am using a serial TTL and terminal and not the BT thing. I have made a video.
Maybe try a serial terminal to see if this isolates the issue to the BT connection.
I may have found the issue in the errata for that chip.
As initpps is called at the appropiate time setring TXEN and SPEN here will workaround any issue with the TX assigned pin being driven low.
NOTE: I am not seeing this issue here but my revision of the chip may be different.
Last edit: Anobium 2024-08-13
Wow that was quick !
Just feel as though I've been reprimanded but it's not that obvious what goes first and why.
It works now if I comment out the OSC settings - yes I watched the video and many of them !
As he says "I'll be back !" - got to eat sometime !
Thanks Andrew
(Would like to no more about what else that I'm doing wrong ?)
Sorry for making you feel like that! Apologies. I was getting a fast response out - my fault.
Issues with the code.
Initsys was being called anyway. This means that the OSCON registers are being set twice and there is no check the the OSC is running when the registers are changed the second time.
Initsys can be prevented from running but it is a hack.
PPSInit needs to be called early in the start of the chip. Some critical PPS items must be set first. Specifically, the serial registers. Having PPS run on line 90,91 may work but anything that is dependent on the serial working will fail.
Setting the interrupt bits... you have no interrupt handler. I actually do not know what will happen when an interrupt event occurs. I would always recommend ON INTERRUPT blabla CALL blablaISR - this will ensure the interrupt handler is correctly managed.
I would recommend not using TRISx. Why? Because DIR works it it 100% more readable.
All the PORTx set to 0. Repeated as this happens in INITSYS. Same of ANSEL.
I love the use of the script. Very good usage.
My quick review,
Tried adding :
TXEN = 1
SPEN = 1
but no different - actually think that a lot of it might just be the BT serial interface itself and the terminal software on my phone ... tried one on my PC and the characters aren't displayed but are there when viewed as hex.
Thank goodness for CookFood.net - wife's away at the moment - so "home alone" just me and the dog !
Checking ( I am ). Are you using the baseline code I posted?
and, you seeing odd hex chars in PC/Terminal ( see below) ?
Make this change. Then, post a screen shot of the PC terminal. I am looking for these odd characters.
Also, attach your latest ASM to the next post. I want to ensure that looks good. :-)
I'll do what I can ... Jane's home tomorrow, so she becomes my priority (without any programmed interrupts) ... cancer keeps us busy but still positive and I do need a distraction.
To explain, I collated all my register calls into one block from my project - the complete project has all the interrupt handlers ... I'll get a video done soon and maybe share the project code ... I'm too old to think about selling physical products ... still got 3D Scrabble just lying around and need to think about getting that back out there - 4 years of my life creating that !
Someone else pursued a similar idea :
https://www.tomlawton.com/uplift-20
They no longer make them but I got one ... my idea though is pure engineering, spinning slow takes no power - something running at 1000 - 2000 RPM at 2.5V / 50uA 24/7 is the challenge and to be self-starting.
Last edit: Andrew Jameson 2024-08-13
Of course, family first. So right.
Thanks for explaining. This code is trying to find a root cause of an issue so it is important to ensure the program is minimal/good practice. Typically, I am debugging some odd conditions and i do try to make the code understandable for the time I work on it. I am old and I need it easy.... :-)
What a cool project!! wow
I have had an idea. After taking apart my BT thingy.
As this relates to the TX line toggling when in communication with the BT adapter. Try adding a pull up resistor to the TX and RX lined. Try 100k.
Do a search for AN2606. Page 42.
Well as they say up North ... "I'll go t' foot of our stairs !" ... Don't know what they say up here in Perthshire - should do as I'm Scottish and from near Edinburgh (which never really was recognized for being Scottish ... ).
Couldn't find a 100K ... too popular a value in home projects so tried a 910K pullup on the RX pin (RC4) and it worked immediately ! (The TX pin (RC3) actually has a 1M pulldown - only when the BT interface is connected does the pin test high.) I have to be careful and frugal with pullup / down usage - 100K can represent 30uA consumption.
That was a brilliant thought !
I'll get back to some domestic chores and make it look like I've been busy !
Many thanks,
Andrew
AYE! Great news.
Let me know what R you end up with.
I ended up with 1M ... seems to work and every uA is precious !