When Using a both a PIC16F684 and PIC 16F690 when the baud rate is set for 9600 the actual TX baud rate is ~10,500. This represents an error of about %10 and is too high for most devices work with when set to 9600 baud,
To temporarily work around this, I tracked (at least part of the problem) to the
RS232.h library in the script where "SerFullDelay" is calculated. I changed the formula:
Well.... looks like rBitRateUnit is not used. I have not been able to locate a reference to this constant. I have looked at the source etc. The rBitRateUnit is not used in rs232.h - it seems very odd.
Have you been able to test other baud rates? and, at other frequencies?
I am thinking we could add a little more functionality to handle this issue but we would need more data to enable us to ensure compatibility across all the options.
Or, can you think of another way forward?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My testing shows all baud rates to be off by about 10% or more.
I suggest the following.
1. Independent verification of baud rate inaccuracy.
Someone needs to confirm what I am seeing.
2. Whoever authored the current RS232.H and stdbasic.h
files(Hugh?), might want to verify and check that
rBitRateUnit is working as intended. I suspect that it
is not. Changing its value has no effect upon serout
baud rates. Is it possibly only used for serial input?.
Code comments do not say.
3. I have modified the Rs232.h to get fairly accurate
serial output baud rates, but have no clue at this
point how these modifications will affect serial input
timings. At best, these are a workaround to a
deeper issue, that could possibly be easily corrected
by Hugh or whoever wrote the current code.
4. I am surprised that this has not been noticed before,
so previous versions of GCB could be tested to see
when the inaccuracy started.
a. Has it always been inaccurate?
b. Did the inacuracy begin with the latest release?
c. The previous one?
d. Were the soft serial baud rates accurate in the
older versions of GCB?
William
Last edit: William Roth 2014-07-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@1. We need someone with a protocol analyser. Not me.
@2. I will take this action. Get back with an answer.
@3. A way forward for you to minimise the impact of your change. Make your mods in your local file (main program) and leave the rs232.h alone until we get this sorted.
@4. Moved away from software to hardware serial via the USART. I did use a few years ago, had no issues with serial then but my target device would have been a PC so it may tolerate a greater level of inaccuracy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
William,
I think the issue has been there for some time as I recall having communication issues many years ago and couldn't figure out why and didn't take the time as you did to dig deeper. I found the slower baud rates i.e. 9600 seemed to work fine at 20 Mhz or less so the error was probably within tolerance.
I have just been using that setup when I needed this communication.
Your work has been very helpful. There have been changes that may or may not have made the issue worse and there is no way Hugh can test everything as GCB has grown so much in the last couple years. As a user I want to thank you for taking the time to diagnose this and hopefully somebody, with more knowledge than me of the inner workings of GCB, can help fix the issues you've found.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While personally, I use hardware serial whenever practical, software serial is a convenient way to add additional serial "ports", or to have RS232 serial functionality when the fixed hardware pin may be tied up. Also, not all PICS have a hardware serial
port, so with these chips, software serial is a must for serial comms.
With a serial tx error of ~%10 at 9600 baud, (10.5K actual), software serial will not work with many if not most terminal programs and will fail to communicate with many devices. I have not tested serial input accuracy/ tolerance.
Anobium suggested:
@3. A way forward for you to minimise the impact of your change. Make your mods in your local file (main program) and leave the rs232.h alone until we get this sorted.
The mods I made require modifying the script in rs232.h. Specifically these lines.
'20 MHz PIC, 10 us taken off - 50 instructions
SerFullDelay19200 = int(52 - 4 / ChipMHz * 45) 'change from 45 to 30
SerFullDelay9600 = int(104 - 4 / ChipMHz * 50) 'change from 50 to 35
SerFullDelay4800 = int(208 - 4 / ChipMHz * 50) 'change from 50 to 35
SerFullDelay2400 = int(417 - 4 / ChipMHz * 50) 'change from 50 to 35
SerFullDelay1200 = int(833 - 4 / ChipMHz * 50) 'change from 50 to 35
SerFullDelay600 = int(1666 - 4 / ChipMHz * 50) 'change from 50 to 35
SerFullDelay300 = int(3333 - 4 / ChipMHz * 50) 'change from 50 to 35
These will not compile when used in the main program, and has something to do with the "int" function not defined. So what you are suggesting may not be possible.
For what its worth I have made all the changes necessary to meet my personal needs for accurate software serial tx. My intent here is to help make software serial work
correctly for everyone.
EDIT: For about $12 US, you can get a "protocol analyzer" from Ebay. These are 8 channel logic analyzer "clones" that operate with saleae logic software. Built in protocol analyzers, for Async Serial, I2C, SPI, CAN, JTAG, and more.
Last edit: William Roth 2014-07-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When Using a both a PIC16F684 and PIC 16F690 when the baud rate is set for 9600 the actual TX baud rate is ~10,500. This represents an error of about %10 and is too high for most devices work with when set to 9600 baud,
To temporarily work around this, I tracked (at least part of the problem) to the
RS232.h library in the script where "SerFullDelay" is calculated. I changed the formula:
From: SerFullDelay9600 = int(104 - 4 / ChipMHz * 50)
To: SerFullDelay9600 = int(104 - 4 / ChipMHz * 38</B>)
This got the 9600 baud rate pretty close as reported by Saleae Logic, with the bit times between 103 to 105us. This only corrected the 9600 TX rate.
I also noticed a comment in the rs232.h file that says:
So I looked in stdbasic.h and found this in the script:
'Bit rate delays #define r300 64 #define r600 32 #define r1200 16 #define r2400 8 #define r4800 4 #define r9600 2 #define r19200 1 'Number to multiply above by to get correct delay length (us) #define rBitRateUnit 52Changing the value from 52 to 40 had no effect at all upon the serial TX baud rate.
Last edit: William Roth 2014-06-25
There has been no official response to my obesrvations on software serial.
Shall I assume that it is of no official importance ?
Hi - was busy on another issue.
Well.... looks like rBitRateUnit is not used. I have not been able to locate a reference to this constant. I have looked at the source etc. The rBitRateUnit is not used in rs232.h - it seems very odd.
Have you been able to test other baud rates? and, at other frequencies?
I am thinking we could add a little more functionality to handle this issue but we would need more data to enable us to ensure compatibility across all the options.
Or, can you think of another way forward?
My testing shows all baud rates to be off by about 10% or more.
I suggest the following.
1. Independent verification of baud rate inaccuracy. Someone needs to confirm what I am seeing. 2. Whoever authored the current RS232.H and stdbasic.h files(Hugh?), might want to verify and check that rBitRateUnit is working as intended. I suspect that it is not. Changing its value has no effect upon serout baud rates. Is it possibly only used for serial input?. Code comments do not say. 3. I have modified the Rs232.h to get fairly accurate serial output baud rates, but have no clue at this point how these modifications will affect serial input timings. At best, these are a workaround to a deeper issue, that could possibly be easily corrected by Hugh or whoever wrote the current code. 4. I am surprised that this has not been noticed before, so previous versions of GCB could be tested to see when the inaccuracy started. a. Has it always been inaccurate? b. Did the inacuracy begin with the latest release? c. The previous one? d. Were the soft serial baud rates accurate in the older versions of GCB?William
Last edit: William Roth 2014-07-13
See inline.
@1. We need someone with a protocol analyser. Not me.
@2. I will take this action. Get back with an answer.
@3. A way forward for you to minimise the impact of your change. Make your mods in your local file (main program) and leave the rs232.h alone until we get this sorted.
@4. Moved away from software to hardware serial via the USART. I did use a few years ago, had no issues with serial then but my target device would have been a PC so it may tolerate a greater level of inaccuracy.
Never had a use for 3 software UART's, so wrote my own alternate software USART routine
http://sourceforge.net/p/gcbasic/discussion/629990/thread/fffea3cf/#6407
Updated in this post, but with code format problems
http://sourceforge.net/p/gcbasic/discussion/579126/thread/13b0e115/#037a
No script written for bitrate delays to account for code overhead, or different clock rates. Bitrate delay was arrived at by trial and error.
William,
I think the issue has been there for some time as I recall having communication issues many years ago and couldn't figure out why and didn't take the time as you did to dig deeper. I found the slower baud rates i.e. 9600 seemed to work fine at 20 Mhz or less so the error was probably within tolerance.
I have just been using that setup when I needed this communication.
Your work has been very helpful. There have been changes that may or may not have made the issue worse and there is no way Hugh can test everything as GCB has grown so much in the last couple years. As a user I want to thank you for taking the time to diagnose this and hopefully somebody, with more knowledge than me of the inner workings of GCB, can help fix the issues you've found.
While personally, I use hardware serial whenever practical, software serial is a convenient way to add additional serial "ports", or to have RS232 serial functionality when the fixed hardware pin may be tied up. Also, not all PICS have a hardware serial
port, so with these chips, software serial is a must for serial comms.
With a serial tx error of ~%10 at 9600 baud, (10.5K actual), software serial will not work with many if not most terminal programs and will fail to communicate with many devices. I have not tested serial input accuracy/ tolerance.
Anobium suggested:
The mods I made require modifying the script in rs232.h. Specifically these lines.
These will not compile when used in the main program, and has something to do with the "int" function not defined. So what you are suggesting may not be possible.
For what its worth I have made all the changes necessary to meet my personal needs for accurate software serial tx. My intent here is to help make software serial work
correctly for everyone.
EDIT: For about $12 US, you can get a "protocol analyzer" from Ebay. These are 8 channel logic analyzer "clones" that operate with saleae logic software. Built in protocol analyzers, for Async Serial, I2C, SPI, CAN, JTAG, and more.
Last edit: William Roth 2014-07-15