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 <g...@cortexrf.com.au> 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 >> Freetel-codec2@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1] > > ------------------------------------------------------------------------------ > > _______________________________________________ > Freetel-codec2 mailing list > Freetel-codec2@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 [1] Links: ------ [1] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
_______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
