This article by Ed Nisley in September issue of Dr. Dobb's Journal reminds me of my FYP days. It was the time when I first got acquainted with the embedded world, thinking that nothing is impossible as long as I am willing to learn and try. When I first wrote the proposal for my FYP, my ideas were ambitious, an integrated smart home system prototype accessible via the net. But I did not consider some very important things, the time factor and the difficulties in hardware-software integration.
I started with modifying high level application design available off the shelves, to coding the firmware and debugging the hardware. It was sort of a reverse process where you dig deeper and deeper to the level where you can be comfortable with dealing the problem. Yet, after months of struggle, I only managed to get the firmware working with about 3 months left from deadline. That is kinda far away from the wonderful application I had in mind earlier.
Although the board design followed an eval board closely, it was no easy task getting my firmware working on my custom board despite using the eval board codes as reference.
I learned that there are many possible reasons for the board or the firmware to fail. Not to mention there are many important small prints in the chipset user guide that are very crucial to the development. And usually things off the shelves can't quite work the way as you want in an embedded project.
Although I have wanted to an embedded software engineer and get excited whenever I see an ad looking for one, with the jobscope that seems to be my dream job, I do have mixed feelings. Along the development phase, it can be quite discouraging, with day in and out not achieving any results. In low level programming, moving of bits and bytes between registers can be kinda tough, especially ploughing through the datasheets and user manuals for endless times. So although I'm doing Java programming now (something I couldn't quite figure during school days), instead of my dream job, I have gotten comfortable with the current situation. At least all the resources are readily available and codes off the shelves usually work fine with minor modifications. Of cuz, those who have not gone through hardship will not know how sweet life is.
I guess for FYP its important to set realistic goals and deadlines. And not to limit your research scope to certain areas only. More importantly, if something don't work, keep working on it, and it'll eventually. Although I did not get an A for it (I grumbled bout it before), it was great satisfaction, especially from the comments of my supervisor and examiner. For those still working on their FYP, don't give up yet! This December holiday is the time to bia and look forward to those breakthroughs! It is a wonderful feeling!
Embedded Space: Monoculturalism - Building Blocks
On the hardware side, classic small-scale embedded-system design sarted with datasheets for single integrated circuits that were actually comprehensible to one person. The chip designers specified how the external hardware must behave, to the extent Motorola and Intel microprocessors might as well have been from different planets, and embedded system designers continued that process to produce completely unique chunks of hardware.
Eventually though, vendors notices that most of the gadgets looked pretty much the same: A microcontroller, some external memory, an assortment of digital and analog I?O, plus some communication ports. Add a few status LEDs and a debugging port: Shazam, everyone could use a single board. At least if they were willing to buy a few features they didn't really need, which generally turned out to be the dealbreaker: The cost of the board was relatively high compared to the cost of the final product.
Nowadays, chips have become sufficiently complex that reading the datasheet does not give you confidence that you can actually build a working gadget. Chip vendors now produce "evaluation boards" to provide an existence theorem: If you interconnect the hardware using this exact board layout, then run this software, the chip behaves properly.
Once you've seen it work, the theory goes, you can adapt it for your own use, write your own code, and go on your merry way to satisfy your customers. Any problems can be traced back to differences between the eval board's design and your efforts, so figuring out what's going wrong shouldn't take all that long.
In actual practice, however, the adaptation process sometimes goes along these lines: "This works, so we'll just run with it!" Grafting an eval chip's layout onto your board is one thing, but shoehharning sample code into a production application becomes something quite different and rather scary.
Eval board code tends to be written for the very specific purpose of showing how the circuit works. Considerations of realibility, error handling, overall structure, and security tend to fall by the wayside, even in ordinary projects, but particularly for sample code tat's written very, very early in the chip's design stage. As a result, eval board code comes with a surprisingly high level of cruft, not to mention outright errors in lesser used functions.
Nevertheless, there's an awful pressure to make as few changes as possible, because you (or your boss) really wants to concentrate on the rest of the project, the part that contains your unique and no doubt valuable IP, rather than building-hardware and code.
Sounds familiar?
I started with modifying high level application design available off the shelves, to coding the firmware and debugging the hardware. It was sort of a reverse process where you dig deeper and deeper to the level where you can be comfortable with dealing the problem. Yet, after months of struggle, I only managed to get the firmware working with about 3 months left from deadline. That is kinda far away from the wonderful application I had in mind earlier.
Although the board design followed an eval board closely, it was no easy task getting my firmware working on my custom board despite using the eval board codes as reference.
I learned that there are many possible reasons for the board or the firmware to fail. Not to mention there are many important small prints in the chipset user guide that are very crucial to the development. And usually things off the shelves can't quite work the way as you want in an embedded project.
Although I have wanted to an embedded software engineer and get excited whenever I see an ad looking for one, with the jobscope that seems to be my dream job, I do have mixed feelings. Along the development phase, it can be quite discouraging, with day in and out not achieving any results. In low level programming, moving of bits and bytes between registers can be kinda tough, especially ploughing through the datasheets and user manuals for endless times. So although I'm doing Java programming now (something I couldn't quite figure during school days), instead of my dream job, I have gotten comfortable with the current situation. At least all the resources are readily available and codes off the shelves usually work fine with minor modifications. Of cuz, those who have not gone through hardship will not know how sweet life is.
I guess for FYP its important to set realistic goals and deadlines. And not to limit your research scope to certain areas only. More importantly, if something don't work, keep working on it, and it'll eventually. Although I did not get an A for it (I grumbled bout it before), it was great satisfaction, especially from the comments of my supervisor and examiner. For those still working on their FYP, don't give up yet! This December holiday is the time to bia and look forward to those breakthroughs! It is a wonderful feeling!
Embedded Space: Monoculturalism - Building Blocks
On the hardware side, classic small-scale embedded-system design sarted with datasheets for single integrated circuits that were actually comprehensible to one person. The chip designers specified how the external hardware must behave, to the extent Motorola and Intel microprocessors might as well have been from different planets, and embedded system designers continued that process to produce completely unique chunks of hardware.
Eventually though, vendors notices that most of the gadgets looked pretty much the same: A microcontroller, some external memory, an assortment of digital and analog I?O, plus some communication ports. Add a few status LEDs and a debugging port: Shazam, everyone could use a single board. At least if they were willing to buy a few features they didn't really need, which generally turned out to be the dealbreaker: The cost of the board was relatively high compared to the cost of the final product.
Nowadays, chips have become sufficiently complex that reading the datasheet does not give you confidence that you can actually build a working gadget. Chip vendors now produce "evaluation boards" to provide an existence theorem: If you interconnect the hardware using this exact board layout, then run this software, the chip behaves properly.
Once you've seen it work, the theory goes, you can adapt it for your own use, write your own code, and go on your merry way to satisfy your customers. Any problems can be traced back to differences between the eval board's design and your efforts, so figuring out what's going wrong shouldn't take all that long.
In actual practice, however, the adaptation process sometimes goes along these lines: "This works, so we'll just run with it!" Grafting an eval chip's layout onto your board is one thing, but shoehharning sample code into a production application becomes something quite different and rather scary.
Eval board code tends to be written for the very specific purpose of showing how the circuit works. Considerations of realibility, error handling, overall structure, and security tend to fall by the wayside, even in ordinary projects, but particularly for sample code tat's written very, very early in the chip's design stage. As a result, eval board code comes with a surprisingly high level of cruft, not to mention outright errors in lesser used functions.
Nevertheless, there's an awful pressure to make as few changes as possible, because you (or your boss) really wants to concentrate on the rest of the project, the part that contains your unique and no doubt valuable IP, rather than building-hardware and code.
Sounds familiar?
Comments