"Simply sticking in another interrupt could result in
something as simple as an audible "tick" every time a char is
received"
No, that is not the case.
Even the time between each audio sample - ahh what is it 16ksps is
62.5 microseconds
and in 62.5uS that is 10,500 instructions ! the interrupt wil
consume perhaps 100 tops.
the processor wont notice the interrupt. that's the whole idea of
an interrupt....
50 cycles...100 cycles... you have 168 million per second... to go
around.
on the PIC24 how to you guard the flags and indexes ? IE make the
operations atomic ?
otherwise you could be reading the flags and indexes etc while the
DMA is updating those same variables
so you have different problems the way you describe.
POLLING though will NOT work in the case of a CAT setup. why ?
because if the serial connection is say 9600 bps that s a char
every millisecond, and with a buffer say 4 bytes deep 4mS worse,
but the time the codec gets around to finishing the current block
of encoding and gets to your polling algorithm, the sender will
have over run the input USART FIFO.....
hence use of the interrupt handler to empty the usart.....
The main reason I said can't do a software FIFO is because it
needs to be an interrupt and there is little documentation I
have found on the main code structure, let alone a flow diagram.
So I have no idea of code over heads or interrupt priority.
Simply sticking in another interrupt could result in something
as simple as an audible "tick" every time a char is received or
worst case result in a loss of synchronization every time a char
is received.
Sort of reverse engineering all the code I haven't found a
resource that lets me determine how and where to best implement
the serial coms.
On say a PIC24 I can just let it fill the buffer and then test
the flags to see if chars are present.
That would be easy to do and the test would be as simple in code
as checking the switches.
If you think there is so much over head then I will just give
it a try in software and see what happens.
Thanks.
Eric
On 2016-09-07 01:01, Bruce Perens wrote:
> So,
anything that happens in the usart interrupt handler is transparent to the codec encoder
Except for timing. But
Brady has already explained that it's timing-insensitive.
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
|
------------------------------------------------------------------------------
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
