Re: [ECOS] Timecritical interrupt-debuging ... printf in DSR's ... Cyg_Scheduler_Implementation::rem_thread() ... cyg_assert_fail()

["oliver munz @ s p e a g" <munz at speag dot ch>]

Thanks for Your hints.

The soulution whit the high-priority thread is interessting. At the moment
I'm happy whit printf() on a standard buffered serial-line. When set to
non-blocking-mode via "retcode = cyg_io_set_config(comms[2],
CYG_IO_SET_CONFIG_SERIAL_WRITE_BLOCKING, &m, &n);" I lose characters, but
the DSR is running whitout timing- or kernel-problems...

Greatings
Oliver Munz


> Another thing you can consider is make a first pass at the driver using a
> high-priority thread to service the device, instead of the DSR. Just have
> the DSR signal the thread using a semaphore or similar. Than you can then
> send a fair amount of debug output to a hardware-driven serial port (from
> the thread context)  and still remain within the timing constraints of
> USB. You may just need to try responding to the USB host before doing your
> printf()'s in certain time-constrained situations, such as when you get a
> SET_ADDRESS.
>
> This will obviously effect your throughput (not to mention all the serial
> output slowing things down) but you'll be able to get through a USB
> enumeration no problem. Once it's all working you can bring the code back
> into the DSR and remove the printing. Or even better, leave a
> configuration option to switch between the "debug" and "release" options.
>
> Frank Pagliughi


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss