From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Graf To: ecos-discuss@sources.redhat.com Subject: Re: [ECOS] sscanf() vs. fgetc() Date: Thu, 12 Jul 2001 05:57:00 -0000 Message-id: <3.0.5.32.20010712145511.0093c540@128.128.128.220> References: <3.0.5.32.20010712104805.00914420@128.128.128.220> <3B4D832C.370985AE@redhat.com> X-SW-Source: 2001-07/msg00358.html Hi Jonathan, thank you very much for trying the example. Indeeed very kind of you! >Hmm.... > >cyg_thread_create()... >cyg_thread_resume... >fgetc()... >fgetc() done. Why doesn't fgetc() block in your case? Were there characters in the serial buffer? For me, fgetc() does block due to empty buffer. >fgetc()... >loop... >sprintf... >sscanf... >sscanf done. >loop... >main() finished > >This was on a PC target FWIW. Which priority value did you have for the sscanf() thread? I had the default of "10", which means lower priority than the "9" in the fgetc() thread. (Otherwise sscanf() works for me as well.) >Perhaps you should step into sscanf() and see where it stops. I tried, of course. Singlestepping has the tendency of being a bit problematic on my target. (probably due to optimized code, and the way singlestepping works without hardware support). I experience sigtraps when trying to singlestep my way down. Ignoring them, I end up in the scheduler, but don't understand too much of what is going on there. (Not sure if I can get any meaningful results this way.) >Or if it gets stuck, press Ctrl-C and then "info threads", then switch to the main thread >and do a backtrace. Ctrl+C doesn't work for my Hitachi SH3 target. I help myself with an NMI button, so I can see memory contents, but have no easy way to get back into the main() context. Peter