Skip to main content

Building Blocks.

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?

Comments

Popular posts from this blog

The Bridal Dowry.

The delivery of dowry ( 送嫁妆 ) is another important custom. It represents parent's effort for her daughter to have a good life after marriage and prepare her with the necessities for being a good wife. I am amazed by some of the things included in the dowry. Of course, in our modern living, we will not be using some of those things... Nevertheless, I think it is all good to have them, as each item carries a good meaning for our blissful marriage. :-)

If you have it, just flaunt it.

Its such a lousy day, I have decided to blog another entry. Yesh, I am thinking about things other than my last two papers on Thurs and Friday. Something probably talked alot before by many people... What is it with men and women with 可爱-oooii *杨丞琳's voice* face, long tresses, slim legs, curvey body, in revealing tight clothes (only for those with the former characteristics), in pink. Why are men so attracted to those features? The guy is lying if he says he will not turn his head when he sees women with those features. I think it has nothing to do with men being lustful or anything disgusting. It probably has something to do with the genes, the hormones. I don't believe it has to do with things like its men's nature instinct to look for partners who can reproduce blahblahblah. That's so boring! Its something mysterious, something that let men derives pleasure by just looking openly, without doing anything bad or harmful or immoral. Do women ogle at men all the time too

Dreaming About You.

I usually leave my handphone on during the night (just in case if anyone want to contact me urgently, eg. a friend in need of help etc). But I think I will be leaving my phone off from now on. Why? In the wee hours this morning, I received three continuous sms . I forced myself outta bed to read the message, thinking it must be something very important. I surprised to read that they were messages from " Dreamchat ", telling me that " someone is dreaming of me ". Oh great! What a good reason to wake me up! It also asked me to call this 1900 number to listen to the message. There was even a member id at the end... So someone still wide awake in the middle of the night decided to use this wonderful service to let me know he/she is dreaming of me leh. wah seh. I immediately deleted the messages and went back to sleep. Knowing I will just have a few more hours of my six hours daily sleep time left. How did this " Dreamchat " thingy got my handphone number? Is