Hi Nick thanks for the comment I hadn't noticed the 8 next to the int and assumed 16bit still not quite use to working back in the micro world.
Any how the problem still persists if I set _SS_MAX_RX_BUFF to 63, 127 or anything other than 2^n i still get timing issues.
Im currently using 127 for testing, but will revamp the code to use 16 bit in the end as I may need more than 256.
With 127 and original code I get the following corruption at 19.2k
$G¨Ô? ??ÅÉ`37,???KLK&%?©Å
$G¨Ô? ??ÅÉd36,???KLK&%?©Å
As a quick test I modified the code as follows to see if its the root of the problem
The original code does the mod twice which is a waste of cycles and we all know ISRs should be as fast as poss.
// if ((_receive_buffer_tail + 1) % _SS_MAX_RX_BUFF != _receive_buffer_head)
uint8_t calc_once = (_receive_buffer_tail + 1) % _SS_MAX_RX_BUFF;
if (calc_once != _receive_buffer_head)
{
// save new data in buffer: tail points to where byte goes
_receive_buffer[_receive_buffer_tail] = d; // save new byte
// _receive_buffer_tail = (_receive_buffer_tail + 1) % _SS_MAX_RX_BUFF;
_receive_buffer_tail = calc_once;
}
else
.....
Now the corruption is quite a bit less
$GPGGA,000825.8³6,,,,,0,0,,¬�?¦,
$GPGGA,000826.0³7,,,,,0,0,,¬�?¦,
So I am on the right track.
I will remove the mod and add some IF-BUT code to do the buffer loop which may fix the problem.
As a side note I will do some testing to see how much faster the mod is when its power 2, it could be optimised by the compiler to be a simple logical AND in that specific case which would be very fast.
I will post anything interesting.