Jason wrote:
wireless wrote:
Mike Frysinger wrote:
On Friday 12 September 2008, billium wrote:
get openocd from respository, svn checkout
svn://svn.berlios.de/openocd/trunk/openocd and extract
why ? we have an openocd-9999.ebuild which fetches straight from the
upstream site ...
I have to chuckle out loud......
Some time ago, I inquired about using developing on embedded (gentoo)
linux using Eclipse and any sort of TAG/BDM device.
I still remember the (focused) scolding you gave me about how that
was not the *nix way. Command line, burn and churn, etc etc....
As an old (*nix) fart, I rather enjoyed (and agreed with) your prose.
However, the planet is being overrun with young kids that like their
gui-fied tools....
Rhetorical Question: How many of those "young kids" are _good_? There
is no shortcut to deep understanding (no, I'm no where close).
Something a GUI obfuscates away, the cli celebrates. But then, we
agree... ;-)
Most of what we do is old fashion roll your own state machine, async
programming (8-32) bit processors for products. So any RTOS/executive
is a luxury.... The designs typically used >90% of the resources.
Tight and Spartan still rules the roost in our embedded world.
It does not matter if they are good, they will eventually replace us,
and assembler will rise again, as it's understanding along with a firm
grasp of hardware is essential. Team programming is over rated. We put
one firmware person on each project. Sink or swim, but that's a
different issue.
Now you are pointing folks to openocd......?
Are you implying that openocd is a gui? I think you might be referring
to something else.
Eclipse vs command line.... look at the top of this page:
http://www.yagarto.de/
Second bullet (*works with Elipse*). That's what I refer to a
gui-fied. You interface to a variety of tasks and tools, via a gui.
Granted, many of the parts can and should run on the CLI, but,
it is dam nice to have an IDE to work from, and I'm an old *nix
hack making the statement. Sure you can go to another terminal
session under linux (X) and run a command line tool for what
ever reason, but, working centrally out of an IDE has it's merits,
and it is the industry standard way to write firmware.
If you work with Code Composer (TI) or CodeWarrior (Freescale) or any
number of gui based (packaged) tools, you see all of the pieces, via a
gui. That's where Eclipse is heading, in my opinion. It's not that CLI
tools will disappear, but using them and accessing them, via Eclipse,
is the future, from the many vendors we speak with. (ymmv).
After all 99% of firmware is still written (and cross compiled)
on windows boxes, from what I see, at the major vendor trade shows
(Freescale, Microchip, TI, Atmel etc etc) and talking to a myriad
of folks that write firmware, for a living. Sure every body has
a thing or 2 built on embedded linux, but most products still
are built via Integrated Development Environments (IDE), because
that's what their management feels comfortable with. They want those
vendor(ish) tools, so if an employee, or consultant leaves, it's
pretty much easy to find another firmware engineer to work on the next
revision of the product, (YMMV). Following another programmer on
somebody else's *nix CLI stuffage, is most often a drag, and that's if
you are 'into' *nix type of OSes.
Eclipse can be a game changer for the entire industry, methinks, as
the management, (you know, those folks that *FUND* new products within
a company), are hoping for something like Eclipse to mature and vendors
make the commitment to move to it, as well as open source choices.
Pie-in-the-sky, maybe, but I hear it more and more. We have some very
bright folks we work with. They do not have problems using linux or
*nix, but, when it comes to firmware development, most refuse to
use linux/*nix as the windows based tools allow them to code, much
faster. Time is money, when you bill by the hour, and our clients
are stingy and expect miracles, often on PO's of less than 100 hours.
Personally, embedded linux is way excessive for most of our clients,
but, if there was unification around eclipse (as an open source
IDE), then I think many companies would venture new embedded
products, upgrading the processor to something that can handle
embedded linux and be happy with Eclipse, knowing they can work
it from a windows or linux workstation, depending on what the
firmware engineer is most comfortable with.
I also think that once Eclipse (et. al) matures, many companies
will port their BSPs over to Eclipse and be done with paying
royalties, fees and (extorted) licenses to Micro Soft.
just my 2cents.
Here's a quick and dirty:
http://openhardware.net/Embedded_ARM/OpenOCD_JTAG/#testocd
Basically, run openocd from the command line, specifying a config file.
Then telnet into it. ;-)
Someone may have glossed over this with a gui, but that's not what crops
up in google.
Maybe we can all agree on a BSP that works well with a JTAG and
Eclipse, and make it an option for Noobs wanting to get into
embedded Gentoo? I think this is an easier sell than GNAP....?
Keeping cost down is a good idea, and my early vote goes for
an Arm9 board.
I haven't needed a jtag for it, since the bootloader was sufficient, but
I like the NSLU2 as a good starter kit. I recently saw one on ebay for
~$30US. I bought mine new years ago for ~$70US.
OK, if the group decides not to want a JTAG, then that's cool with me.
Folks occasionally become interested in embedded gentoo, are open to
what processor/board to use. IMHO, it'd be very cool to have an
introduction to embedded gentoo, say like Das Blinkenlights,
or Das AD/DA, on a simple, low cost board. Ethernet is the only real
hardware requirement I'd suggest, so I'd be cool to whatever the
consensus is.
The next step after that (at least, what I did) was the Gateworks 2348-4
board. Same processor, 4 mini-pci, 2 ethernet, USB as an option. It's
less than $300US. Openocd works with it's parallel jtag programmer. I
haven't needed that yet either, since the bootloader works for me.
Um, most of our customers want an custom bootloader. It's really not
an option when you write firmware for a custom designed board that
is going to become a product. Sure vendors provide reference code, but
I've never seen that be sufficient for a product. I know lots of
companies use code from the chip vendors (cisco), but, it gets them
into trouble, more often than most realize. Besides a JTAG can be used
for debugging lots of different firmware/hardware issues, particularly
when you have limited/constrained resources and many things flying
around, asynchronously. You could not even get a firmware engineer
anywhere I've seen that would do a project, without a JTAG, BDM or
ICE. This is where embedded linux (and hopefully embedded gentoo) can
go to whole new level, when you customize device drivers for various
optimized needs, under constrained resources. Am I talking about
deviation from what the kernel gods have published? Sure, but only
in small amounts, and it is done quite often with embedded products.
Just look at the number of vendors now offering 'embedded linux'.
The ethernet support is native in the vanilla kernel since about 2.6.21
or .23. As of 2.6.27, the kernel has support for the hardware crypto
engine. IPsec VPN gateway, anyone?
I'm not trying to upset anyone, I just see things slightly different
than most, because, as the end of the battle, I do want linux as a
workstation development platform (complete with a killer IDE) and
embedded linux (customized) as a ~rtos to win, or at least be a
realistic option for many processors and new products.
Sure (linux) is gaining market share, but, I think that
is a (relatively) few products that hit very high volume. It certainly
does not dominate where most firmware engineers actual do their work,
imho.
James
