From: Frank Pagliughi <fpagliughi@mindspring.com>
To: Oliver Munz <oli@snr.ch>
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Timecritical interrupt-debuging ... printf in DSR's ... Cyg_Scheduler_Implementation::rem_thread() ... cyg_assert_fail()
Date: Wed, 06 Jul 2005 07:31:00 -0000 [thread overview]
Message-ID: <42CB88BE.1060207@mindspring.com> (raw)
In-Reply-To: <006101c580e1$b3a48df0$5e188481@cadpad>
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
next prev parent reply other threads:[~2005-07-06 7:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-04 21:46 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 [this message]
2005-07-08 11:08 ` oliver munz @ s p e a g
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42CB88BE.1060207@mindspring.com \
--to=fpagliughi@mindspring.com \
--cc=ecos-discuss@sources.redhat.com \
--cc=oli@snr.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).