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
