Skip to main content

Posts

Showing posts with the label embedded

CANbus on the Omega2

Omega2S Omega2+ If you are as big a fan of the Omega2 as I am I'm guessing you want to do as much with the platform as possible. Recently I've been looking to get a low cost Linux system on a CANbus, to sniff on some traffic. What are the options for adding a CAN interface to your Omega2, either when you are designing a solution or looking to easily add it to an existing system? eLinux has a great guide on a number of CANbus adapters that I'd recommend to anyone looking to integrate CAN into their system. Interface Typical use case Available on Omega2 / Omega2S serial (via SLCAN) Design-in/Add-on Simple protocol but not considered reliable, efficient or fast by Linux CAN developers . SPI Design-in Not usable , the Omega2 (MT7688 cpu) is only half duplex SPI Software SPI Design-in Higher cpu load than hardware SPI USB Design-in/Add-on Available (Omega2 has one USB host port) Note that all of the design-in options could be used ...

Oscilloscope assisted debugging

Concept External test equipment is a powerful but often overlooked tool for debugging particular kinds of software problems. In particular, test equipment like oscilloscopes and logic analyzers are well suited to investigating timing related issues on embedded systems. Why is test equipment suited to helping with issues related to timing? Oscilloscopes and logic analyzers can easily provide microsecond or better measurements and, unlike software based monitoring approaches, they aren't affected by other software running on the system. Embedded systems are ideal for this approach as they both provide the io outputs required for timing measurement, and often lack the advanced debugging facilities found in desktop/laptop processors and operating systems that would make this approach less necessary. At the conclusion of  debugging some 1-Wire bus contention issues  I was still seeing CRC errors reported periodically. Here is how I used an oscilloscope to track down the lik...

Bus contention on a 1-wire bus

Background I've been playing around with the Maxim  DS18B20 digital temperature sensor. These are neat devices that provide a digital temperature, which means they provide an actual Celsius reading in digital form, with a pretty high level of accuracy, +/- 0.5C from -10C to 85C. They are also quite compact. Here is the typical TO92-3 form factor that the DS18B20 comes in. Why not a thermistor connected to an ADC? Your microprocessor may not have an accurate enough or linear enough ADC to let you attain the desired temperature accuracy. In my case I'm using the Espressif ESP32 . The ESP32 is a great processor but its ADC still needs some work . Code to linearize the ADC results was added earlier this year but the biggest missing piece is proper calibration of the ADCs vref. Without this the scaling of ADC values can vary by several percent. Good news is that factory calibration is possible and should be coming. Thermistors also have a non-linear resist...

Performance of std::vector vs. arrays

The surprising results of a performance comparison between std::vector<> operator= and memcpy() with a raw array. An application profiling effort by a colleague and I led us to investigate the performance tradeoffs between std::vector<> and a raw array ( uint8_t blah[] ). The application was a c++ rewrite of a c# application. The rewrite was undertaken because the overhead of running a c# application on our memory and cpu constrained ARM Linux system was affecting system performance and responsiveness. Using Mono to run C# applications on Linux resulted in ~40MB of ram overhead for our application that itself allocated tens of thousands of bytes at most. Startup time left much to be desired. It took a few seconds to start the application up from mmc on the 1GHz ARM processor. We verified the long startup time by printing an “I’m started” string as the first function in Main. We tried upgrading to a newer version of Mono to see if that would improve performance. We las...