Before testing any device, I always do a in depth review of the documentation so that I can identify the features that will need to be tested, verified or demonstrated. So I started with the Kinetis L Series Product Brief.
Features common to all Kinetis L series families include:
• 48 MHz ARM Cortex-M0+ core
• High-speed 12/16-bit analog-to-digital converters
• 12-bit digital-to-analog converters for all series except for KLx4 family
• High-speed analog comparator
• Low-power touch sensing with wake-up on touch from reduced power states for all series except for KLx4 family
• Powerful timers for a broad range of applications including motor control
• Low power focused serial communication interfaces such as low power UART, SPI, I2C etc.
• Single power supply: 1.71V - 3.6V with multiple low power modes support single operation temperature: -40 ~ 105 °C (exclude CSP package)
To support the family of devices, they set up a core architecture with the following features;
Core and Architecture:
• ARM Cortex-M0+ Core delivering 1.77 CoreMark/MHz from single-cycle access memories.
The 32-bit processing core can load up more than one instruction per cycle and begin processing each instruction in parallel. Depending upon your code, you can get a lot of processing done using this structure. However, if you have a lot of branches, then you might find your processing actually slow down as the CPU must flush to pipes before beginning the new instructions
• Single-cycle access to I/O and critical peripherals: Up to 50 percent faster than standard I/O, improves reaction time to external events allowing bit banging and software protocol emulation.
This statement indicates that they have built in bit specific instructions into the CPU. The result should be a very fast pin control execution. So if you are using a lot of the single I/O pins to trigger external hardware, you should get a very fast turn around from sending a state change to the CPU and have it respond very quickly with single pin commands.
• Two-stage pipeline: Reduced number of cycles per instruction (CPI), enabling faster branch instruction and ISR entry.
The two pipeline structure lets the CPU to rapidly process simple instructions off a single memory access. It also lets the CPU load up the entry point for an Interrupt service routine (ISR) to respond to external events, while the CPU finishes the current instruction. A good approach to improve interrupt responses.
• Excellent code density vs. 8-bit and 16-bit MCUs - reduces flash size, system cost and power consumption.
This statement is a little nebulous. Depending upon your instructions and compiler optimization, the 32 bit structure should be more efficient. However, you might find it to be an impediment if your code does a lot of bouncing around. If you really need 32 bit data, then you will find this feature very useful, but if most of your data is 8 or 16 bit, then you might not see as much of a timing improvement. Still, a good feature in most cases.
• Optimized access to program memory: Accesses on alternate cycles reduces power consumption.
Another benefit to the pipeline structure. If you have a lot of sequential code you can get a very efficient code execution.
• 100 percent compatible with ARM Cortex-M0 and a subset ARM Cortex-M3/M4: Reuse existing compilers and debug tools.
They basically have not changed the Cortex processor, so you have everything you had before, so you can port your old code into this device with a minimum of problems. However, you might want to redesign some of your code to take advantage of the new features they have built around the Cortex core.
• Simplified architecture: 56 instructions and 17 registers enables easy programming and efficient packaging of 8/16/32-bit data in memory.
Nearly all embedded devices are reduced instruction set computers (RISC), which is why they are used in a lot of simple tasks where you do not need a more robust general-purpose processor (GPU) like the Intel 8086 variants. The 17 registers may or may not be of use for your application. If used correctly, you can setup some very efficient software for event driven applications. I will know more once I see what they are and what they can enhance.
• Linear 4 GB address space removes the need for paging/banking, reducing software complexity.
This feature could be really useful in data logging applications. If you need to gather a huge amount of data over a short time, then having a large memory space is ideal, especially with the four DMA controllers. You can pull data into and out of your device very quickly.
• ARM third-party ecosystem support: Software and tools to help minimize development time/cost.
They are basically saying that they have maintained backward compatibility with your existing ARM compilers and debuggers, very important if you have already invested in a good tool set.
• Micro Trace Buffer: Lightweight trace solution allows fast bug identification and correction.
Very useful feature if you need to find out why your code is bombing. The micro buffer can capture the last instructions for retrieval and evaluation, always a good feature.
• BME: Bit manipulation engine reduces code size and cycles for bit oriented operations to peripheral registers eliminating traditional methods where the core would need to perform read-modify-write instructions.
This feature wets my appetite. Having a very efficient bit manipulation capability is essential to take full advantage of individual I/O pins. If you look at a lot of embedded applications, they use the full 8 or 16 bit instructions to set or clear a bit. If this feature lets you use one instruction to identify the pin and the state, then I can see a great boost in I/O action implementation for this device.
• Up to 4-channel DMA for peripheral and memory servicing with minimal CPU intervention.
DMA is very important if you need to read and send large chunks of data to support devices. DMA is a very efficient method to access the data without tying up the processor from doing other actions while the data transfers are occurring.
• Broad range of performance levels with CPU frequencies up to 48 MHz.
This feature gives you a choice when looking at timing verses power usage. Hopefully this means that you can adjust your CPU speed dynamically. This capability is essential when you have an application that spends a lot of time waiting for an event, but then needs to ramp up to full speed to process the event. Could be a neat feature depending upon how its implemented.
• Ultra low-power:
This is a very interesting statement. From looking at the architecture, I can see where they have potentially greatly improved the processor efficiency for doing normal embedded tasks. However, you usually have to give up something to buy power savings. Once I get a chance to see how they have implemented their power savings features, I can expand upon this feature, but for now, they have clearly adjusted the architecture to save power, I just need to see if they have created impediments to other features to make it happen.
• Next-generation 32-bit ARM Cortex M0+ core: 2x more CoreMark/mA than the closest 8/16-bit architecture Multiple flexible low-power modes, including new operation clocking option which reduces dynamic power by shutting off bus and system clocks for lowest power core processing.
This statement hints that they have provided the software with the ability to adjust the power consumption by using various operating modes. I can’t wait to see what they have done to achieve this feature.
Peripherals with an alternate asynchronous clock source can continue operation.
Another intriguing statement. I think they may enable various I/O actions to occur while the processor is in sleep or low power mode. Again, I need to see how they have implemented this feature before I can assess it benefits.
• UART, SPI, I2C, ADC, DAC, TPM, LPT and DMA support low-power mode operation without waking up the core
These features will most likely use the 17 registers they talked about earlier. Doing data transfers should be a normal way to do I/O. Once you set up the link, the processor should not need to be actively involved in the transfer.
• Memory:
The 32-bit memory structure provides a wide range of memory configurations. It is very easy to set up areas for transparent flash, ram, or any other memory type. With the independent I/O to memory feature, you should be able to allow the memory access speed issues be handled totally by the hardware. Again, I need to see the details before I can assess the benefits.
• Scalable memory footprints from 8 KB flash / 1 KB SRAM to 128 KB flash / 16 KB SRAM.
Again, a fallout from the 32-bit structure.
• Embedded 64 B cache memory for optimizing bus bandwidth and flash execution performance (feature not available on KL02 family).
The implementation of cache memory can be good or bad. In many cases your code will dictate the answer. If you do a lot of jumping around, then you lose the advantage of cache. If you use good modular coding techniques, then cache can indeed speed up your processing capability.
• Mixed-signal analog:
• Fast, high precision 16-, or 12-bit ADCs with optional differential pairs, 12-bit DACs, high speed comparator.
The ADC is 12 bit. They do some over-sampling to generate a 16-bit result. I suspect that you will just use the 12-bit resolution for most applications. The 12-bit DAC is optional, so if you need a high-resolution analog output, it would be useful. They have one comparator, which they drive with a 6-bit DAC. I suspect this would be adequate for most capacitive sensing applications I have seen, but we shall see once we can get into the details.
Powerful signal conditioning, conversion and analysis capability with reduced system cost.
This statement brings a smile to my face. We shall see if this claim is true once we see all of the pieces and their connectivity.
• Human Machine Interface (HMI):
The basic I/O pins give you access to buttons, variable voltages, and you have the standard serial outputs to drive LCD’s and UART terminals.
• Optional capacitive Touch Sensing Interface with full low-power support and minimal current adder when enabled.
Available on the KL05 series. Once we see the pin control provided, I will have more information on what the device supports.
• Connectivity and Communications:
• All UARTs support DMA transfers, and can trigger when data on bus is detected, UART0 supports 4x to 32x over sampling ratio. Asynchronous transmit and receive operation for operating in STOP/VLPS modes.
I like the implications of this feature. You can set up messages for automatic responses based upon simple pin triggers without bringing the processor out of low power modes. I can’t wait to see how they implement this feature.
• Up to two SPIs
I have not used an SPI before, so I may have to build up an application to test this capability.
• Up to two I2Cs
Same for the I2C. I know a lot of you have used this feature, so I may need to try some of the stock implementations just to verify some of the other features.
• Full-speed USB OTG controller with on-chip transceiver.
I am curious if they can support the full USB 2.0 range, though I have doubts about ever needing it in an embedded application.
• Reliability, Safety and Security:
I really like the security feature they have built into the device. An 80-bit unique processor ID makes it nearly impossible for someone to access the processor if you implement a code security sequence before you allow updates. If no one can find out your ID, then you can stop anyone from highjacking your hardware, very useful in sensitive applications.
• Internal watchdog
Standard feature to make sure your device is not lost in the ether. I recommend you use them if you have an application where the device is left unattended for a long period of time.
• Timing and Control:
Another feature I am interested in exploring in detail. If you learn to understand a systems timing requirements, you can greatly improve your overall performance and lower your power needs. Based upon what I have seen above, they have built in some very interesting timing features in this device.
• Powerful timer modules which support general purpose, PWM, and motor control functions.
Coupled with the independent I/O, you should be able to setup motor control without active processor involvement.
• Periodic Interrupt Timer for RTOS task scheduler time base or trigger source for ADC conversion and timer modules.
Again, coupled with independent I/O features, you should be able to perform a significant amount of automatic data collection.
• System:
• GPIO with pin interrupt functionality.
I really like the possibilities of this feature. When linked to external circuits, you have a tremendous capability to implement a wide range of functions that can occur without any processor involvement. A very neat idea.
• Wide operating voltage range from 1.71 V to 3.6 V with flash programmable down to 1.71 V with fully functional flash and analog peripherals.
I can see where a lot of applications would need this feature. I need to look into the details to see if the processor can adjust its timing based upon a fall in power, so you can get a graceful degradation during power interruption conditions, like; brownouts, clouds over your solar collectors, etc.
• Ambient operating temperature ranges from -40 °C to 105 °C.
Another exciting feature if you plan to do an outdoor application. Most devices cease operation at about 0 degrees C, so getting down to –40 means it can work even in our North American winter weather.
A lot of interesting issues to consider while I await the delivery of the board.
Until then,
DAB
