From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11083 invoked by alias); 8 Jul 2005 11:08:02 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 10849 invoked by uid 22791); 8 Jul 2005 11:07:51 -0000 Received: from otoro.itis.ethz.ch (HELO otoro.itis.ethz.ch) (129.132.24.2) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 08 Jul 2005 11:07:51 +0000 Received: from localhost (localhost [127.0.0.1]) by otoro.itis.ethz.ch (Postfix) with ESMTP id C21285B382; Fri, 8 Jul 2005 13:07:48 +0200 (MEST) Received: from otoro.itis.ethz.ch ([127.0.0.1]) by localhost (otoro [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07190-01-8; Fri, 8 Jul 2005 13:07:48 +0200 (MEST) Received: from cadpad (itis-speag-094-dhcp.itis.ethz.ch [129.132.24.94]) by otoro.itis.ethz.ch (Postfix) with SMTP id E28765B380; Fri, 8 Jul 2005 13:07:47 +0200 (MEST) Message-ID: <016701c583ad$4536fe60$5e188481@cadpad> Reply-To: "oliver munz @ s p e a g" From: "oliver munz @ s p e a g" To: "Frank Pagliughi" Cc: References: <006101c580e1$b3a48df0$5e188481@cadpad> <42CB88BE.1060207@mindspring.com> Date: Fri, 08 Jul 2005 11:08:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0527-1, 07.07.2005), Outbound message X-Antivirus-Status: Clean Subject: Re: [ECOS] Timecritical interrupt-debuging ... printf in DSR's ... Cyg_Scheduler_Implementation::rem_thread() ... cyg_assert_fail() X-SW-Source: 2005-07/txt/msg00082.txt.bz2 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