Cookies disallowed, click button to change.
Cookies allowed, click button to disallow.
"Productive programming of modern embedded systems is a challenge. For example, consider a smart phone that is using multiple processor cores of multiple capabilities. The functionalities of these cores vary dynamically based on the application requirements; different cores are running on different OSes.
One of the OSes might be handling user interface plus file and data management and the other core, invisible to the user, might be managing low-level activities such as connecting and handling calls. It is a complicated task for a single OS to track and manage all resources and operations, hence the need for more than one OS. How to enable communication between cores, share resources, and synchronize accesses? Some other complicated programming questions include:
1. Can conventional thread creation and management techniques that were originally developed for general purpose processors be used for embedded platforms? Hint: Resource is scarce in embedded systems - the maximum number of cores available on an embedded platform is presently 64.
2. What are the challenges that embedded platforms pose with regard to memory accesses? Hint: Embedded systems contain multiple memory spaces that are dedicated to each core. These memories maintain a distinct address space that are not accessible from other threads.
3. Can conventional, general purpose synchronization be used for embedded systems as well? Hint: Embedded systems, especially heterogeneous ones, are asymmetric multiprocessor (AMP)-based architectures; processors are loosely coupled, with each processor having its own OS and memory. "
"A bootloader resides in protected program memory on a given microcontroller. It is usually the first software to run after power up or reset and is highly processor- and board-specific. The bootloader could be considered a “dumb” piece of code in that it doesn’t understand what application needs to be performed or even what the device function is. Rather, it is specially designed to understand communication from the outside world via any number of communication protocols (UART, I2C, SPI, CAN, Ethernet) and to understand the memory map of the microcontroller. When the bootloader does its job, it communicates with the outside world, or host, reads the data file sent by the host, and updates the Microprocessor in which it resides to run the new application code provided. "
Here is a one good reason to dust-off that old Ethernet switch from the 90's .
It is an elegant solution to building the 7 node Desk Cluster out of Raspberry Pi computers and a bunch of assorted hardware you might just happen to have at home. Talk about progress!
Any doubts ARM based servers? Then let's quote:
"The low power use of these things is incredible, as is the small size, the fact they are totally silent, and because they are so cheap, it is very viable to have one per task (or set of tasks).
Previously I ran a Sempron 3000+ laptop as my 'server' doing everything, and it had fan noise, and used more power than 10x Raspberry Pi's, and if I borked the system, it took down EVERYTHING. (It wasn't able to run virtualisation to suit my needs).
Love the Pi."
NXP's application note on porting new CMSIS-DAP to the the Cortex-M0 MCU's. Comes with complete source code for the LPC11Uxx family of MCUs.
"This application note illustrates how to port the CMSIS-DAP application to a Cortex-M0 platform and then to use the Cortex-M as a debugger.
CSP for the IoT world of Cortex-M everywhere!
"Measuring just 1.9 x 2.0 mm, the Kinetis KL02 MCU is 25 percent smaller than the industry’s next-smallest ARM® MCU. Within this miniscule device, Freescale has included the latest 32-bit ARM Cortex™-M0+ processor, cutting-edge low-power functionality and a range of analog and communication peripherals. This enables system designers to dramatically reduce the size of their boards and products while retaining the all-important performance, feature integration and power consumption characteristics of their end devices. In addition, space-constrained applications that previously couldn’t incorporate an MCU now can be upgraded to become smart applications, adding a new tier of devices to the IoT ecosystem."
Kinetis KL02 MCU features include:
"This article represents the results we obtained after implementing Xenomai RTDM kernel module. It also compares performance of the kernel-based solution with our previous user-space based approach. "
"Solution - Xenomai RTDM kernel module
It is well known, that moving into the kernel space could provide much better timing. We were trying to avoid this step as long as possible (because it is easier to develop and debug in the user space), but based on the results mentioned above it looks like we can not improve timing any more from the user space. So we decide to write kernel module. Xenomai offers convenient API to write real-time kernel space drivers which is called RTDM - Real-Time Driver Model (please see introduction paper and API documentation for more details)."
"For years, IEEE-1394 (FireWire) has been a successful and popular consumer electronics and computer interface. While that is true, the strongest design activity recently has been in other sectors. Over the past 17 years IEEE-1394 has been gaining traction as an aerospace and defense (A&D) high-speed interface and is used in programs such as the F-35 Lightning II, NPOESS, X47B, JSOW, and X2000, plus many others. "
"OK, I'm no Grampa, but I do relish old display technology. Everything today is LED, LCD, LCD, LED, or LCD. Boring. Let's have a look at displays from a more interesting time.
There's no denying Nixie's coolness factor. Let's start there, as most of you have probably seen them somewhere. Each digit in a Nixie display is a thin-formed wire electrode. The tube is filled with neon, and works on the same principle as a simple neon lamp. There's something hypnotic about watching a changing Nixie, as the display plane is different for each digit."