Hi Rob, > 1. You moved the disabling of transmit interrupts to a point after the last > byte has been transmitted. My original reasoning was to avoid an unnecessary > transmit interrupt when there would be nothing more to transmit. That may go > wrong when the application presents another byte at a critical point in time > while the 'last' byte is being transmitted (e.g. while handling other > interrupts). This is what actually fixed the issue. I think it is related to the exact timing of the buffer-empty vs the put char (i've been there before). But to be honest, I can't point out what was wrong...
> 2. You made the buffer 'pointers' volatile. Being non-volatile could be the > reason that 'buffer full' or 'buffer empty' situations were not always > detected correctly. This was my first thought too, but it (at least on itself) did not fix the issue. Anyway, I guess this is as it is supposed to be. > I suppose you have tested the changes thoroughly. I'll repeat my tests as > well. No thorough tests yet, but it fixed an issue I ran into and works as expected in my app. >> I also suspect 'serial_overflow_discard=true' might not work properly >> with the 'put procedure... > > > Did you observe mal behaviour? No, I never want to loose chars (even if it messes up my timing). But if I understand correct: the serial_overflow_discard=true makes serial_send_byte() to exit on buffer full, with serial_send_success=false. As a result serial_hw_data'put() will try again. So no discard... Joep -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
