* [ECOS] Timecritical interrupt-debuging ... printf in DSR's ... Cyg_Scheduler_Implementation::rem_thread() ... cyg_assert_fail() @ 2005-07-04 21:46 Oliver Munz 2005-07-05 7:17 ` Fabian Scheler 2005-07-06 7:31 ` Frank Pagliughi 0 siblings, 2 replies; 7+ messages in thread From: Oliver Munz @ 2005-07-04 21:46 UTC (permalink / raw) To: ecos-discuss Hi To debug an USB-driver, I used diag_printf(). Unfortunatly this function blocks my DSR longer then the USB-specifications allowed to. So I tryed to send the debug-output over the standard at91-serial-driver, configurated with a 2kByte buffer. This works fine a short time and fail: CYG_ASSERT( ((queue_map & (1<<pri))!=0) == ((!run_queue[pri].empty())!=0), "Map and queue disagree"); in: 7 cyg_assert_fail() at e:\ecos\packages\infra\current\src\buffer.cxx:737 6 Cyg_Scheduler_Implementation::rem_thread() at e:\ecos\packages\kernel\current\src\sched\mlqueue.cxx:323 5 Cyg_Condition_Variable::wait_inner() at e:\ecos\packages\kernel\current\src\sync\mutex.cxx:636 4 serial_write() at e:\ecos\packages\io\serial\current\src\common\serial.c:362 3 cyg_io_write() at e:\ecos\packages\io\common\current\src\iosys.c:178 I don't know if it's allowed to use the buffered IO from ISR and DSR's. If everybody know's if it should work or not in threory, let me know.... Im also intressted in other hints how to debug driveres... Thanks Oliver Munz -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] Timecritical interrupt-debuging ... printf in DSR's ... Cyg_Scheduler_Implementation::rem_thread() ... cyg_assert_fail() 2005-07-04 21:46 [ECOS] Timecritical interrupt-debuging ... printf in DSR's ... Cyg_Scheduler_Implementation::rem_thread() ... cyg_assert_fail() Oliver Munz @ 2005-07-05 7:17 ` Fabian Scheler 2005-07-05 7:28 ` Andrew Lunn 2005-07-06 7:31 ` Frank Pagliughi 1 sibling, 1 reply; 7+ messages in thread From: Fabian Scheler @ 2005-07-05 7:17 UTC (permalink / raw) To: Oliver Munz; +Cc: ecos-discuss Hi, > I don't know if it's allowed to use the buffered IO from ISR and DSR's. If > everybody know's if it should work or not in threory, let me know.... Im > also intressted in other hints how to debug driveres... well, I don't know the exact implementation of buffered IO in eCos, but buffered IO always is blocking (if you want to ensure that no data gets lost), and blokcing operations are never allowed within an ISR or a DSR. Ciao, Fabian -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] Timecritical interrupt-debuging ... printf in DSR's ... Cyg_Scheduler_Implementation::rem_thread() ... cyg_assert_fail() 2005-07-05 7:17 ` Fabian Scheler @ 2005-07-05 7:28 ` Andrew Lunn 2005-07-05 9:43 ` oliver munz @ s p e a g 0 siblings, 1 reply; 7+ messages in thread From: Andrew Lunn @ 2005-07-05 7:28 UTC (permalink / raw) To: Fabian Scheler; +Cc: Oliver Munz, ecos-discuss On Tue, Jul 05, 2005 at 09:16:44AM +0200, Fabian Scheler wrote: > Hi, > > > I don't know if it's allowed to use the buffered IO from ISR and DSR's. If > > everybody know's if it should work or not in threory, let me know.... Im > > also intressted in other hints how to debug driveres... > > well, I don't know the exact implementation of buffered IO in eCos, > but buffered IO always is blocking (if you want to ensure that no data > gets lost), and blokcing operations are never allowed within an ISR or > a DSR. Correct. You can use the infrastructure trace functions and instramentation functions which are safe when writting to a buffer. Or you can implement your own buffering which is ISR/DSR safe. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] Timecritical interrupt-debuging ... printf in DSR's ... Cyg_Scheduler_Implementation::rem_thread() ... cyg_assert_fail() 2005-07-05 7:28 ` Andrew Lunn @ 2005-07-05 9:43 ` oliver munz @ s p e a g 2005-07-05 11:23 ` Andrew Lunn 0 siblings, 1 reply; 7+ messages in thread From: oliver munz @ s p e a g @ 2005-07-05 9:43 UTC (permalink / raw) To: Fabian Scheler, Andrew Lunn; +Cc: ecos-discuss ----- Original Message ----- From: "Andrew Lunn" <andrew@lunn.ch> To: "Fabian Scheler" <fabian.scheler@gmail.com> Cc: "Oliver Munz" <oli@snr.ch>; <ecos-discuss@sources.redhat.com> Sent: Tuesday, July 05, 2005 9:27 AM Subject: Re: [ECOS] Timecritical interrupt-debuging ... printf in DSR's ... Cyg_Scheduler_Implementation::rem_thread() ... cyg_assert_fail() > On Tue, Jul 05, 2005 at 09:16:44AM +0200, Fabian Scheler wrote: >> Hi, >> >> > I don't know if it's allowed to use the buffered IO from ISR and DSR's. >> > If >> > everybody know's if it should work or not in threory, let me know.... >> > Im >> > also intressted in other hints how to debug driveres... >> >> well, I don't know the exact implementation of buffered IO in eCos, >> but buffered IO always is blocking (if you want to ensure that no data >> gets lost), and blokcing operations are never allowed within an ISR or >> a DSR. > > Correct. > > You can use the infrastructure trace functions and instramentation > functions which are safe when writting to a buffer. Or you can > implement your own buffering which is ISR/DSR safe. > > Andrew Thanks a lot... Then I can try the option "CYGOPT_IO_SERIAL_SUPPORT_NONBLOCKING" (and hope there rise no other problems)... If I use the "CYG_TRACE0(bool, msg)" function family, then I have to use "CYG_TRACE_PRINT()" if I want control over the timing, because "CYG_TRACE_PRINT()" blocks until the hole trace-buffer ist written to diag_write(). Right? Greatings Oli -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] Timecritical interrupt-debuging ... printf in DSR's ... Cyg_Scheduler_Implementation::rem_thread() ... cyg_assert_fail() 2005-07-05 9:43 ` oliver munz @ s p e a g @ 2005-07-05 11:23 ` Andrew Lunn 0 siblings, 0 replies; 7+ messages in thread From: Andrew Lunn @ 2005-07-05 11:23 UTC (permalink / raw) To: oliver munz @ s p e a g; +Cc: Fabian Scheler, Andrew Lunn, ecos-discuss On Tue, Jul 05, 2005 at 11:43:20AM +0200, oliver munz @ s p e a g wrote: > > ----- Original Message ----- > From: "Andrew Lunn" <andrew@lunn.ch> > To: "Fabian Scheler" <fabian.scheler@gmail.com> > Cc: "Oliver Munz" <oli@snr.ch>; <ecos-discuss@sources.redhat.com> > Sent: Tuesday, July 05, 2005 9:27 AM > Subject: Re: [ECOS] Timecritical interrupt-debuging ... printf in DSR's ... > Cyg_Scheduler_Implementation::rem_thread() ... cyg_assert_fail() > > > >On Tue, Jul 05, 2005 at 09:16:44AM +0200, Fabian Scheler wrote: > >>Hi, > >> > >>> I don't know if it's allowed to use the buffered IO from ISR and DSR's. > >>> If > >>> everybody know's if it should work or not in threory, let me know.... > >>> Im > >>> also intressted in other hints how to debug driveres... > >> > >>well, I don't know the exact implementation of buffered IO in eCos, > >>but buffered IO always is blocking (if you want to ensure that no data > >>gets lost), and blokcing operations are never allowed within an ISR or > >>a DSR. > > > >Correct. > > > >You can use the infrastructure trace functions and instramentation > >functions which are safe when writting to a buffer. Or you can > >implement your own buffering which is ISR/DSR safe. > > > > Andrew > > Thanks a lot... > > Then I can try the option "CYGOPT_IO_SERIAL_SUPPORT_NONBLOCKING" (and hope > there rise no other problems)... Nope, this will not help. Thats a different meaning of none blocking. > If I use the "CYG_TRACE0(bool, msg)" function family, then I have to use > "CYG_TRACE_PRINT()" if I want control over the timing, because > "CYG_TRACE_PRINT()" blocks until the hole trace-buffer ist written to > diag_write(). Right? Correct. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] Timecritical interrupt-debuging ... printf in DSR's ... Cyg_Scheduler_Implementation::rem_thread() ... cyg_assert_fail() 2005-07-04 21:46 [ECOS] Timecritical interrupt-debuging ... printf in DSR's ... Cyg_Scheduler_Implementation::rem_thread() ... cyg_assert_fail() Oliver Munz 2005-07-05 7:17 ` Fabian Scheler @ 2005-07-06 7:31 ` Frank Pagliughi 2005-07-08 11:08 ` oliver munz @ s p e a g 1 sibling, 1 reply; 7+ messages in thread From: Frank Pagliughi @ 2005-07-06 7:31 UTC (permalink / raw) To: Oliver Munz; +Cc: ecos-discuss Oliver Munz wrote: > Hi > > To debug an USB-driver, I used diag_printf(). Unfortunatly this > function blocks my DSR longer then the USB-specifications allowed to. > So I tryed to send the debug-output over the standard > at91-serial-driver, configurated with a 2kByte buffer. > > This works fine a short time and fail: > > CYG_ASSERT( ((queue_map & (1<<pri))!=0) == > ((!run_queue[pri].empty())!=0), "Map and queue disagree"); > in: > > 7 cyg_assert_fail() at e:\ecos\packages\infra\current\src\buffer.cxx:737 > 6 Cyg_Scheduler_Implementation::rem_thread() at > e:\ecos\packages\kernel\current\src\sched\mlqueue.cxx:323 > 5 Cyg_Condition_Variable::wait_inner() at > e:\ecos\packages\kernel\current\src\sync\mutex.cxx:636 > 4 serial_write() at > e:\ecos\packages\io\serial\current\src\common\serial.c:362 > 3 cyg_io_write() at e:\ecos\packages\io\common\current\src\iosys.c:178 > > > I don't know if it's allowed to use the buffered IO from ISR and > DSR's. If everybody know's if it should work or not in threory, let me > know.... Im also intressted in other hints how to debug driveres... > > Thanks > 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] Timecritical interrupt-debuging ... printf in DSR's ... Cyg_Scheduler_Implementation::rem_thread() ... cyg_assert_fail() 2005-07-06 7:31 ` Frank Pagliughi @ 2005-07-08 11:08 ` oliver munz @ s p e a g 0 siblings, 0 replies; 7+ messages in thread From: oliver munz @ s p e a g @ 2005-07-08 11:08 UTC (permalink / raw) To: Frank Pagliughi; +Cc: ecos-discuss 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2005-07-08 11:08 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-07-04 21:46 [ECOS] Timecritical interrupt-debuging ... printf in DSR's ... Cyg_Scheduler_Implementation::rem_thread() ... cyg_assert_fail() Oliver Munz 2005-07-05 7:17 ` Fabian Scheler 2005-07-05 7:28 ` Andrew Lunn 2005-07-05 9:43 ` oliver munz @ s p e a g 2005-07-05 11:23 ` Andrew Lunn 2005-07-06 7:31 ` Frank Pagliughi 2005-07-08 11:08 ` oliver munz @ s p e a g
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).