Hi,
I've got an (Oshonsoft) program where there's a area for me to add my MAIN CODE!
I was told that it has to use little time, so it doesn't affect the working CODE (I'm not used to this)

What I want to know, is estimates of different times for different lines of CODE.
e,g,
SEROUT with a STRING of variables
or
a page of CODE.

This may be a bit vague, but I have to get the feel for what's needed.
Camerart.

 

Any serout will take lots of time compared to a regular block of code. Serout at 9600 baud takes about 1ms per character, but code runs thousands of instructions in that same 1ms.

 

Any serout will take lots of time compared to a regular block of code. Serout at 9600 baud takes about 1ms per character, but code runs thousands of instructions in that same 1ms.

Hi S,
Ok, thanks.

I'm trying to get the SERVO CODE working, that you may recall in another thread.
In the CODE is a GPS READ section, into BUFF(X) I want to copy BUFF(x) into another buffer, and prove that it's been copied. I usually use SEROUT and a computer terminal, as a monitor.
How can I check this another way, please?
C

 

Make sure any serout is in the main code (loop) where it does not interfere with any interrupts or other timing routines.
Another way to check is to add logic in the main code to verify the buffer data is in the correct format (as expected) and simply turn on a LED or do a serout with only a couple of characters instead of the whole string. If the buffer has a bad format, use a different LED or output a short error string but never the full buffer, that may take too long.
Regardless, if you are getting too many strings from the GPS, your SEROUT and other code will take too much time to parse and output all the data via SEROUT. Reduce the number of GPS data strings for testing, and only once things work, increase the frequency of data. Start with once every second or two. Reduce the GPS data strings to a minimal size as well, and remove any unwanted strings being sent. In reality, you probably only need a couple GPS strings to get all your data.
SEROUT is software driven, a very poor way to debug code. Your SEROUT data may be displayed corrupted even if the buffer data is correct. That is because interrupt routines can interfere with the timing routines of a SEROUT routine. You would be better trying I2C or SPI to send the debug data to another processor that can then display the data to your terminal without any interference from other code. In other words, set up a processor for debugging only, connected to your main processor via some hardware driven interface. Then any serial data display does not interfere with you main processor.

 

Make sure any serout is in the main code (loop) where it does not interfere with any interrupts or other timing routines.
Another way to check is to add logic in the main code to verify the buffer data is in the correct format (as expected) and simply turn on a LED or do a serout with only a couple of characters instead of the whole string. If the buffer has a bad format, use a different LED or output a short error string but never the full buffer, that may take too long.
Regardless, if you are getting too many strings from the GPS, your SEROUT and other code will take too much time to parse and output all the data via SEROUT. Reduce the number of GPS data strings for testing, and only once things work, increase the frequency of data. Start with once every second or two. Reduce the GPS data strings to a minimal size as well, and remove any unwanted strings being sent. In reality, you probably only need a couple GPS strings to get all your data.
SEROUT is software driven, a very poor way to debug code. Your SEROUT data may be displayed corrupted even if the buffer data is correct. That is because interrupt routines can interfere with the timing routines of a SEROUT routine. You would be better trying I2C or SPI to send the debug data to another processor that can then display the data to your terminal without any interference from other code. In other words, set up a processor for debugging only, connected to your main processor via some hardware driven interface. Then any serial data display does not interfere with you main processor.

Hi S,
Ok, thanks.
I use the main loop, for the SEROUTs. The GPS sentence starts with $ and ends with W, so if I use $, plus one of the sentence initials, e,g, M and W, this is only 3x characters.

I am puzzled though, as I expect the control code to be pages long, so must take some time. Will this add enough time to make the servos judder?
C

 

If the servo is interrupt driven, the main code should not affect it, unless you are disabling interrupts at some point in the code and then re-enabling it later.
Interrupt code takes priority over mainline code.

 

If the servo is interrupt driven, the main code should not affect it, unless you are disabling interrupts at some point in the code and then re-enabling it later.
Interrupt code takes priority over mainline code.

Hi S,
In my project there are 2x SLAVE programs.
1/ GPS/QEI (incremental encoder)
2/ GPS/SERVO
As I'm getting mixed up between the two, it's probably better that I go back to the GPS/SERVO CODE THREAD on ETO, and leave this thread for GPS/QEI, if that's ok with you.
C