Re: General embedded development kits using gcc/gdb.

Re: General embedded development kits using gcc/gdb.

[dwglessn]

> Is gcc ported for _any_ 8-bit microprocessor/microcontroller?

Yes.  http://home.worldnet.fr/~stcarrez/m68hc11_port.html describes
a port for the 68HC11 and 68HC12.

--
David


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: General embedded development kits using gcc/gdb.

[Curt Mills, WE7U]

On Mon, 10 Jul 2000 dwglessn@collins.rockwell.com wrote:

> > Is gcc ported for _any_ 8-bit microprocessor/microcontroller?
> 
> Yes.  http://home.worldnet.fr/~stcarrez/m68hc11_port.html describes
> a port for the 68HC11 and 68HC12.


Also:

	http://sdcc.sourceforge.net/

8051 & Z80 compiler, and

	http://www.eskimo.com/~archer	(My home page)

GCC 2.81 version of HC11 compiler and MIT Handyboard Libraries.
This one doesn't use the full GNU toolset though.  The HC11/HC12
port listed first is more complete, and is against GCC 2.95.

Curt Mills, WE7U                         hacker.NO_*SPAM@tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

General embedded development kits using gcc/gdb.

[Andrew Tuckey]

> From: Craig Verbeck <CVerbeck@ClarityVisual.com>
> 
> Here's a list of processors that I'd love to see a binary distribution of
> this "development kit" for both windows and Linux:
> 
> 8bit: 8051/Atmel AVR
(snip)

Thank you Craig for your comments - all very helpful.  I already distribute an
80C537/80C517 development kit.  It has an assembly debugger (via the serial
port) with all the normal stuff - break points, register values etc.  I use a
very nice compiler for the 8051 family made by Hi-Tech, but its $1000 per
licence - one of the things that gave me the impetus for this project.

Is gcc ported for _any_ 8-bit microprocessor/microcontroller?



> 16bit: x86

Is there a preferable x86 platform for embedded apps?  Say an 80188EB, or
other?


-- 
Andrew Tuckey, Visiting Lecturer
Electrical and Computer Engineering Department
University of Wisconsin - Madison
1415 Engineering Drive
Madison, WI  53706-1691

Email: tuckey@ieee.org

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: General embedded development kits using gcc/gdb.

[norwood sisson]

check out
http://www.redhat.com/products/edk/
http://www.mvista.com/journeyman/

woody


tuckey@ieee.org wrote:
> 
> Dear GCC Cross Compiler List,
> 
> My name is Andrew Tuckey and I'm currently an Australian postdoctoral research
> scientist at the Eindhoven University of Technology, Eindhoven, the
> Netherlands.  My stay here stops in 7 weeks when I migrate the the USA to take
> up a position at the University of Wisconsin - Madison.  My primary research
> topic is dynamic control of electric machines and the testing of such
> controlled machines.
> 
> For my current project I'm using a TMS320C40 DSPs to dynamically control the
> torque of an induction type machine using a technique called Field Oriented
> Control (FOC).  As an outer loop speed control I'm using another 'C40 with
> speed and torque set-points output by LabVIEW via a LabMaster A/D card.  In
> pursuing this project I have become aware of a couple of limitations of our
> system, and the development of microprocessor control systems in general.
> Therefore I would like to look for a different type of solution for future
> projects.
> 
> I would like to make some single board embedded development kits with some
> simple tools.  Firstly I would like to use a board that has a more general
> (i.e. non DSP) type processor, something like a MIPS, ARM, PowerPC, or
> Pentium, or anything else that is deemed suitable.  The programme for a board
> will be programmed using gcc on any type of host computer with target output
> for the embedded system processor, and I would like to have the facility to
> use gdb as the debugger.  Such a system has many advantages.
> 
> Firstly such a system would only cost hardware since the software tools are
> free, and thus it would be reachable by students and enthusiasts, not just
> full-fee paying companies.
> 
> Secondly gcc and gdb are familiar to computer science students so they
> wouldn't have to learn another compiler/debugger (like Code Composer for
> the 'C40s for instance).
> 
> Thirdly, one wouldn't be restricted to a particular hardware for development or
> for the target processor (again like Code Composer and the 'C40s) - one could
> use whatever one desired that had enough processing power.
> 
> I realise that I will need to do some ROM programming for the
> downloading/debugger interface, but I'm willing to put in a little time if the
> hardware will support it, and channel the lessons learned in the experience
> back into the open source community.
> 
> As an extension I would further like to look at using RTLinux on the systems
> in more general contexts.  Ultimately I would like to use some high-speed
> communication for the downloading/debugging since using a serial port can get
> very painful.  If I used Ethernet and TCP/IP the embedded system could be
> remote from the development environment.
> 
> Further, I would like to have some digital and analogue I/O on the board.
> Having these on-board avoids the delays incurred in getting the data from the
> A/D converters etc. - something I have had some experience with using 'C40 for
> electric machine control.  I would like to experiment with mapping the outputs
> of the analogue and digital I/O onto particular memory locations so that I
> can avoid ISA and PCI bus interface complexity and delays.
> 
> For these boards customers could just buy the chips they want and leave out
> the bits they don't so the price for a development kit would be kept quite
> low.
> 
> Now the question that I would ask this list is `is what I'm proposing
> feasible?'  I'm sure it's fine for the larger processors, like a Pentium or
> MIPS, but what about the gdb interface for a memory limited ARM board?
> 
> Do any of you see any obvious problems with the concept?  Any recommendations?
> 
> Although I have used gcc and gdb in my computer science degree subjects and
> for some software development, I'm not quite sure where to start with the gdb
> interfacing.  I would like to know what type of communication is used between
> the processor, the running programme and gdb.  Could someone point me in the
> right direction to get such information.
> 
> And finally, when I build up these boards, how many would be interested in
> buying one?
> 
> --
> Andrew Tuckey, Visiting Lecturer
> Electrical and Computer Engineering Department
> University of Wisconsin - Madison
> 1415 Engineering Drive
> Madison, WI  53706-1691
> 
> Email: tuckey@ieee.org
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: General embedded development kits using gcc/gdb.

[Joel Sherrill]

Craig Verbeck wrote:
> 
> My reply may be considered off topic -- but I think it's a cool idea....

> There are development boards for all of these systems.  The ultimate would
> be to download a zip (windows) or tar-ball (Linux) that had binary versions
> of the compiler, debugger, eCos, and maybe uC/Linux with a BSP for a
> specific development board.  Based on how much processor you have available
> (MIPS, memory size, etc.) other excellent additions would be a portable GUI
> and a TCP/IP stack.  All ready to go.  Download, install and you are ready
> to develop in a familiar environment that has been pre-converged to this
> target system.
> 
> Here's a list of processors that I'd love to see a binary distribution of
> this "development kit" for both windows and Linux:
> 8bit: 8051/Atmel AVR
> 16bit: x86
> 32bit: PPC/CPU32(68k)/ARM/MIPS/Pentium
> I'm sure there are more.  These are the processors that I use (or would like
> to use) on a regular basis.
> 
> I know a lot of people have developed parts and pieces of this.  All of the
> source code is available.  But, there does not appear to be any _overall_
> organization.
> 
> Sorry for the rant,

This is not that much of a rant. :)

I think that the RTEMS team has come as close to anyone to meeting your
requirements.  There are pre-built cross toolset binaries for Linux x86,
Solaris/SPARC, FreeBSD, and Cygwin.  On each host, the same target
CPU families are supported (i386, i960, m68k/coldfire/cpu32, mips, 
powerpc, sh, and sparc).  In addition, there are also Linux x86 only 
binaries for the hppa and recently submitted Hitachi H8 port.  There 
is a port of RTEMS to the TI DSP C3x/C4x family and when possible we
will 
eventually make GNU toolset binaries available for that.  An ARM port is 
underway and tools will be added for that one when it is merged.  The
current version of all these are available at
ftp.oarcorp.com:/pub/rtems/betas.
Be careful when pulling things down -- use the index.html to guide your
selection.  There are literally over a Gbyte of tool binaries.  It
is hard to imagine anyone really needing all of them. :)

The above described tool binaries give you tools that target the CPU
family.
The second 1/2 of the problem is targetting to your board.  Included
in the RTEMS source is an RPM spec that can be used to build a packaged
binary version of a Board Support Package.

RTEMS has all of the classic RTOS features mentioned in the original
port
plus more.  It includes a port of the FreeBSD TCP/IP stack, filesystem
support, MicroWindows port, remote debugging via Ethernet, webserver, 
and much more.  It supports about 85% of the full POSIX 1003.1b standard 
including threads, supports a pSOS+ like API, and has emerging support 
for ITRON.  

For online documentation follow the links from www.oarcorp.com.
> A.C. Verbeck
> Principal Software Engineer
> Clarity Visual Systems
> email: cverbeck@clarityvisual.com
> vox: (503) 570-0319
> fax: (503) 682-9441
> web: www.ClarityVisual.com
> 
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: General embedded development kits using gcc/gdb.

[Daris Nevil]

Craig,

The vision you describe below is the driving force behind our development
at Simple Network Magic.  We see so many companies that need embedded
Internet and Network Managament, but don't have the time or $ to do
in-house development.  We provide a complete package, including compiler
binaries, a kernel and drivers already ported to the hardware, etc (you
can view at www.snmc.com/products.html).

Our drawback is because of our small size we cannot handle a wide range
of processors as you described.  We have restricted ourselves to PPC only,
and our next product will be based on the PowerQuick II.

Thanks for "the rant".

Daris Nevil
SNMC


Craig Verbeck wrote:

>
>
> There are development boards for all of these systems.  The ultimate would
> be to download a zip (windows) or tar-ball (Linux) that had binary versions
> of the compiler, debugger, eCos, and maybe uC/Linux with a BSP for a
> specific development board.  Based on how much processor you have available
> (MIPS, memory size, etc.) other excellent additions would be a portable GUI
> and a TCP/IP stack.  All ready to go.  Download, install and you are ready
> to develop in a familiar environment that has been pre-converged to this
> target system.
>
> Here's a list of processors that I'd love to see a binary distribution of
> this "development kit" for both windows and Linux:
> 8bit: 8051/Atmel AVR
> 16bit: x86
> 32bit: PPC/CPU32(68k)/ARM/MIPS/Pentium
> I'm sure there are more.  These are the processors that I use (or would like
> to use) on a regular basis.


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

RE: General embedded development kits using gcc/gdb.

[Craig Verbeck]

My reply may be considered off topic -- but I think it's a cool idea....

| I would like to make some single board embedded development 
| kits with some
| simple tools.  Firstly I would like to use a board that has a 
| more general
| (i.e. non DSP) type processor, something like a MIPS, ARM, PowerPC, or
| Pentium, or anything else that is deemed suitable.  The 
| programme for a board
| will be programmed using gcc on any type of host computer 
| with target output
| for the embedded system processor, and I would like to have 
| the facility to
| use gdb as the debugger.  Such a system has many advantages.

One not-so-implied requirement is to lower the entry cost to develop on such
a system.  IMO this is the key to making this type of system work.  I have
been drawn to gcc/gdb/eCos for the same reasons: extremely high quality
tools, exceptionally low cost of entry (in $).

However, there is cost.  In many cases you must converge the tools to your
system.  To expand on your idea, wouldn't it be great if there were a "kits"
for not just this board (which BTW is an excellent combination) but for a
large number of development boards/eval kits.

I am approached by distributors/factory reps every week.  They want to
"give" me an eval board.  In almost all cases the development tool-chain
cost is extreme ($5k-$25k+).  They will give you an eval license for the
development tools that lasts 30 days.  This is not enough time.  Also, all
of these compilers are different -- I have no desire to learn a new tool
chain each time I have to develop a project with a new processor.

There are development boards for all of these systems.  The ultimate would
be to download a zip (windows) or tar-ball (Linux) that had binary versions
of the compiler, debugger, eCos, and maybe uC/Linux with a BSP for a
specific development board.  Based on how much processor you have available
(MIPS, memory size, etc.) other excellent additions would be a portable GUI
and a TCP/IP stack.  All ready to go.  Download, install and you are ready
to develop in a familiar environment that has been pre-converged to this
target system.

Here's a list of processors that I'd love to see a binary distribution of
this "development kit" for both windows and Linux:
8bit: 8051/Atmel AVR
16bit: x86
32bit: PPC/CPU32(68k)/ARM/MIPS/Pentium
I'm sure there are more.  These are the processors that I use (or would like
to use) on a regular basis.

I know a lot of people have developed parts and pieces of this.  All of the
source code is available.  But, there does not appear to be any _overall_
organization.

Sorry for the rant,

A.C. Verbeck
Principal Software Engineer
Clarity Visual Systems
email: cverbeck@clarityvisual.com
vox: (503) 570-0319
fax: (503) 682-9441
web: www.ClarityVisual.com

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: General embedded development kits using gcc/gdb.

[Frank Przybylski]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

Hi all,
Andre Rodrigues da Silva wrote:
> 
>     Andrew,
> 
>     The only thing I would like to point out is that if you use a processor like
> motorola's
> MPC860 you can make the debugging by JTag just like you should be used to with the
> texas' processors. I thing this is a bit more easy.
> 
>     If you're interested in such a possibility I can give you these links:
> 
>     linuxppc.cs.nmt.edu -> look for embedded distribution
>     linux-embedded.org -> general info
>     www.brightstareng.com -> sell a board with mpc823 (much like the mpc860)
> 
>     Regards,
> 
>             André

A nice start point for embedded cross development with lots of links and a focus
on MPC860 (but not limited to) can be found under:
http://members.xoom.com/greyhams/linux/PowerPC-Embedded-HOWTO.html

Frank

-- 
===============================================================================
Frank Przybylski,VAS GmbH,Gotenstr.6,20097 Hamburg,GERMANY,TEL:+49-40-238568-14
   mailto:Frank.Przybylski@vas-gmbh.de , visit us at http://www.vas-gmbh.de
===============================================================================

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

Re: General embedded development kits using gcc/gdb.

[Andre Rodrigues da Silva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5214 bytes --]

    Andrew,

    The only thing I would like to point out is that if you use a processor like
motorola's
MPC860 you can make the debugging by JTag just like you should be used to with the
texas' processors. I thing this is a bit more easy.

    If you're interested in such a possibility I can give you these links:

    linuxppc.cs.nmt.edu -> look for embedded distribution
    linux-embedded.org -> general info
    www.brightstareng.com -> sell a board with mpc823 (much like the mpc860)

    Regards,

            André



tuckey@ieee.org wrote:

> Dear GCC Cross Compiler List,
>
> My name is Andrew Tuckey and I'm currently an Australian postdoctoral research
> scientist at the Eindhoven University of Technology, Eindhoven, the
> Netherlands.  My stay here stops in 7 weeks when I migrate the the USA to take
> up a position at the University of Wisconsin - Madison.  My primary research
> topic is dynamic control of electric machines and the testing of such
> controlled machines.
>
> For my current project I'm using a TMS320C40 DSPs to dynamically control the
> torque of an induction type machine using a technique called Field Oriented
> Control (FOC).  As an outer loop speed control I'm using another 'C40 with
> speed and torque set-points output by LabVIEW via a LabMaster A/D card.  In
> pursuing this project I have become aware of a couple of limitations of our
> system, and the development of microprocessor control systems in general.
> Therefore I would like to look for a different type of solution for future
> projects.
>
> I would like to make some single board embedded development kits with some
> simple tools.  Firstly I would like to use a board that has a more general
> (i.e. non DSP) type processor, something like a MIPS, ARM, PowerPC, or
> Pentium, or anything else that is deemed suitable.  The programme for a board
> will be programmed using gcc on any type of host computer with target output
> for the embedded system processor, and I would like to have the facility to
> use gdb as the debugger.  Such a system has many advantages.
>
> Firstly such a system would only cost hardware since the software tools are
> free, and thus it would be reachable by students and enthusiasts, not just
> full-fee paying companies.
>
> Secondly gcc and gdb are familiar to computer science students so they
> wouldn't have to learn another compiler/debugger (like Code Composer for
> the 'C40s for instance).
>
> Thirdly, one wouldn't be restricted to a particular hardware for development or
> for the target processor (again like Code Composer and the 'C40s) - one could
> use whatever one desired that had enough processing power.
>
> I realise that I will need to do some ROM programming for the
> downloading/debugger interface, but I'm willing to put in a little time if the
> hardware will support it, and channel the lessons learned in the experience
> back into the open source community.
>
> As an extension I would further like to look at using RTLinux on the systems
> in more general contexts.  Ultimately I would like to use some high-speed
> communication for the downloading/debugging since using a serial port can get
> very painful.  If I used Ethernet and TCP/IP the embedded system could be
> remote from the development environment.
>
> Further, I would like to have some digital and analogue I/O on the board.
> Having these on-board avoids the delays incurred in getting the data from the
> A/D converters etc. - something I have had some experience with using 'C40 for
> electric machine control.  I would like to experiment with mapping the outputs
> of the analogue and digital I/O onto particular memory locations so that I
> can avoid ISA and PCI bus interface complexity and delays.
>
> For these boards customers could just buy the chips they want and leave out
> the bits they don't so the price for a development kit would be kept quite
> low.
>
> Now the question that I would ask this list is `is what I'm proposing
> feasible?'  I'm sure it's fine for the larger processors, like a Pentium or
> MIPS, but what about the gdb interface for a memory limited ARM board?
>
> Do any of you see any obvious problems with the concept?  Any recommendations?
>
> Although I have used gcc and gdb in my computer science degree subjects and
> for some software development, I'm not quite sure where to start with the gdb
> interfacing.  I would like to know what type of communication is used between
> the processor, the running programme and gdb.  Could someone point me in the
> right direction to get such information.
>
> And finally, when I build up these boards, how many would be interested in
> buying one?
>
> --
> Andrew Tuckey, Visiting Lecturer
> Electrical and Computer Engineering Department
> University of Wisconsin - Madison
> 1415 Engineering Drive
> Madison, WI  53706-1691
>
> Email: tuckey@ieee.org
>
> ------
> Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
> Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com

General embedded development kits using gcc/gdb.

[tuckey]

Dear GCC Cross Compiler List,

My name is Andrew Tuckey and I'm currently an Australian postdoctoral research
scientist at the Eindhoven University of Technology, Eindhoven, the
Netherlands.  My stay here stops in 7 weeks when I migrate the the USA to take
up a position at the University of Wisconsin - Madison.  My primary research
topic is dynamic control of electric machines and the testing of such
controlled machines.

For my current project I'm using a TMS320C40 DSPs to dynamically control the
torque of an induction type machine using a technique called Field Oriented
Control (FOC).  As an outer loop speed control I'm using another 'C40 with
speed and torque set-points output by LabVIEW via a LabMaster A/D card.  In
pursuing this project I have become aware of a couple of limitations of our
system, and the development of microprocessor control systems in general.
Therefore I would like to look for a different type of solution for future
projects.

I would like to make some single board embedded development kits with some
simple tools.  Firstly I would like to use a board that has a more general
(i.e. non DSP) type processor, something like a MIPS, ARM, PowerPC, or
Pentium, or anything else that is deemed suitable.  The programme for a board
will be programmed using gcc on any type of host computer with target output
for the embedded system processor, and I would like to have the facility to
use gdb as the debugger.  Such a system has many advantages.

Firstly such a system would only cost hardware since the software tools are
free, and thus it would be reachable by students and enthusiasts, not just
full-fee paying companies.  

Secondly gcc and gdb are familiar to computer science students so they
wouldn't have to learn another compiler/debugger (like Code Composer for
the 'C40s for instance).

Thirdly, one wouldn't be restricted to a particular hardware for development or
for the target processor (again like Code Composer and the 'C40s) - one could
use whatever one desired that had enough processing power.

I realise that I will need to do some ROM programming for the
downloading/debugger interface, but I'm willing to put in a little time if the
hardware will support it, and channel the lessons learned in the experience
back into the open source community.

As an extension I would further like to look at using RTLinux on the systems
in more general contexts.  Ultimately I would like to use some high-speed
communication for the downloading/debugging since using a serial port can get
very painful.  If I used Ethernet and TCP/IP the embedded system could be
remote from the development environment.

Further, I would like to have some digital and analogue I/O on the board.
Having these on-board avoids the delays incurred in getting the data from the
A/D converters etc. - something I have had some experience with using 'C40 for
electric machine control.  I would like to experiment with mapping the outputs
of the analogue and digital I/O onto particular memory locations so that I
can avoid ISA and PCI bus interface complexity and delays.

For these boards customers could just buy the chips they want and leave out
the bits they don't so the price for a development kit would be kept quite
low.


Now the question that I would ask this list is `is what I'm proposing
feasible?'  I'm sure it's fine for the larger processors, like a Pentium or
MIPS, but what about the gdb interface for a memory limited ARM board?

Do any of you see any obvious problems with the concept?  Any recommendations?

Although I have used gcc and gdb in my computer science degree subjects and
for some software development, I'm not quite sure where to start with the gdb
interfacing.  I would like to know what type of communication is used between
the processor, the running programme and gdb.  Could someone point me in the
right direction to get such information.

And finally, when I build up these boards, how many would be interested in
buying one?



-- 
Andrew Tuckey, Visiting Lecturer
Electrical and Computer Engineering Department
University of Wisconsin - Madison
1415 Engineering Drive
Madison, WI  53706-1691

Email: tuckey@ieee.org

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com