For a project I want to use the Teensy 3.1 board (see “Hacking the Teensy V3.1 for SWD Debugging“) in USB CDC mode: that way the Teensy board can connect to the host and exchange data or attach a console to the Teensy board: that way I can connect the Teensy over USB to the host use the USB as communication interface:
Teensy with Octo WS2811 Board
Frequent readers of this blog know: I’m using Processor Expert in most of my projects with CodeWarrior, Driver Suite or Kinetis Design Studio. With the move of Freescale to Kinetis Design Studio and the Kinetis SDK with Processor Expert, there is an opportunity for our voice to be heard in a survey Freescale now runs about configuration tools and Processor Expert.
Processor Expert
Happy Surveying 🙂
In one of my earlier posts (“Using the DHT11/DHT22 Temperature/Humidity Sensor with a FRDM Board“) I’m using the DHT11/DHT22 temperature/humidity sensors with the FRDM-KL25Z board. These sensors are very inexpensive, but have limited measurement range and accuracy. As pointed out by a reader of that article, Sensirion (a Swiss company :-)) has good sensors too, and I decided I would like to try the SHT11 sensor:
SHT11 Sensor
There are cases where my application runs find for days, weeks or even months, but then from time to time there is an application crash. Yes, the watchdog will recover it, but still it would be good to know what happened? One solution would be to hook up a trace probe (like the one I have described in this post: “First Steps with the P&E Tracelink“). But having such a trace probe attached all the time is first not cheap and second not always possible. So what if the application would leave ‘breadcrumbs’ behind which would tell me the flow of the program leading to the problem? I have found a functionality in the GNU tools which seems not be widely known or use, but is incredibly helpful in such cases.
So what if I could get a log like this telling me which functions get called by whom?
{ 00000E88->00000DA0 ???->DEMO_Init
} 00000E88<-00000DA0 ???<-DEMO_Init
{ 00000E8C->00000D40 ???->DEMO_Run
 { 00000D62->00000CE8 DEMO_Run:0x0022->decide
 { 00000D0E->00000C60 decide:0x0026->calcValue
 } 00000D0E<-00000C60 decide:0x0026<-calcValue
 { 00000D16->00000CA0 decide:0x002E->getValue
  { 00000CC6->00000C60 getValue:0x0026->calcValue
  } 00000CC6<-00000C60 getValue:0x0026<-calcValue
 } 00000D16<-00000CA0 decide:0x002E<-getValue
 } 00000D62<-00000CE8 DEMO_Run:0x0022<-decide
 { 00000D62->00000CE8 DEMO_Run:0x0022->decide
Short post for April Fools’ Day :-):
From time to time I get questions about books for embedded systems and programming. [Tom] pointed me to an interesting book about programming the ARM Cortex M using the Freescale FRDM board. Even better, he was so kind to write a short review. So there is now a Books! Page available. If you have other books to recommend, post a comment or better a review and it will get added.
Happy Reading 🙂
To facilitate student learning and preparation for the exams, I passed today a collection of exam questions with solution hints to the students. And as well why I’m *not* asking simple ‘true or false’ questions my exams:
The Right Way to Answer True or False Questions
🙂
There is a really annoying issue with using command line tools on Windows: the maximum length of the command line passed to cmd.exe is 8192 characters (see http://blogs.msdn.com/b/oldnewthing/archive/2003/12/10/56028.aspx). So you think this is not a problem for you, as you would not pass such a long command line to cmd.exe (the DOS shell under Windows)? Well, if you are using Eclipse (as I do) which generates make files (which is the normal way), then the cmd.exe very likely is involved to call the compiler/linker/etc, indirectly with the usage of make.exe. Compiling files is usually not a problem as it does not hit that 8192 limit. However, it is likely that link phase will end up with an error:
Error in the Problems View
If you have such a problem, there is a solution ….
For a home automation project I need to know the room temperature and humidity percentage of the room air. Adafruit has an inexpensive DHT11 sensor from http://www.aosong.com which I decided to use for that project.
Test Setup for DHT11 Sensor
If you are designing your own board for the Freescale FRDM boards, then having the matching PCB design files is a good thing to have. I have posted this week an Altium contribution on GitHub for the FRDM headers (see “FRDM-KL25Z Arduino Headers with Altium“). And here there is yet another contribution I received from [Darren]: the FRDM-KL25Z board in Altium :-):
FRDM-KL25Z in Altium
Eclipse with GDB is great: it comes with a graphical front end for debugging. But sometimes it is all about to download a program. Is it really necessary to launch an IDE like Eclipse to program or quickly debug a board? With the GNU Debugger (GDB), the answer is ‘no’: GDB comes with a command line debugger which is designed exactly for this: providing a command line interface for programming/downloading and debugging, bypassing any GUI (Graphical User Interface).
Combination of GDB Debugging Probes and Boards (P&E, Segger and FRDM-KL25Z)
MCU on Eclipse 