1 |
Jason wrote: |
2 |
> wireless wrote: |
3 |
>> Mike Frysinger wrote: |
4 |
>>> On Friday 12 September 2008, billium wrote: |
5 |
>>>> get openocd from respository, svn checkout |
6 |
>>>> svn://svn.berlios.de/openocd/trunk/openocd and extract |
7 |
>>> why ? we have an openocd-9999.ebuild which fetches straight from the |
8 |
>>> upstream site ... |
9 |
>> I have to chuckle out loud...... |
10 |
>> |
11 |
>> |
12 |
>> Some time ago, I inquired about using developing on embedded (gentoo) |
13 |
>> linux using Eclipse and any sort of TAG/BDM device. |
14 |
>> |
15 |
>> |
16 |
>> I still remember the (focused) scolding you gave me about how that |
17 |
>> was not the *nix way. Command line, burn and churn, etc etc.... |
18 |
>> |
19 |
>> As an old (*nix) fart, I rather enjoyed (and agreed with) your prose. |
20 |
>> However, the planet is being overrun with young kids that like their |
21 |
>> gui-fied tools.... |
22 |
>> |
23 |
> |
24 |
> Rhetorical Question: How many of those "young kids" are _good_? There |
25 |
> is no shortcut to deep understanding (no, I'm no where close). |
26 |
> Something a GUI obfuscates away, the cli celebrates. But then, we |
27 |
> agree... ;-) |
28 |
|
29 |
Most of what we do is old fashion roll your own state machine, async |
30 |
programming (8-32) bit processors for products. So any RTOS/executive |
31 |
is a luxury.... The designs typically used >90% of the resources. |
32 |
Tight and Spartan still rules the roost in our embedded world. |
33 |
|
34 |
It does not matter if they are good, they will eventually replace us, |
35 |
and assembler will rise again, as it's understanding along with a firm |
36 |
grasp of hardware is essential. Team programming is over rated. We put |
37 |
one firmware person on each project. Sink or swim, but that's a |
38 |
different issue. |
39 |
|
40 |
|
41 |
>> Now you are pointing folks to openocd......? |
42 |
|
43 |
> Are you implying that openocd is a gui? I think you might be referring |
44 |
> to something else. |
45 |
|
46 |
Eclipse vs command line.... look at the top of this page: |
47 |
|
48 |
http://www.yagarto.de/ |
49 |
|
50 |
Second bullet (*works with Elipse*). That's what I refer to a |
51 |
gui-fied. You interface to a variety of tasks and tools, via a gui. |
52 |
Granted, many of the parts can and should run on the CLI, but, |
53 |
it is dam nice to have an IDE to work from, and I'm an old *nix |
54 |
hack making the statement. Sure you can go to another terminal |
55 |
session under linux (X) and run a command line tool for what |
56 |
ever reason, but, working centrally out of an IDE has it's merits, |
57 |
and it is the industry standard way to write firmware. |
58 |
|
59 |
|
60 |
If you work with Code Composer (TI) or CodeWarrior (Freescale) or any |
61 |
number of gui based (packaged) tools, you see all of the pieces, via a |
62 |
gui. That's where Eclipse is heading, in my opinion. It's not that CLI |
63 |
tools will disappear, but using them and accessing them, via Eclipse, |
64 |
is the future, from the many vendors we speak with. (ymmv). |
65 |
After all 99% of firmware is still written (and cross compiled) |
66 |
on windows boxes, from what I see, at the major vendor trade shows |
67 |
(Freescale, Microchip, TI, Atmel etc etc) and talking to a myriad |
68 |
of folks that write firmware, for a living. Sure every body has |
69 |
a thing or 2 built on embedded linux, but most products still |
70 |
are built via Integrated Development Environments (IDE), because |
71 |
that's what their management feels comfortable with. They want those |
72 |
vendor(ish) tools, so if an employee, or consultant leaves, it's |
73 |
pretty much easy to find another firmware engineer to work on the next |
74 |
revision of the product, (YMMV). Following another programmer on |
75 |
somebody else's *nix CLI stuffage, is most often a drag, and that's if |
76 |
you are 'into' *nix type of OSes. |
77 |
|
78 |
Eclipse can be a game changer for the entire industry, methinks, as |
79 |
the management, (you know, those folks that *FUND* new products within |
80 |
a company), are hoping for something like Eclipse to mature and vendors |
81 |
make the commitment to move to it, as well as open source choices. |
82 |
Pie-in-the-sky, maybe, but I hear it more and more. We have some very |
83 |
bright folks we work with. They do not have problems using linux or |
84 |
*nix, but, when it comes to firmware development, most refuse to |
85 |
use linux/*nix as the windows based tools allow them to code, much |
86 |
faster. Time is money, when you bill by the hour, and our clients |
87 |
are stingy and expect miracles, often on PO's of less than 100 hours. |
88 |
|
89 |
Personally, embedded linux is way excessive for most of our clients, |
90 |
but, if there was unification around eclipse (as an open source |
91 |
IDE), then I think many companies would venture new embedded |
92 |
products, upgrading the processor to something that can handle |
93 |
embedded linux and be happy with Eclipse, knowing they can work |
94 |
it from a windows or linux workstation, depending on what the |
95 |
firmware engineer is most comfortable with. |
96 |
|
97 |
I also think that once Eclipse (et. al) matures, many companies |
98 |
will port their BSPs over to Eclipse and be done with paying |
99 |
royalties, fees and (extorted) licenses to Micro Soft. |
100 |
|
101 |
just my 2cents. |
102 |
|
103 |
|
104 |
Here's a quick and dirty: |
105 |
> |
106 |
> http://openhardware.net/Embedded_ARM/OpenOCD_JTAG/#testocd |
107 |
|
108 |
> Basically, run openocd from the command line, specifying a config file. |
109 |
> Then telnet into it. ;-) |
110 |
|
111 |
> Someone may have glossed over this with a gui, but that's not what crops |
112 |
> up in google. |
113 |
|
114 |
>> Maybe we can all agree on a BSP that works well with a JTAG and |
115 |
>> Eclipse, and make it an option for Noobs wanting to get into |
116 |
>> embedded Gentoo? I think this is an easier sell than GNAP....? |
117 |
>> Keeping cost down is a good idea, and my early vote goes for |
118 |
>> an Arm9 board. |
119 |
|
120 |
> I haven't needed a jtag for it, since the bootloader was sufficient, but |
121 |
> I like the NSLU2 as a good starter kit. I recently saw one on ebay for |
122 |
> ~$30US. I bought mine new years ago for ~$70US. |
123 |
|
124 |
OK, if the group decides not to want a JTAG, then that's cool with me. |
125 |
Folks occasionally become interested in embedded gentoo, are open to |
126 |
what processor/board to use. IMHO, it'd be very cool to have an |
127 |
introduction to embedded gentoo, say like Das Blinkenlights, |
128 |
or Das AD/DA, on a simple, low cost board. Ethernet is the only real |
129 |
hardware requirement I'd suggest, so I'd be cool to whatever the |
130 |
consensus is. |
131 |
|
132 |
|
133 |
> The next step after that (at least, what I did) was the Gateworks 2348-4 |
134 |
> board. Same processor, 4 mini-pci, 2 ethernet, USB as an option. It's |
135 |
> less than $300US. Openocd works with it's parallel jtag programmer. I |
136 |
> haven't needed that yet either, since the bootloader works for me. |
137 |
|
138 |
Um, most of our customers want an custom bootloader. It's really not |
139 |
an option when you write firmware for a custom designed board that |
140 |
is going to become a product. Sure vendors provide reference code, but |
141 |
I've never seen that be sufficient for a product. I know lots of |
142 |
companies use code from the chip vendors (cisco), but, it gets them |
143 |
into trouble, more often than most realize. Besides a JTAG can be used |
144 |
for debugging lots of different firmware/hardware issues, particularly |
145 |
when you have limited/constrained resources and many things flying |
146 |
around, asynchronously. You could not even get a firmware engineer |
147 |
anywhere I've seen that would do a project, without a JTAG, BDM or |
148 |
ICE. This is where embedded linux (and hopefully embedded gentoo) can |
149 |
go to whole new level, when you customize device drivers for various |
150 |
optimized needs, under constrained resources. Am I talking about |
151 |
deviation from what the kernel gods have published? Sure, but only |
152 |
in small amounts, and it is done quite often with embedded products. |
153 |
Just look at the number of vendors now offering 'embedded linux'. |
154 |
|
155 |
|
156 |
> The ethernet support is native in the vanilla kernel since about 2.6.21 |
157 |
> or .23. As of 2.6.27, the kernel has support for the hardware crypto |
158 |
> engine. IPsec VPN gateway, anyone? |
159 |
|
160 |
I'm not trying to upset anyone, I just see things slightly different |
161 |
than most, because, as the end of the battle, I do want linux as a |
162 |
workstation development platform (complete with a killer IDE) and |
163 |
embedded linux (customized) as a ~rtos to win, or at least be a |
164 |
realistic option for many processors and new products. |
165 |
Sure (linux) is gaining market share, but, I think that |
166 |
is a (relatively) few products that hit very high volume. It certainly |
167 |
does not dominate where most firmware engineers actual do their work, |
168 |
imho. |
169 |
|
170 |
|
171 |
|
172 |
James |