[ECOS] problem with synchronization

[ECOS] problem with synchronization

[Rafael Rodríguez Velilla]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3374 bytes --]

  I'm working with eCos 1.3.1 in an ARM7TDMI processor

  I have written a little assembler routine to attend my serial IRQs (in
order to make a bug with the USART less harmful)
  The idea is to have a thread where I use these functions:
manda_buffer_enviar(buffer_pointer, length_of_the_buffer,
time_for_timeout);   // For sending
lee_buffer_recibido(buffer_pointer, length_of_the_buffer,
time_for_timeout);      // For receiving
  To send and receive (respectively) a stream through the serial line.

 I have made the USART produce a FIQ, so I use cyg_interrupt_set_vsr to
substitute the FIQ to my custom routine (to speed up serial transactions)
 I want to sleep the calling thread of these routines till the buffer is
full (when receiving) or it is empty (when sending), then the FIQ routine
should check if the buffer is full (or empty) and awake the thread.
 The FIQ simply sends or receives a character while it has space in the
buffer, when the buffer is full (or empty if it is transmitting) it
disables the generation of the FIQand should awake the thread that made the
call.

  I also want to set a timeout, in order to awake the thread if too much
time is spent without receiving (or sending) chars.
  I have implemented this with flags (timed flags) but it only works
correctly for the sending side, the receiving side doesn't set the timer
when I use cyg_flg_timed_wait, because it returns inmediatly returning
false.
  The courious thing is that it works coerrectly in the sending side, but
not in the receiving and both use the same method of sleeping and
awaking....

  I have tried to use, instead of flags, the pair cyg_thread_delay (in the
calling side) - cyg_thread_release (in the FIQ side), but this doesn't
work, I have tried to track what happens with this combination and I've
discover (don't know exactly how) that after calling cyg_thread_release my
main thread is exited !!!! (why does it suicide instead of awaking?)


  Please, take a look at the code and tell me if I'm doing something wrong.
I attach two files, vectors.S contains the code corresponding to the FIQ
routine, and seriel_FIQ.c contains the initialization routine, the calling
routines and the FIQ disabling routines.

  Do you suggest any other synchronization method?

  The FIQ calls termina_rutina_fiq_rx (termina_rutina_fiq_tx) when the
buffer is full (empty) if it is receiving (sending) data.  These routines
should awake the thread that has to process the serial data.

  To test I have used the following inside a lonely thread:

  inicializa_puerto_serie
  for (aux=1;aux<=20;aux++) {
     manda_buffer_enviar(prueba,aux,100);  // 1 second of timeout (ata
19200 bauds it is loooooong enough)
  }  // this works correctly
  for(aux=1;aux<=20;aux++) {
    lee_buffer_recibido(prueba,aux,300); // This doesn't wait till data
arraives at the serial port (and it should)
    manda_buffer_enviar(prueba,aux,100);  //This prints the buffer as it
was before calling lee_buffer_recibido.
 }


  I'm pretty sure that the FIQ routine is correctly programmed, because it
I don't make it awake the thread at the end of the FIQ (I let it awake by
timeout) it awakes correctly (so, the context is correctly saved). Besides,
the TRANSMITING side WORKS!!!










--
Rafael Rodríguez Velilla        rrv@tid.es
Telefónica I+D          http://www.tid.es
Telf: +34 - 91 337 4270

Re: [ECOS] problem with synchronization

[Robin Farine]

Hi Rafael,

I'm way too lazy to look deaply in your code. Though one thing rings a bell, in
general you should not use eCos services from FIQ mode. To check that's actually
your problem, try using an IRQ instead which triggers a DSR to invoke
cyg_flag_setbits() (if its not safe to call it from an interrupt handler).

Robin

Re: [ECOS] problem with synchronization

[Rafael Rodríguez Velilla]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2217 bytes --]

  I have reviewed my own code (I can understand why you feel lazy to read my 'not
neat' code) and I have discover a mistake (in my code):

  cyg_flag_timed_wait expects an absolute time for the timeout, and I supplied only
the time I wanted to wait (I have resloved this just adding to the timeout the
value of cyg_current_time().   .... I hope this helps someone else.

  This doesn't solve my problem because my thread is not correctly awoken... but
now the timer is set correctly.

  So I suppose that the problem is in how the thread switch happens after I set the
flag.

  The idea of using the ISR-DSR scheme to set the flag in the DSR is not applicable
for me. I'm using a processor runnig at 0.8MHz, a memory of 8 bits with an extra
WAIT state (don't ask me why do I have a micro of 32bits with an 8 bit memory) so
any instructions takes 8 cycles to be read, and I have a buggy embedded USART
without buffer(I have to twist the bits that I want to send and read)...  so the
time till the ISR is activated is enough to overrun characters (this is not true if
I set the serial speed to 400 bauds... no way).

  I understand that you feel like reviewing my code (it bores me too) so I'll make
some questions instead of throwing new code...

1.- As Robin insinuated... Is it unsafe to call cyg_flag_setbits inside an ISR?
2.- What do I have to do to guarantee a safe thread-switch? I think that the
processor mode is not relevant, it is only relevant having the stack pointer
pointing into the thread's stack (so no other thread or IRQ can mess around it), if
this is true, actually I'm not doing it correctly (I'll continue with my work to
mend it). If anyone has the gold rules to prepare for a thread-switch, please let
me know.


  Thank you for your attention.


> I'm way too lazy to look deaply in your code. Though one thing rings a bell, in
> general you should not use eCos services from FIQ mode. To check that's actually
> your problem, try using an IRQ instead which triggers a DSR to invoke
> cyg_flag_setbits() (if its not safe to call it from an interrupt handler).
>
> Robin

--
Rafael Rodríguez Velilla        rrv@tid.es
Telefónica I+D          http://www.tid.es
Telf: +34 - 91 337 4270

Re: [ECOS] problem with synchronization

[Jonathan Larmour]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]

Rafael Rodríguez Velilla wrote:
> 
> 1.- As Robin insinuated... Is it unsafe to call cyg_flag_setbits inside an ISR?

Yes it is unsafe.

> 2.- What do I have to do to guarantee a safe thread-switch? I think that the
> processor mode is not relevant, it is only relevant having the stack pointer
> pointing into the thread's stack (so no other thread or IRQ can mess around it), if
> this is true, actually I'm not doing it correctly (I'll continue with my work to
> mend it). If anyone has the gold rules to prepare for a thread-switch, please let

When you use the setbits, that causes a reschedule. The stack pointer will
be wrong, and the system will not expect that it is in a FIQ context.

If you are not using DSRs, then effectively you are working outside the
eCos kernel, so don't try and use kernel primitives. Perhaps the easiest
route may just be to dump stuff in a buffer, and have a thread just poll
that buffer. Then at least all rx data is saved. If that isn't an option,
then at least you can make your FIQ more like an ISR by making it invoke a
DSR in exactly the same way as a "standard" FIQ would. Then you will
hopefully have had enough time to grab the rx data, stick it in a buffer
and re-enable interrupts. The risk with this approach though is that if
your CPU is sufficiently slow and loaded, it may spend all its time
processing ISRs, and never reach the DSR.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/

Re: [ECOS] problem with synchronization

[Rafael Rodríguez Velilla]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2155 bytes --]

Jonathan Larmour wrote:

> Rafael Rodríguez Velilla wrote:
> >
> > 1.- As Robin insinuated... Is it unsafe to call cyg_flag_setbits inside an ISR?
>
> Yes it is unsafe.

  Then, any operation that can produce a thread switch must be called outside of th
eISR, right?


> > 2.- What do I have to do to guarantee a safe thread-switch? I think that the
> > processor mode is not relevant, it is only relevant having the stack pointer
> > pointing into the thread's stack (so no other thread or IRQ can mess around it), if
> > this is true, actually I'm not doing it correctly (I'll continue with my work to
> > mend it). If anyone has the gold rules to prepare for a thread-switch, please let
>
> When you use the setbits, that causes a reschedule. The stack pointer will
> be wrong, and the system will not expect that it is in a FIQ context.
>
> If you are not using DSRs, then effectively you are working outside the
> eCos kernel, so don't try and use kernel primitives. Perhaps the easiest
> route may just be to dump stuff in a buffer, and have a thread just poll
> that buffer. Then at least all rx data is saved. If that isn't an option,
> then at least you can make your FIQ more like an ISR by making it invoke a
> DSR in exactly the same way as a "standard" FIQ would. Then you will
> hopefully have had enough time to grab the rx data, stick it in a buffer
> and re-enable interrupts. The risk with this approach though is that if
> your CPU is sufficiently slow and loaded, it may spend all its time
> processing ISRs, and never reach the DSR.

  Yes. I have just tried this approach and it seems to fit perfectly.
  As the serial communication happens in fixed length streams this approach is perfect
for me.
  My FIQ now posts a DSR when it receives all the buffer or sends it all and it seems to
work perfectly (and I have spent 10 times less to program the new routine).

  Thank you for your hint... I've learnt something... if the kernel does it for you just
use it ... and I was reinventing the DSR for the FIQ.



--
Rafael Rodríguez Velilla        rrv@tid.es
Telefónica I+D          http://www.tid.es
Telf: +34 - 91 337 4270