What embedded device/tool/technology are you thankful for?

Thursday, November 24th, 2011 by Robert Cravotta

In the spirit of the Thanksgiving holiday being celebrated in the United States this week, what device, tool, or technology are you thankful for making your life as an embedded developer better? This can be anything, not just the newest developments. The idea is to identify those things that made a material impact during your embedded career.

As an example, my own introspection on the topic yielded a somewhat surprising answer for me – I am thankful for the humble USB port. I remember when my mentor came to me one day with a spec sheet and asked me what I thought about this thing called the Universal Serial Bus specification. We talked about that specification on and off over the course of a year or so, but never did I imagine the larger extent of the impact of so small a change.

Not only did USB simplify and make connecting and powering devices simpler and more reliable such that everyday technophobes could successfully use those devices, but it simplified development boards and workbenches all around because more and more of the new development boards that included a USB port no longer required a separate source for system power. As a consumer, I have recognized that I have not crawled under my desk to plug in a transformer in years – and for that, I am thankful.

There are many things I am thankful for, and these opportunities for introspection are valuable because they increase the odds of recognizing the mundane and nearly invisible changes that have permeated our environment – just like the invisible embedded devices that populate our everyday lives. What embedded device, tool, and/or technology are you thankful for?

40 Responses to “What embedded device/tool/technology are you thankful for?”

  1. Darnell Washington Jr. says:

    JTAG probes.

    Anyone who ever used an in-circuit emulator, those finicky things, knows what I am talking about.

  2. Jayaraman Kiruthi Vasan says:

    E8A emulator of Renesas MCUs. Seamlessly helping to cut down on development time.

  3. A. @ LI says:

    GPS in automotive and sports devices

  4. P. @ LI says:

    No. 1 USB…as a developer, programmer
    No. 2 HDMI as a general user

  5. J. @ LI says:

    Hi Robert,
    I am thankful for the Age of the Tools. In this Age, tools that enable the individual to transform ideas into things have empowered generations of creative engineers to create wealth from thin air.
    There is no single element responsible for this, but the concept that technology must be created for the creators, CAD, CAE, EDA, modularization, modelling, compilers, IDEs, embedded flash, free SPICE, HDLs, simulation.
    This revolution eventually was digested by us all, and now is taken for granted, to the point that people today expect things to be available for free.
    But there was a time when product development was only available to large corporations, and very large engineering teams. A simple PCB would cost tens of thousand dollars, and firmware development systems were special technical workstations, with compilers and emulators, that cost hundreds of thousands.
    Today the dream workstation is in reach of the average person, and one can sit at home and develop ASICs, prototype FPGAs, simulate complete analog circuits, design a PCB, send it to fabrication, develop firmware and have a full professional product, for a fraction of the cost that once it was.
    The Age of Tools also extends to every other aspect of engineering. You can become member of a club that makes available heavy tooling like welding, lathing, milling, sawing to any member.

    In this age, just add brains and dreams and you can do it. It is a most heartwarming feeling to live in these days.
    - Jonny

  6. R.G. @ LI says:

    I am thankful for the embedded tool In-circuit emulator, as it provides full control over all aspects of the microprocessor speeding the application development and also, RTOS , as it highly simplifies the application design.

  7. M. @ LI says:

    A fast serial port! In fact the RS232 standard is probably the best thing that happened – simple enough to be implemented on just about every embedded target. It can be used to debug software without needing any form of debugger – in fact I hardly ever use debuggers these days.

  8. S. @ LI says:

    GOOGLE search – for providing answers to all my development problems.

  9. A. @ LI says:

    1.ANSI C – 99.9% is same for HOST and TARGET!
    2.Internet – 80% of all solutions come from GOOGLE in 5 minutes.
    3.FPGA – 70% don’t have to throw a PCB because of one H/W ‘bug’ ;-)
    4.QEMU – 50% target is not needed, automated builds verification, no cross compiling!

  10. M. @ LI says:

    The age of GPL and open-source. For example I could opt for geda/pcb, gcc, insight & avrdude. I can develop a complete solution, schematic, layout & firmware, from the ground up with GPL open-source tools using *any* host OS of choice. A bug in the tool, I just fix it, and move on.

    A man no longer needs to stop and ask for directions except to find the source repository, with no limits over the control over their environment.

  11. R. @ LI says:

    This is a fun idea for a topic and it’s interesting how many of them are ubiquitous things we give little thought to like USB or WIFI. My humble candidate is flash memory. I have a box in the garage with some 1702A 256 x 8 EEPROMS and a UV light to erase them that I’m very grateful I don’t have to use!

  12. A. @ LI says:

    My vote is for completely integrated design environments. Some tools now allow complete hardware, firmware (fpga) and software design implementation without leaving the top level GUI. This allows me to take designs from concept into production with a small efficient team.

  13. H. @ LI says:

    1. Debugger
    2. Google
    3. Integrated design environment

  14. R. @ LI says:

    My first instinct was GPSim, but I’ll expand that to general agreement with Mark – open source! When I first encountered GPSim I was trying to develop for rom-based PICs without spending too much. MPLab contained a simulator but it was next to useless because it only dealt with the core. GPSim was designed by people like me, for people like me, and is open-source so I could fix its foibles.

  15. H. @ LI says:

    I would definitely thankful to IDE’s which just allows me to have fast software development and it also ease mine task of testing and debugging and since most of IDE’s now provides support for hardware debug its like a single GUI will help you to complete your entire embedded product cycle.

  16. F. @ LI says:

    Coffee. Definitely coffee.

    I think it fits into the “meta-embedded tool” category.

  17. Dirk Bruehl says:

    I have to admit that all things mentioned here up to now make our life as an embedded developer better and easier.

    But my personal thanks go to Mr. Chuck Moore, who thought about real communication with computers years before starting with embedded systems. His brilliant approach, named FORTH, being programming language, operating system, and Integrated development environment at once, enabled me to work with different microprocessors with ease and high productivity.

    My best experience was with projects using HARRIS’ RTX2000, the first microprocessor having FORTH as machine language, executing up to 4 high level commands in one clock cycle. It was amazing to me how fast programming was done and how fast programs where running.

    That was Thanksgiving. The next season is for making a wish, and my wish is to have a microcontroller with FORTH as it’s native machine language, as easy to use as the RTX2000.

  18. R. @ LI says:

    IDEs,
    ICEs,
    Virtual Machines
    GCC, Linux, the most
    Flash Memory
    ARM

  19. J. @ LI says:

    Coffee, ANSI C, gdb, and oscilloscopes.

  20. S. @ LI says:

    Flash Memory (anybody who had to use UV erasable micros should understand)
    Modelsim (somewhat quirky interface but essential)

  21. C. @ LI says:

    Debug, debug, and debug

    On-chip debug/trace
    JTAG/ICE debugger interfaces
    Symbolic debugger software

    After that RTOS’s

  22. N. @ LI says:

    My best- JTAG gave us access to the internals of highly dense modern processors, without which we would be blind

  23. T. @ LI says:

    The “delete” key.

  24. C. @ LI says:

    Flash memory
    JTAG programming tools

  25. A. @ LI says:

    Lauterbach Trace32

  26. D. @ LI says:

    The gcc toolchain, which meant that basically the same toolset can be used for any architecture except the PIC ;-)

  27. S. @ LI says:

    Source level debuggers, Flash memory, JTAG, open source, www, scopes, 32 bit CPUs, FPGAs. There is so much to be thankful for!

  28. P. @ LI says:

    To me Flash memory and Emulator as well as C language helped a big step forward.
    I would also add the constant increase of power of microprocessors

  29. T. @ LI says:

    Back in the 1980′s I was privileged to use a plug-in for a Tek scope that allowed me to trace code on an 8049 processor. Trace mechanisms since have built on that…

  30. M. @ LI says:

    For me is CANAlyzer, and MicroC RTOS

  31. E. @ LI says:

    For me it is the low cost JTAG programmer, debugger/trace tools which removes the need for expensive hardware based emulators dedicated to each processor type.

  32. N. @ LI says:

    ANSI C, RISC micro, Lauterbach tools

  33. S. @ LI says:

    ARM Architecture, Higher languages than assembly, Free and open-source friendly minds and most of all the people sharing information on internet.

  34. R. @ LI says:

    Logic analyzer cores for FPGA, and not just for hardware design. Snooping on a bus has proven invaluable in debugging code as well, especially for low level systems like DMA.

  35. H. @ LI says:

    The Salaea tiny low cost logic analyser has proven absolutely great for my microcontroller projects ! Hook it up to some free I/O lines and set/clear them in your code to get trace information in real time, or analyse your serial comms, or real time timing analyses, PWM outputs etc. Just great !!!

Leave a Reply to G. @ LI