Date: Thu, 22 Aug 2002 23:30:04 -0700 Subject: ColdFire Digest #1585 - 02/08/22 From: "Coldfire CPU Discussion List" To: "Coldfire CPU Discussion List" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Sender: Precedence: Bulk List-Software: LetterRip Pro 3.0.7 by Fog City Software, Inc. List-Subscribe: List-Digest: List-Unsubscribe: ColdFire Digest #1585 - Thursday, August 22, 2002 Re: embedded tcp/ip by "Chris Johns" working pthreads implementation for uClinux (was RE: parse error during a by "David Chan" Re: working pthreads implementation for uClinux (was RE: parse error duri by "David McCullough" RTD2 by "Claudio Imberlina @ Cyber-Tek" RE: RTD2 by "Tessner, Kevin" Re: RTD2 by "Claudio Imberlina @ Cyber-Tek" RTD2 source, a real answer by "Tessner, Kevin" Re: RTD2 source, a real answer by "L. Wayne Johnson" dBUG firmware vs BDM by "Robert Edward Munro" ---------------------------------------------------------------------- Subject: Re: embedded tcp/ip From: "Chris Johns" Date: Thu, 22 Aug 2002 20:05:52 +1000 benjamin hall wrote: > > We are designing a 2nd generation product that is used to test USB = devices. > Our first generation offered a serial port connection to the PC, from = which > it was controlled via a host application, and we are looking to add > ethernet. I would look for a stack that has a proven history. Also look and check Coldfire's are supported. The stack is only one issue, and it may not be the most important. Check the number and type of drivers supported by the stack. In your case network performance does not seem to be an issue, but then again CPU load maybe. For example a CS8900 interface will place a larger load on the CPU than the MAC found in the 5272 (the load is dependent on the network traffic). Each MAC has a performance/cost/complexity trade off. If you can afford to spend a little extra CPU performance an ethernet device such as the CS8900 uses the cost complexity gains given may be important. If your requirements are for 100M ethernet then you need to consider that specific range of MAC devices. After this look for the stack. You meantioned in an earlier mail the application is not complex enough to warrent an RTOS. The addition of TCP/IP and a RTOS may work out simpler for your application. TCP/IP stacks need some CPU time for handling input, timers, protocol control messages (ICMP) plus more. An RTOS will allow the stack to integrate to your application and not require application changes to support it. The RTOS will give the CPU to the stack when it needs it. You should be able run your application as a single task under the RTOS. It may require some small changes to interrupt handler entry and exit but a good RTOS should make this simple. For example RTEMS provides the standard test program ttcp and it is a single task ported from Unix to test the TCP/IP stack. It only uses the TCP/IP interfaces. An important issue to consider is how your product's TCP/IP stack will be configured. Will the IP address be static and held in the hardware somehow ? If so how will a user set or change this address for their specific network ? The network may not be usable when they receive the product so it cannot be used. Should you allow a network address to be assigned from a network server automatically (DHCP) when your product boots ? This requires your customers have a DHCP server online adding complexity to each user network they may not have or need. > So the requirement is only that we be able to connect to our > device and send/receive commands and data. I'm not even sure what subset = of > TCP or IP or whatever, that our simple system will require. But that's = it > in a nutshell. IMO TCP is the best as all the low level connection, retry etc is handled for you. It is just like a serial data stream. If performance is not an issue I like ASCII based protocols. You can telnet to them to test. Oh and do not forget to check out RTEMS at http://www.rtems.com/RTEMS/rtems.html. It has the FreeBSD stack so is well proven and fully featured. You can also get a number of excellent books on how to use it. -- Chris Johns, cjohns at cybertec.com.au ---------------------------------------------------------------------- Subject: working pthreads implementation for uClinux (was RE: parse error during a compile ) From: "David Chan" Date: Thu, 22 Aug 2002 09:35:12 -0500 Davidm, I inquired as to the status of uClibc's pthread implementation under uClinux/ColdFire, and I got this response from Erik Andersen on the uClibc mailing list: --snip-- > Hi, > > I'm planning on using some simple POSIX threading in an application > designed to run on uClinux/ColdFire using the uClibc library. I noticed > on the "Supported Applications List" that the comment next to Mozilla > mentioned support for POSIX threads. How good is the support so far? Is > the implementation full enough to support something like a multithreaded > web server? Sure. It works fine for me and all the multi-threaded test apps I have run... If you have problems, report them to the mailing list so we can get things fixed, -Erik -- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- _______________________________________________ uClibc mailing list uClibc@uclibc.org http://codepoet.org/mailman/listinfo/uclibc --snip-- So, though I haven't tried it quite yet, Erik seems to be confident that pthreads do work under uClinux/ColdFire. Did you have a contrary experience? Cheers, David Chan -----Original Message----- From: ColdFire@WildRice.com [mailto:ColdFire@WildRice.com] On Behalf Of David McCullough Sent: Tuesday, August 20, 2002 5:47 PM To: Coldfire CPU Discussion List Subject: Re: parse error during a compile Jodie, I don't know of any working pthreads implementations for uClinux, which explains why it isn't working for you I guess :-) >From the error I would say that a typedef or struct is missing. Cheers, Davidm ---------------------------------------------------------------------- Subject: Re: working pthreads implementation for uClinux (was RE: parse error during a compile ) From: "David McCullough" Date: Fri, 23 Aug 2002 01:35:41 +1000 Jivin David Chan lays it down ... > Davidm, > > I inquired as to the status of uClibc's pthread implementation under > uClinux/ColdFire, and I got this response from Erik Andersen on the > uClibc mailing list: > > --snip-- > > Hi, > > > > I'm planning on using some simple POSIX threading in an application > > designed to run on uClinux/ColdFire using the uClibc library. I > noticed > > on the "Supported Applications List" that the comment next to Mozilla > > mentioned support for POSIX threads. How good is the support so far? > Is > > the implementation full enough to support something like a > multithreaded > > web server? > > Sure. It works fine for me and all the multi-threaded test > apps I have run... If you have problems, report them to > the mailing list so we can get things fixed, I stand corrected. If Erik says he has tried it then I'm inclined to believe him :-) The version in the current uClinux-dist was pre-threads. We have updated to 0.9.13 and will be going to 0.9.15 as soon as it appears so the next distro release will have an up-to-date uClibc with whatever threading support there is, Cheers, Davidm -- David McCullough: Ph: +61 7 3435 2815 http://www.SnapGear.com davidm@snapgear.com Fx: +61 7 3891 3630 Custom Embedded Solutions + = Security ---------------------------------------------------------------------- Subject: RTD2 From: "Claudio Imberlina @ Cyber-Tek" Date: Thu, 22 Aug 2002 15:01:46 -0300 Any one know how to obtain the source code for the operating system RTD2 Thanks in advance Claudio Imberlina ---------------------------------------------------------------------- Subject: RE: RTD2 From: "Tessner, Kevin" Date: Thu, 22 Aug 2002 15:15:42 -0400 Is that the one from the guys that did C3POS? Kevin Tessner UCS Chief Engineer SST division of Woodhead Canada Phone: (519) 725-5136 ext. 327 Fax: (519) 725-1515 Email: ktessner@mySST.com Web Site: www.mySST.com (sorry, couldn't resist) -----Original Message----- From: Claudio Imberlina @ Cyber-Tek [mailto:cimberlina@cyber-tek.com] Sent: August 22, 2002 2:02 PM To: ColdFire@WildRice.com Subject: RTD2 Any one know how to obtain the source code for the operating system RTD2 Thanks in advance Claudio Imberlina ________________________________________________________________________ ColdFire Discussion List See: ---------------------------------------------------------------------- Subject: Re: RTD2 From: "Claudio Imberlina @ Cyber-Tek" Date: Thu, 22 Aug 2002 16:28:16 -0300 Mark Lawrence and Brian Shand created RTD2 as an undergraduate thesis in 1997. (You are talking about R2D2) ----- Original Message ----- From: "Tessner, Kevin" To: Sent: Thursday, August 22, 2002 4:15 PM Subject: RE: RTD2 > Is that the one from the guys that did C3POS? > > Kevin Tessner > UCS Chief Engineer > SST division of Woodhead Canada > Phone: (519) 725-5136 ext. 327 > Fax: (519) 725-1515 > Email: ktessner@mySST.com > Web Site: www.mySST.com > > (sorry, couldn't resist) > > -----Original Message----- > From: Claudio Imberlina @ Cyber-Tek [mailto:cimberlina@cyber-tek.com] > Sent: August 22, 2002 2:02 PM > To: ColdFire@WildRice.com > Subject: RTD2 > > Any one know how to obtain the source code for the operating system RTD2 > > Thanks in advance > Claudio Imberlina > ________________________________________________________________________ > ColdFire Discussion List > See: > > > ________________________________________________________________________ > ColdFire Discussion List > See: > > > > ---------------------------------------------------------------------- Subject: RTD2 source, a real answer From: "Tessner, Kevin" Date: Thu, 22 Aug 2002 15:27:54 -0400 And now for the real answer... Kevin Tessner UCS Chief Engineer SST division of Woodhead Canada Phone: (519) 725-5136 ext. 327 Fax: (519) 725-1515 Email: ktessner@mySST.com Web Site: www.mySST.com -----Original Message----- From: Jonathan Malton Sent: August 22, 2002 3:26 PM To: 'Tessner, Kevin' Subject: RE: RTD2 ha ha! I suggest writing to the communication research group in the electrical engineering department at the university of capetown. rtd2 was developed there, and they'll have the source -----Original Message----- From: Tessner, Kevin [mailto:ktessner@mySST.com] Sent: Thursday, August 22, 2002 3:16 PM To: 'ColdFire@WildRice.com' Subject: RE: RTD2 Importance: Low Is that the one from the guys that did C3POS? Kevin Tessner UCS Chief Engineer SST division of Woodhead Canada Phone: (519) 725-5136 ext. 327 Fax: (519) 725-1515 Email: ktessner@mySST.com Web Site: www.mySST.com (sorry, couldn't resist) -----Original Message----- From: Claudio Imberlina @ Cyber-Tek [mailto:cimberlina@cyber-tek.com] Sent: August 22, 2002 2:02 PM To: ColdFire@WildRice.com Subject: RTD2 Any one know how to obtain the source code for the operating system RTD2 Thanks in advance Claudio Imberlina ________________________________________________________________________ ColdFire Discussion List See: ---------------------------------------------------------------------- Subject: Re: RTD2 source, a real answer From: "L. Wayne Johnson" Date: Thu, 22 Aug 2002 12:44:33 -0700 Try http://crg.ee.uct.ac.za/~eee484f/ At 03:27 PM 8/22/02 -0400, you wrote: >And now for the real answer... > >Kevin Tessner >UCS Chief Engineer >SST division of Woodhead Canada >Phone: (519) 725-5136 ext. 327 >Fax: (519) 725-1515 >Email: ktessner@mySST.com >Web Site: www.mySST.com > >-----Original Message----- >From: Jonathan Malton >Sent: August 22, 2002 3:26 PM >To: 'Tessner, Kevin' >Subject: RE: RTD2 > >ha ha! > >I suggest writing to the communication research group in the electrical >engineering department at the university of capetown. rtd2 was developed >there, and they'll have the source > >-----Original Message----- >From: Tessner, Kevin [mailto:ktessner@mySST.com] >Sent: Thursday, August 22, 2002 3:16 PM >To: 'ColdFire@WildRice.com' >Subject: RE: RTD2 >Importance: Low > >Is that the one from the guys that did C3POS? > >Kevin Tessner >UCS Chief Engineer >SST division of Woodhead Canada >Phone: (519) 725-5136 ext. 327 >Fax: (519) 725-1515 >Email: ktessner@mySST.com >Web Site: www.mySST.com > >(sorry, couldn't resist) > >-----Original Message----- >From: Claudio Imberlina @ Cyber-Tek [mailto:cimberlina@cyber-tek.com] >Sent: August 22, 2002 2:02 PM >To: ColdFire@WildRice.com >Subject: RTD2 > >Any one know how to obtain the source code for the operating system RTD2 > >Thanks in advance >Claudio Imberlina >________________________________________________________________________ >ColdFire Discussion List >See: > > >________________________________________________________________________ >ColdFire Discussion List >See: L. Wayne Johnson wayne@zk.com Senior Software Engineer, ZK Celltest Inc, www.zk.com voice: 408-986-8080, fax: 408-986-8178 ---------------------------------------------------------------------- Subject: dBUG firmware vs BDM From: "Robert Edward Munro" Date: Fri, 23 Aug 2002 16:06:13 +1000 (AEST) Heya=3D], The design and developement of our dsp board seems to be neverending and the more we look into it the more complex it appears... I think we are suffering from a severe case of "feature creap", possibly doing too much, but its all fun=3D] Until you run out of time;) The latest issue is what = to use for monitoring/debugging, dissassembly, program download ect for the 206e on the board. We cant choose whether to go for the option of chucking a flash prom on the board and and burning say, dBUG, on to it, to do this, or using the on-chip debugging hardware already on the coldfire and interfaceing this with specialised software. I guess, just thinking about it now its really just an issue of whether we go for the portable, more expensive option (a 512x16 flash prom is about 60AUD), or the cheaper option that requires specific software - as apposed to just plain old kermit or hyperterminal. How does using dBUG compare to using BDM? Are there any other issues that could influence my opinion that i dont know about? Thanks again=3D] you guys are an amazing help=3D] Cheers Rob ---------------------------------------------------------------------- End of ColdFire Digest ________________________________________________________________________ ColdFire Discussion List See: