It won't result in an audible click or glitch in the modulator output. The DACs and ADCs are being driven by the STM32's DMA from 20ms buffers. Once a buffer is half empty/full, the DMA peripheral triggers an interrupt, which then copies to/from an 80ms FIFO. Once enough samples are on the incoming FIFO (~40ms), freedv_tx or freedv_rx are called in main. Even if an interrupt from the UART hits during the DMA service routine, it won't cause any problems.
On Tue, Sep 6, 2016 at 11:39 PM, <[email protected]> wrote: > 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. > > On Tue, Sep 6, 2016 at 3:56 PM, glen english <[email protected]> wrote: > >> Eric. you said : "you can not implement a software FIFO on interrupt >> because this would effect the other processes every time a byte is >> received." >> >> That is not really the case .I'll explain. >> >> the interrupt handler will push the used registers, SP etc onto the >> stack on entry to the IRQ handler, and restore them when it is done. >> So, anything that happens in the usart interrupt handler is >> transparent to the codec encoder- it wont ever know there was an >> interrupt. The compiler will deal with all that for you. Yes I know in >> asm days, life was different. >> >> but I guess you already know the above.. maybe the case of cycles >> >> There are plenty of online examples. >> >> Essentially on stm32 >> >> on IRQ entry >> >> read USART->SR into a variable >> if there are errors , read the DR. >> this will clear errors. it will also get a char if there was one there. >> >> if there were no errors , but the RXNE / fifo flag was set, and you have >> not read the DR already, read the DR and put your new char into your ram >> buffer, increment the buffer ptr index, wrap as required and increment >> the nChars variable so your app knows how many chars there are >> >> if the TXE flag was set, the usart wants another char, get from your ram >> buffer and write to the DR, inc buffer ptr, and -- nChars to tx. >> >> done. >> >> now, in your application, you need sample the nchars waiting to tx, and >> n chars ready to get from the buffer variables, and because the irq >> context also has access to those registers, you need to guard >> application access (ie non irq context) by using critial sections . in >> the simplist form that is disabling and enablign interrupts around those >> variables >> >> NOW !!!!! >> >> there are some very handy synchronization opcodes you can use in the ARM >> instruction set to do this!!! >> if you want- no need for critical sections and disabling interrupts. >> >> g >> >> >> >> >> ------------------------------------------------------------ >> ------------------ >> _______________________________________________ >> Freetel-codec2 mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > > > ------------------------------------------------------------------------------ > > > _______________________________________________ > Freetel-codec2 mailing > [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
