|
|
View previous topic :: View next topic |
Author |
Message |
12Lapointep
Joined: 04 Aug 2015 Posts: 16 Location: United States
|
Ex_STISR.C Buffer size |
Posted: Tue Aug 25, 2015 8:53 am |
|
|
Hey all,
I am currently working on the circular buffer with the PIC18F67J94 and I was wondering about the size of the buffer. How big can it be? For example, the UART will have a 'one' deep hardware buffer that will trigger the interrupt for the circular buffer. How big can that circular buffer be considering the math in my code will make it rollover no matter what? |
|
|
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Tue Aug 25, 2015 9:10 am |
|
|
Circular buffers can be whatever size you want them to be, provided there's enough RAM of course. You can make them rollover whereever you need. Obviously there's no point in allocating more memory for them, and then not using it: the rollver maths should match the buffer size.
Generally there's some idea of how long the buffers need to be. Its related to how many characters can arrive while some long operation is taking place, or perhaps to expected message length. In the "old days" it was fairly common for serial buffers to hold a little over 80 characters, as that was the length of a line on most VDUs and some sent the whole line when it got to the end rather than character by character.
On PICs, its better to have a buffer size that's a power of two, as that makes the maths simple and helps to avoid the "interrupts disabled" warning on divisions.
There's also the question of what to do when the buffer overflows: ignore the new character or keep it and scrap the oldest one instead. Some applications work better one way, some the other. Some buffering schemes, especially in days gone by, did flow control by monitoring how much was in the buffer. WHen the buffer got, say, to 90% full they'd send an XOFF or negated CTS or whatever, allowing some overrun, then when the buffer got to, say, 80% turn the flow back on.
Last edited by RF_Developer on Tue Aug 25, 2015 9:18 am; edited 1 time in total |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19549
|
|
Posted: Tue Aug 25, 2015 9:17 am |
|
|
STISR, is for transmit, not receive. It doesn't generally matter how long your maths takes. If you can accept pauses in the output, or you don't actually have the data prepared, you may not even need a buffer.... |
|
|
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Tue Aug 25, 2015 9:22 am |
|
|
Ttelmah wrote: | STISR, is for transmit, not receive. It doesn't generally matter how long your maths takes. If you can accept pauses in the output, or you don't actually have the data prepared, you may not even need a buffer.... |
Indeed. Having buffering give you the ability to make transmit calls non-blocking, which is favourable in systems applications, but often not a whole lot of use in a standalone, single-thread embedded situation, as in most PIC code. I dont usually buffer serial transmissions, and therefore rarely use serial transmit interrupts. |
|
|
12Lapointep
Joined: 04 Aug 2015 Posts: 16 Location: United States
|
2 Circular buffer |
Posted: Tue Aug 25, 2015 11:44 am |
|
|
Lets say I receive data in my circular buffer and than send it to the main program. It will output a different string of data to another circular buffer and then transmit it back to the computer. How would I go about achieving this? |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|