Hi William, I tried removing the HSerSend line and there may have been a small improvement in the error rate, but I think that the interrupt delay is still the main problem. I was hoping to do something with the PCM function of the PIC, but it seems that you can't get below about 1KHz with the 16MHz clock in the PIC. As you know, I'm using servos that need about a 50Hz clock. Do you know of any way around this? Thanks, Terry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You never have said what the project is. I have guessed that it may be for a telescope that has an adjustable objective lens. Correct me if I am wrong and please tell us what it is.
Are you married to the 16F1829 or are you willing to upgrade to 18F16Q4x ? This will cost you about $2 us or so. ( Plus Shipping) Your answer will determine the direction and approach to get your project going.
Now I will sort of answer your question. Yes there is a way around the1IKHz lower limit but it requires jumping through a few hoops. I first need to know how many actually servos you are controlling. I see that there are 2 for "tilt". But am unsure of what the "bump" stuff is. Servos or motors ? It appears that the adjustable objective lens ( focus) uses a motor with 2 encoders or maybe 2 motors and 2 encoders. You have not provided the details .
So the bottom line here is that I need to know how many 50 Hz servo signals you need to generate ?
Without that information I cannot help you any further. It would be a waste of my time and yours.
William
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi William, OK – the device is for focusing and guiding an astronomical telescope. The focus part is pretty straightforward, as it just involves a DC motor with a gearbox and a rotary optical encoder on the output shaft. It’s the ‘Tip-Tilt’ servos that need the continuous 50Hz pulse train, as these are used to rapidly move an optical window to cancel out gear errors and vibration, by refracting the image by a few pixels in both North-South and East-West directions. There are only two servos, so that’s the PWM requirement – I just need to adjust the pulse width between 1 and 2mS on the two channels. The ‘Bump’ command is just a coarse adjustment to the mount drive motors when the mechanical drift becomes too great for the refractive element to compensate. The bump is an intermittent short pulse (about 100mS), sent via opto-couplers, so no need for interrupts to handle this.
I’m not wedded to the 1829, but the test board is built with one, so it would be convenient to use it. The 18F16Q4 devices seem to be in short supply in the UK, but I can probably get some, if necessary.
Regards, Terry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now that I know what your project is, I can provide you with better help. I will try to mock up something here with 2 servos and the serial data stuff. To refract the image only a few pixels likely requires pretty fine resolution of the servo pulse, depending upon how much motion you get in relation to the servo pulse width. I will keep that in mind. Also we need to make sure there are no glitches in the servos while other operations are taking place otherwise image quality will suffer.
I do not have an 1829 to test with, but I do have several 1825's which is the same chip but only 14 pins. I can test well enough to tell if the 1829 can actually do what you need, but we will need to restructure code a bit to prevent serial data errors as this is most likely caused by the timer interrupt . The UART's on these chips are rock solid as is the background GCB library.
There are both short commands and long commands where a command can be either 1 byte or 7 bytes. This is unusual as most devices use a fixed packet size. A fixed packet size of 7 bytes is less taxing than having a variable packet size. Also there is no handshaking between the PIC and whatever is sending the data to it.
Question 1: Is the data packet protocol fixed or can it be changed so that all commands are 7 bytes? I mean are we stuck with the ways it is now or can we modify?
Question 2: Can we add code that tells whatever it is that sends the data to the PIC that the PICs is busy and to wait until it is not busy to send more data?
Question 3: Was the code that you provided the actual code that will receive the data? It appears to be written to receive data from a terminal app and not from any kind of commercial software. My guess is that there is some kind of commercial software that you will be using instead of a terminal app. Can you share what that is and if it has specs can you provide ? Like the serial protocol that it uses? I know the baud should be 9600 what I am asking for is the specifics such a handshaking ( if any) and stuff like that.
What I am proposing is a more robust protocol than I see in your code so that the PIC will not miss data, and the code execution will not hang if there is an error of some kind. As it is, it will hang if there is an error on the first command byte ( or any byte really) . So we need to eliminate serial RX "blocking" if possible and use a timeout if the next byte is not received correctly... and to add some ACK/NAK handshaking stuff. Is this OK or are we stuck with it as it is in your example code?
William
Last edit: William Roth 2023-01-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi William, Most things are possible. The reason for the current format is that I'm using an old version of a Visual C# control program that was written by a friend for an old version of this hardware. I was aiming for backward compatibility, but that isn't essential. The single byte commands are not especially important to its function (just version requests and 'repeat previous action' commands). Please feel free to modify the code to give good stability.
Terry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Therefore I need to know how the Control Program works in order to determine what methods to use. Does the control program send serial commands to the PIC control board at any given time? My guess is that it does.
In any case the 16F1829 will not be adequate for several reasons.
A 50 Hz interrupt CAN be generated with 16-bit Timer 1. We just have to preload the timer value as the first line in the PWMhandler routine.
However this method of generating a PWM means that an interrupt is triggered every 20 ms. This means that any code that is executing at the time the interrupt is triggered with be stopped for duration of the interrupt handler routine. There will be serial data issues as well as encoder/motor issues using this method. I can see the serial problems now that I have a short program running that can replicate the errors
What needs to be done is to wait for the first byte to be received from the command software then get the next 6 bytes and then execute the command, while in the background the PWM is always running and does not us an interrupt that will interfere with other critical operations like reading the encoder or receiving serial data.
The 16F1829 is simply not capable of generating a 50Hz PWM using its PWM(CCP) modules while the chip operates at 16MHz. This chip can only use the 8-bit timers for generating the PWM Clock so you can never get to 50Hz and the PWM resolution would be poor even if you could. However some newer chips can do all this quite well.
I will do some research and see which chips can do what we need to do. I really like the Q series 18F chips ( amazing features), but there may be some others that are adequate. I have about 50 different PIC's here to to test with most of them modern ones. The 16F1829 is ~13 year old technology.
I still need to know how the command software works or is it a work in progress ? Do you sit at a screen and click on stuff to tell the telescope what to do ? Is is configurable ? Is the communication between the control software and the control board bi-directional?
Them more details you can provide ( especially how it communicates with the control board/Pic is paramount to developing the code for the PIC.
William
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will write some well-commented example code based upon your original code as I have a fair idea of what the code needs to do. I can test here with 2 servos and I can use a 2nd microcontroller to simulate the focus motor encoder and send pulses to the PIC. Should be fun.
William
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have code now using 2 PWM's for the 2 servos while sending and receiving data with no errors at up to 57600 baud. So 9600 is no problem.
The code has been restructured to eliminate the 'goto's' and instead uses 'select case' to call various subroutines depending upon the command byte (sdata(1). The data is received using GCB's 'HserGetString' routine. No interrupts are necessary with this method.
However, HserGetString required that the Command Software or Terminal be configured to send a CR ( Carriage Return) at the end of each data packet (string). This is a quite common and accepted method use to tell the microcontroller that all data bytes have been sent, and the packet is complete. This takes a big load off of the microcontroller and allows variable length packets without the microcontroller having to jump through hoops.
Most similar applications add a checksum to the end of each packet to verify the data and use handshaking so that the command software knows that the data was not corrupted, and that the microcontroller is ready to receive the next data packet. We will add that later depending upon the capability/functionality of your command software, but I do think you need some kind of error checking to prevent any potentially disastrous conditions .
I will post the code after I get it all cleaned up and ready for review and further testing. I am about halfway there. It will be a day or more.
William
Last edit: William Roth 2023-01-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My apologies, but I forgot to ask you what programmer device you are using.
Newer chips such as 18F16Q40 are not natively supported by Pickit2/3 as Microchip abandoned support for PK2/3 years ago. There are several options available.
Pickit 4 Programmer - Expensive . Works OK . Requires installing MPLAB IPE
SNAP Programmer - Cheap - Works OK. Requires installing MPLAB IPE
PickitPlus. Software allows using PK2 & PK3 with all 8-bit PICs including the latest.
Kept up to date. https://pickitplus.co.uk
My personal recommendation is PicKitPlus. Well worth the money. Excellent support
Next would be the SNAP
Last would be PK4
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi William,
I have the Snap programmer to hand, but it sounds like the PicKitPlus software is worth a look.
I'm currently assembling a board with the 18F16Q40 in place of the 16F1829, so it should be ready to try by Thursday.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I took the liberty to make significant changes to your original code. The code will be well commented so please read though and study it before testing so that you have some understanding of the code structure and the methods that I used
There is a lot of relevant information and details that you have not yet provided. In these cases I just guessed. So there will likely need to be changes to the code. It is a work in progress that will need to to be modified by you in order to complete.
William
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I developed the code with an 18FQ41 so you will need change the #chip definition at the top of the file. You have probably already figured this out. The file attached below has this change.
The PIC 18G16Q40 is a PPS enabled microcontroller. This means that the peripheral outputs can be mapped/assigned to nearly any I/0 pin. I used the same pins that you used in your sample code. However you can change them using PPS if you so desire. So you are not constrained to the fixed assignment of peripheral outputs of the 1829. For example you can assign Serial TX to Port B.6 instead of PortB.7. This also goes for the PWM outputs. Use the PPSTool that came with your installation. You should be using GCB's latest version.
Also the 18F16Q40 has 3 USARTS. So it is quite possible to have one USART send debug data to a Terminal and another send data to the Command Software.
If you need help with anything else, like setting up a new programmer or new programmer software let us know.
Thanks William. As you say, I have selected the 18F16Q40 as the chip. I've got most of the functions working with a terminal program, so it's looking good. The servos respond correctly and do not appear to cause any COM port problems. The mount output is also OK. I need to test the focus operation and will do this over the weekend. Many thanks for your work on this!
Terry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi William, I tried removing the HSerSend line and there may have been a small improvement in the error rate, but I think that the interrupt delay is still the main problem. I was hoping to do something with the PCM function of the PIC, but it seems that you can't get below about 1KHz with the 16MHz clock in the PIC. As you know, I'm using servos that need about a 50Hz clock. Do you know of any way around this? Thanks, Terry
You never have said what the project is. I have guessed that it may be for a telescope that has an adjustable objective lens. Correct me if I am wrong and please tell us what it is.
Are you married to the 16F1829 or are you willing to upgrade to 18F16Q4x ? This will cost you about $2 us or so. ( Plus Shipping) Your answer will determine the direction and approach to get your project going.
Now I will sort of answer your question. Yes there is a way around the1IKHz lower limit but it requires jumping through a few hoops. I first need to know how many actually servos you are controlling. I see that there are 2 for "tilt". But am unsure of what the "bump" stuff is. Servos or motors ? It appears that the adjustable objective lens ( focus) uses a motor with 2 encoders or maybe 2 motors and 2 encoders. You have not provided the details .
So the bottom line here is that I need to know how many 50 Hz servo signals you need to generate ?
Without that information I cannot help you any further. It would be a waste of my time and yours.
William
Hi William, OK – the device is for focusing and guiding an astronomical telescope. The focus part is pretty straightforward, as it just involves a DC motor with a gearbox and a rotary optical encoder on the output shaft. It’s the ‘Tip-Tilt’ servos that need the continuous 50Hz pulse train, as these are used to rapidly move an optical window to cancel out gear errors and vibration, by refracting the image by a few pixels in both North-South and East-West directions. There are only two servos, so that’s the PWM requirement – I just need to adjust the pulse width between 1 and 2mS on the two channels. The ‘Bump’ command is just a coarse adjustment to the mount drive motors when the mechanical drift becomes too great for the refractive element to compensate. The bump is an intermittent short pulse (about 100mS), sent via opto-couplers, so no need for interrupts to handle this.
I’m not wedded to the 1829, but the test board is built with one, so it would be convenient to use it. The 18F16Q4 devices seem to be in short supply in the UK, but I can probably get some, if necessary.
Regards, Terry
Hi Terry,
Now that I know what your project is, I can provide you with better help. I will try to mock up something here with 2 servos and the serial data stuff. To refract the image only a few pixels likely requires pretty fine resolution of the servo pulse, depending upon how much motion you get in relation to the servo pulse width. I will keep that in mind. Also we need to make sure there are no glitches in the servos while other operations are taking place otherwise image quality will suffer.
I do not have an 1829 to test with, but I do have several 1825's which is the same chip but only 14 pins. I can test well enough to tell if the 1829 can actually do what you need, but we will need to restructure code a bit to prevent serial data errors as this is most likely caused by the timer interrupt . The UART's on these chips are rock solid as is the background GCB library.
There are both short commands and long commands where a command can be either 1 byte or 7 bytes. This is unusual as most devices use a fixed packet size. A fixed packet size of 7 bytes is less taxing than having a variable packet size. Also there is no handshaking between the PIC and whatever is sending the data to it.
Question 1: Is the data packet protocol fixed or can it be changed so that all commands are 7 bytes? I mean are we stuck with the ways it is now or can we modify?
Question 2: Can we add code that tells whatever it is that sends the data to the PIC that the PICs is busy and to wait until it is not busy to send more data?
Question 3: Was the code that you provided the actual code that will receive the data? It appears to be written to receive data from a terminal app and not from any kind of commercial software. My guess is that there is some kind of commercial software that you will be using instead of a terminal app. Can you share what that is and if it has specs can you provide ? Like the serial protocol that it uses? I know the baud should be 9600 what I am asking for is the specifics such a handshaking ( if any) and stuff like that.
What I am proposing is a more robust protocol than I see in your code so that the PIC will not miss data, and the code execution will not hang if there is an error of some kind. As it is, it will hang if there is an error on the first command byte ( or any byte really) . So we need to eliminate serial RX "blocking" if possible and use a timeout if the next byte is not received correctly... and to add some ACK/NAK handshaking stuff. Is this OK or are we stuck with it as it is in your example code?
William
Last edit: William Roth 2023-01-20
Hi William, Most things are possible. The reason for the current format is that I'm using an old version of a Visual C# control program that was written by a friend for an old version of this hardware. I was aiming for backward compatibility, but that isn't essential. The single byte commands are not especially important to its function (just version requests and 'repeat previous action' commands). Please feel free to modify the code to give good stability.
Terry
Therefore I need to know how the Control Program works in order to determine what methods to use. Does the control program send serial commands to the PIC control board at any given time? My guess is that it does.
In any case the 16F1829 will not be adequate for several reasons.
A 50 Hz interrupt CAN be generated with 16-bit Timer 1. We just have to preload the timer value as the first line in the PWMhandler routine.
However this method of generating a PWM means that an interrupt is triggered every 20 ms. This means that any code that is executing at the time the interrupt is triggered with be stopped for duration of the interrupt handler routine. There will be serial data issues as well as encoder/motor issues using this method. I can see the serial problems now that I have a short program running that can replicate the errors
What needs to be done is to wait for the first byte to be received from the command software then get the next 6 bytes and then execute the command, while in the background the PWM is always running and does not us an interrupt that will interfere with other critical operations like reading the encoder or receiving serial data.
The 16F1829 is simply not capable of generating a 50Hz PWM using its PWM(CCP) modules while the chip operates at 16MHz. This chip can only use the 8-bit timers for generating the PWM Clock so you can never get to 50Hz and the PWM resolution would be poor even if you could. However some newer chips can do all this quite well.
I will do some research and see which chips can do what we need to do. I really like the Q series 18F chips ( amazing features), but there may be some others that are adequate. I have about 50 different PIC's here to to test with most of them modern ones. The 16F1829 is ~13 year old technology.
I still need to know how the command software works or is it a work in progress ? Do you sit at a screen and click on stuff to tell the telescope what to do ? Is is configurable ? Is the communication between the control software and the control board bi-directional?
Them more details you can provide ( especially how it communicates with the control board/Pic is paramount to developing the code for the PIC.
William
To get 50Hz PWM with 1us resolution for Servos and where a timer interrupt is unnecessary, I recommend the following microcontrollers.
PIC16F1776 - 28 Pin
PIC16F1778 - 28 Pin
PIC18F16Q40 - 20 Pin
PIC18F16Q41 - 20 Pin
PIC18F27Q43 - 28-Pin
Last edit: William Roth 2023-01-21
Thanks William – I think that the 18F16Q40 is my best bet. It is available and will fit my PCB.
Terry
Great!
I will write some well-commented example code based upon your original code as I have a fair idea of what the code needs to do. I can test here with 2 servos and I can use a 2nd microcontroller to simulate the focus motor encoder and send pulses to the PIC. Should be fun.
William
@Terry Platt
Let me know when you have ordered/received the new chip(s) and I will begin. Until then I will put this on hold.
Hi William,
The chips are on order and are expected to arrive by Friday, 27th Jan.
@Terry Platt
Excellent.
I have code now using 2 PWM's for the 2 servos while sending and receiving data with no errors at up to 57600 baud. So 9600 is no problem.
The code has been restructured to eliminate the 'goto's' and instead uses 'select case' to call various subroutines depending upon the command byte (sdata(1). The data is received using GCB's 'HserGetString' routine. No interrupts are necessary with this method.
However, HserGetString required that the Command Software or Terminal be configured to send a CR ( Carriage Return) at the end of each data packet (string). This is a quite common and accepted method use to tell the microcontroller that all data bytes have been sent, and the packet is complete. This takes a big load off of the microcontroller and allows variable length packets without the microcontroller having to jump through hoops.
Most similar applications add a checksum to the end of each packet to verify the data and use handshaking so that the command software knows that the data was not corrupted, and that the microcontroller is ready to receive the next data packet. We will add that later depending upon the capability/functionality of your command software, but I do think you need some kind of error checking to prevent any potentially disastrous conditions .
I will post the code after I get it all cleaned up and ready for review and further testing. I am about halfway there. It will be a day or more.
William
Last edit: William Roth 2023-01-24
@Terry Platt
My apologies, but I forgot to ask you what programmer device you are using.
Newer chips such as 18F16Q40 are not natively supported by Pickit2/3 as Microchip abandoned support for PK2/3 years ago. There are several options available.
Pickit 4 Programmer - Expensive . Works OK . Requires installing MPLAB IPE
SNAP Programmer - Cheap - Works OK. Requires installing MPLAB IPE
PickitPlus. Software allows using PK2 & PK3 with all 8-bit PICs including the latest.
Kept up to date. https://pickitplus.co.uk
My personal recommendation is PicKitPlus. Well worth the money. Excellent support
Next would be the SNAP
Last would be PK4
Hi William,
I have the Snap programmer to hand, but it sounds like the PicKitPlus software is worth a look.
I'm currently assembling a board with the 18F16Q40 in place of the 16F1829, so it should be ready to try by Thursday.
Great.
I have a bunch of code for you to test.
I took the liberty to make significant changes to your original code. The code will be well commented so please read though and study it before testing so that you have some understanding of the code structure and the methods that I used
There is a lot of relevant information and details that you have not yet provided. In these cases I just guessed. So there will likely need to be changes to the code. It is a work in progress that will need to to be modified by you in order to complete.
William
Many thanks William - the board is ready to go, so please let me have a link to the firmware when you are ready.
Terry
Here is a test program to study and try. You will need to make changes and additions as necessary.
Read the subroutine headers for the Tilt, Mount and Focus Subroutines. They give the command usage.
Example: GN1 Adjusts the servo pulse width by 10 us.
Example: F100 Runs the FocusOut Motor for 100 ms
Have fun.
Edit: I fixed a minor formatting bug in the ReadTemperature sub routine. Download again to get the updated code.
Last edit: William Roth 2023-02-01
Many thanks William - I'll see what it does.
Terry
@Terry Platt
Just a heads up.
I developed the code with an 18FQ41 so you will need change the #chip definition at the top of the file. You have probably already figured this out. The file attached below has this change.
The PIC 18G16Q40 is a PPS enabled microcontroller. This means that the peripheral outputs can be mapped/assigned to nearly any I/0 pin. I used the same pins that you used in your sample code. However you can change them using PPS if you so desire. So you are not constrained to the fixed assignment of peripheral outputs of the 1829. For example you can assign Serial TX to Port B.6 instead of PortB.7. This also goes for the PWM outputs. Use the PPSTool that came with your installation. You should be using GCB's latest version.
Also the 18F16Q40 has 3 USARTS. So it is quite possible to have one USART send debug data to a Terminal and another send data to the Command Software.
If you need help with anything else, like setting up a new programmer or new programmer software let us know.
Last edit: William Roth 2023-02-03
Thanks William. As you say, I have selected the 18F16Q40 as the chip. I've got most of the functions working with a terminal program, so it's looking good. The servos respond correctly and do not appear to cause any COM port problems. The mount output is also OK. I need to test the focus operation and will do this over the weekend. Many thanks for your work on this!
Terry