Recently, I was working with a touch-interface development kit as part of a hands-on project that I am publishing about over the next few months. The out-of-the-box experience was clean (although there was a media hiccup), and the demos worked as advertised. The next step was to build a “hello world” version of a touch interface program to make sure I correctly understood how to operate the system from scratch.
The development kit offered several ways to initialize the target processor. Instead of manually setting all of the registers, I chose to use the supplied configuration wizard. Even though the configuration wizard supplied the source code to initialize the processor, I cannot say it greatly lessoned the learning curve for choosing what the initialization settings should be. However, it did allow me to focus on the settings without too much worrying about the coding mechanics.
The next step was to start using the supplied API (application programming interface) to activate and query the touch interface controller. For the hello world project, I decided to toggle a light on and off whenever I pressed a specific touch button on the development board. I loaded the program and began execution, but touching the button never activated a message for the application code to process. After a bit of trying this and trying that, I realized the timer that the touch controller used was disabled.
I had assumed that the configuration wizard and touch controller API were tightly coupled and that together they would select the appropriate default settings for a touch application on the target system. However, the configuration wizard disabled the timer and the API initialization call did not enable it. This is a simple problem to fix, and I suspect the support team for the development kit will either change the API initialization call to enable that timer or change the documentation for the API call to make it clear that the application code must manually enable the timer. I personally think the API call should abstract enabling and disabling the timer.
Enabling the timer however was not sufficient to make the button activate a message to the application code. It turns out the timeout delay for the touch sensor had been set too short to allow it to register when the user had touched the pad. The timeout delay was not a direct setting; rather it was derived from several other settings. While the configuration wizard simplified the coding for those settings, it did not abstract the derivation of the timeout delay and display that to me when I was choosing the values to use. A conversation with the support team for the development team suggests they will be adding that type of feedback to the wizard.
Initializing a processor that is not using an operating system has always been significant effort. Many companies now offer configuration or initialization wizards/tools to help developers use their processors. My question is, do you find that these tools simplify the learning curve for initializing your target processor? Do they make the process faster and more reliable? What lessons learned could you share about how to best use these types of tools?
If you have a question you would like to see in a future week, please contact me.
Processor Tracker
All Entries RSS Feed
Many of the MCU vendors distribute tools similar to what you have described. Some offer I/O interface libraries, too. My experience is that these things are designed to ‘give great demo’, to allay the fears of managers who have heard of all the sort problems you were trying to avoid – and want to delude themselves into believing that these software tools will simply make the problems vanish in a click.
Yeah, right. Maybe if you have completely trival appliation that uses only a tiny percentage of the MCU capability. If you have anything complex, you need to understand the MCU and its peripherals – and you are better off handing all hardware initialization on your own, and documenting what you are doing. Yes, it is difficult. That is why embedded engineers are so different from ‘programmers’.
My experience with vendor supplied I/O libraries is that they MAY be a source of usable demonstration code.. but that is all.
In my experience the tools are worse than useless. They make it look like initializing the system is as simple as a few mouse clicks. In reality they get something like 90% of the configuration correct. You are then left to figure out the remaining 10% that it did not get right or did not initialize. You spend just as much time pouring over the documentation and checking every bit as if you wrote all the initialization code yourself. I suppose the tool saves a bit of typing but other than that I have not found them to be worth the trouble. I have also only found tools like this for older MCU’s. If you’re using one of the latest and greatest tools like these either do not exist or have so many bugs that you do not want to use them.
Nothing trumps a hardware knowledeable engineer who builds a good set of descriptor header files from the manufacturer’s user manual imho.
It seems funny to me that the “wizard kits” are trying to patch a problem which has historical roots (limited available transistors), but which I am tempted to think manufacturers could design away from today.
Now-a-days, the limiting factor is usually pins. I propose we throw out the old model of figuring out just how many different features can/could/are/default-to impacting the pin of interest. Instead, let me simply turn a feature on or off. All the needed pins get enabled or disabled at the same time. An XOR gate will ensure that conflicting features don’t both get turned on.
Since the embedded developers have to think in terms of features being supplied to their customers, the manufacturers could help by designing the uC setup to work in terms of features. They do this to a degree by grouping related registers by address, but they could do more by tying in pin functionality too.
-D.
If you work on small MCUs, the pin limitation only makes the initialization issue more complex, because multiple functions are assigned to a pin, and in many cases the same functions are ALSO available on other pins – but all of them conflict with something else somewhere. The XOR functionality may simply mean that you accidently turn OFF things that you want. You have to RTFM AND the errata notes AND use some experience and common sense to make it all work. The worst part is trying to keep track of all the documentation errors and shortcomings when dealing with electronic documentation. There is nothing quite as useful as a highlighter or post-it note for an electronic document.
The more complex the MCU and the application, the less useful the whiz-bang tools will be!
I’ve never used one of these tools but then again, I’ve never thought the initialization was a “significant effort”, either.
The only similar tools I’ve ever found useful were the calculators for setting up the bit timing for CAN and even there, they often give you a set of recommendations and you need to choose one based on knowledge and experience and do the initialization yourself.