Hi, hum I didn't expect this discussion to take this direction but it's interesting..
On Mon, Apr 27, 2009 at 3:58 AM, Prince Riley <[email protected]> wrote: > If you check in with a few more Emdev engineers, those putting consumer > products and firmware out, you'll find that too often embedded engineers and > chip makers shudder at using OSD project code as a platform because their > dev system based on GNU tools sets which they feel have too steep a learning > curve and too many gaps and holes in it. > > That's may sound wrongheaded, but they would rather pay 25K to 50K for a > license for a tool with all the pieces in place than muck about with GNU TTY > tools these days. All the major em dev houses use GNU toolchains with GUI > frontends tools and sell them, so its not very easy to get them to look at > anything but something that puts all the code cycle tools together wrapped > tight with no heavy lifting. > I think there are _two_ issues here: 1) Integrating the installation of all the bits [tool chain, user space, ...] 2) GUI front ends. I think Emdebian already addresses 1) quite well. In the old days you used to have to start by compiling your compiler; with Emdebian all this is just an aptitude install away. Also remember that, on your dev workstation, you have all the power of Debian to compose everything you need from Debian packages. I sometimes wonder how much of the GUI usage is "developer pull" and how much is "marketing push". Its a bit like point and click system administration tools - look great when the salesman does the demo but when you have to create 1000 new accounts for the new students a command line and a scripting language starts to look a lot nicer. Even Microsoft, after years of trying to write off the command line as 'has been', has started to provide reasonable shell interfaces in their latest products. Like many others I'm not a great fan of GUIs either. In my experience the "better" devs [the ones that everyone goes to when it doesn't work...] tend not to like / use gui tools either. In particular I don't like debuggers (at least not used in the classic step/breakpoint mode) because they don't promote an efficient work cycle - you tend to end up always stepping through the same code. They also hide timing problems. I find it much more efficient to add code instrumentation (printk, debugfs or equivalent) which can then be analysed off line with scripts if needed and sometimes even used in field. They are sometimes useful for initial bootloader startup and post mortem analysis of panics etc. That said if Emdebian wants to provide GUI wrappers why not - but I strongly suspect the team has more important things to do. Another thing is that I expect any dev environment to be scriptable and all the tools to be installable from Debian packages. For any project I want the bare PC to working dev environment process to look like: 1) Install base Debian 2) Add entry to sources.list for in house repository 3) aptitude update && aptitude install my-project-dev-env 4) svn co <url> [or git clone..] 5) make kernel && make rootfs [in the above my-project-dev-env is a mostly empty package that just depends on all the packages that may be required and maybe includes a few helper scripts]. I have, unfortunately, seen GUI based projects where the equivalent of the above is a 100 page MS Word document explaining in click by click detail how to install eclipse and all the other tools. And once its all installed the build should be one or two commands like the above [so that it can be automated on a continuous integration build server if required]. Any GUI wrapper really must be a _wrapper_ that runs the same scripts so as to have _one_ reproducible, way of building not the "command line way" and the "gui way" [or more likely 'GUI way as setup by Tom', 'GUI way as setup by Dick' ...] > Just take a look at the Beagle board and Gumstik projects. What are the > serious developers using.? You'll quickly see that you won't get many of > them to adopt much less even look at this kernel for embedded work unless > the tools are all there,idot proof, well supported and fully developed. > I don't know, please tell me. > If you ask on a few of the mailing lists for these and other projects, > you'll hear back that embedded Debian has a great deal of potential. At the > same time it also has a great deal of competition. There are just too many > other embedded kernels with full dev sets already out there to really > bother going back to square one. > Emdebian doesn't provide a kernel (and IMHO nor can it or should it) I also don't want my userspace and toolchain to be closely tied to the kernel. When switching projects I prefer to keep the userspace tools. To be honest I don't like vendor supplied kernels at all - you tend to locked into old code [for instance the Freescale BSP for i.MX21 is 2.4.24 !] That does depend on your product lifecycle though - if your doing a "ship it and forget it" product thats going to last 12 months it might be acceptable - the stuff I work on has to be maintained for 10 years. Martin -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
