I post this from Paris. I saw a Pekee from Wany on an exhibition a year ago. Wany is a french company based in the south (Montpellier).
Actually it *does* run Linux. Anyway I completely lost any interest in the product since:
- they're incredibely expensive
- since 2 years or so that the company exist and make big anoucement, since 1 years that I actually saw one, Wany never seemed to care to let out a Linux SDK (as they anounced looooooong ago)
I don't think Wany is going anywhere. Did not indentify their marker, neither their users in 2 years.
Why not a Windows SDK, sure, but were is the Linux one? This is Wany own in-house native SDK, come on!
Would you buy this?
GPL violation possibilities cross my mind. If not, why?
Chose the software first (dev and debug tools), then the target.
I'm not sure that setting up a cross-dev chain is a must, but learning to *use* some is mandatory.
In the gcc chain, at least the binbutils part, there are tools like objcopy or objdump that you may not heard of if you stay with PC/PC.
Embedding is cross-compiling.
It's not just the same: different object format, static vs dynamic link, endianeness, different library... and then there's the upload to target and debug step. cross/remote-debugging is special: is slows down your code-compile-debug cycle, you may not have the full debuger capability your used to, you may have to write some debuger script to put your target in a known step first. Will you debug via serial with a ROM-monitor of a kind, via ethernet, with BDM, will you use an ICE...
So do use a cross-compiler, and do use a remote debuger. You don't have a real contact with embedding as long as you stay PCPC104. PC104 is an industrial reality, but you asked about "learning", not doing actual projects. be assure that someone trained on a cross environment will be at ease in a PCPC setup.
Considering the target, wich was your question ine the first place: two criteria comes to mind.
- supported by gcc
- not Intel x86 architecture (see above: cross!)
One of gcc main point is the broad range of CPU family it supports. Just say "32 bit" and gcc is there. So time spent on gcc can be recycled on other CPU.
BTW I build my first cross-gcc chain using the excellent (even if at the time these were only draft) documentation from Bill.
I now I use the RPM from OAR/RTEMS http://www.oarcorp.com
They are available for PC host towards most target CPU, binutils+gcc+newlib. At least Motorola 68000, PowerPC, Hitachi SH, of course Intel x86, ARM I think, MIPS maybe + others?
Slashdot Mirror
I post this from Paris. I saw a Pekee from Wany on an exhibition a year ago. Wany is a french company based in the south (Montpellier).
Actually it *does* run Linux. Anyway I completely lost any interest in the product since:
- they're incredibely expensive
- since 2 years or so that the company exist and make big anoucement, since 1 years that I actually saw one, Wany never seemed to care to let out a Linux SDK (as they anounced looooooong ago)
I don't think Wany is going anywhere. Did not indentify their marker, neither their users in 2 years.
Why not a Windows SDK, sure, but were is the Linux one? This is Wany own in-house native SDK, come on!
Would you buy this?
GPL violation possibilities cross my mind. If not, why?
You can't buy a laptop without *paying* for an OS.
So the question is:
- would you *pay* for a game/DVD/etc OS?
- would you *pay* for an OS where you can launch a terminal/vi/emacs off the shelves?
In booth cases you can also install a GNU/Linux distro.
(yes I made my choice last summer: iBook)
Chose the software first (dev and debug tools), then the target. I'm not sure that setting up a cross-dev chain is a must, but learning to *use* some is mandatory. In the gcc chain, at least the binbutils part, there are tools like objcopy or objdump that you may not heard of if you stay with PC/PC. Embedding is cross-compiling. It's not just the same: different object format, static vs dynamic link, endianeness, different library... and then there's the upload to target and debug step. cross/remote-debugging is special: is slows down your code-compile-debug cycle, you may not have the full debuger capability your used to, you may have to write some debuger script to put your target in a known step first. Will you debug via serial with a ROM-monitor of a kind, via ethernet, with BDM, will you use an ICE... So do use a cross-compiler, and do use a remote debuger. You don't have a real contact with embedding as long as you stay PCPC104. PC104 is an industrial reality, but you asked about "learning", not doing actual projects. be assure that someone trained on a cross environment will be at ease in a PCPC setup. Considering the target, wich was your question ine the first place: two criteria comes to mind. - supported by gcc - not Intel x86 architecture (see above: cross!) One of gcc main point is the broad range of CPU family it supports. Just say "32 bit" and gcc is there. So time spent on gcc can be recycled on other CPU. BTW I build my first cross-gcc chain using the excellent (even if at the time these were only draft) documentation from Bill. I now I use the RPM from OAR/RTEMS http://www.oarcorp.com They are available for PC host towards most target CPU, binutils+gcc+newlib. At least Motorola 68000, PowerPC, Hitachi SH, of course Intel x86, ARM I think, MIPS maybe + others?