I have used TI TMS320 MCUs for years. TI provides header and source files for accessing hardware. TI Implements a hardware abstraction layer to do that as you probably know.
ARM micro-controllers come with CMSIS, an standard for hardware abstraction layer.
I want to know your opinion; which method do you prefer?
I am very convenient with th TIs one. This is simple and understandable.
regards,
Ras
CMSIS and manufacturer HAL are not exlusive. Usually you will use both. ARM supplies the CMSIS to set up the ARM core, such as the NVIC (Nested Vector Interrupt Controller). The microcontroller manufacturer supplies HAL for the additional peripherals (such as I2C, UART...).
Related
Is it possible to create one file, say for example uart.c to be generic, so that I can call the uart functions for different microcontrollers, say for example avr and arm? or is it a must that for every microcontroller I will have to create the the uart functions from scratch?
You can create a Hardware Abstraction Layer (HAL) that acts as a common interface for all hardware of the same kind. A correctly designed HAL allows portable application-layer code, which is the sole purpose of having one.
The HAL should be in the form of an API library that then acts as a header file template for how the drivers should be designed, the simplest form of "polymorphism". The application programmer calls the HAL, and the MCU-specific functions in the driver will then get called.
In case of UART you might have an init function taking baudrate, stop bit, parity, handshaking etc as parameters. And then a read function and a write function, with some error handling. Overrun and framing errors are universal, for example. It is then up to the specific driver for MCU "x" to implement itself according to your specified HAL.
Generally, one should not create abstaction layers needlessly though. It is quite qualified work and easy to get wrong. If you don't need portability or code re-use between projects, there's no obvious need for a HAL and you could as well call the driver directly from the application code.
The hardware implementations and register interfaces across different vendors certainly differ. ARM do not make MCUs they licence the core - the peripherals are not defined by the core so even amongst ARM devices the peripheral implementations differ between vendors.
What you can do is define a common device-layer interface and implement that interface for each device family you need, then you can reuse the application layer code across architectures.
The alternative is to stick with a common family. AVR for example covers a wide range of devices and the peripherals generally are common across the range. Similarly STM32 (ARM Cortex-M) devices share common peripherals across the range.
So the answer is no, but you can deal with that by abstracting the hardware (or the vendor supplied abstraction or device layer).
For a UART you might use stdio as your abstraction layer and access the device via fprintf, fputchar, fread, fwrite etc. Though typically you'd build that on a lower level layer too.
As I understand, a BSP (Board Support Package) contains bootloader, kernel and device driver which help OS to work on HW. But I'm confused because OS also contains a kernel. So what is the difference between the kernel in OS and the kernel in BSP?
What a BSP comprises of depends on context; generically it is code or libraries to support a specific board design. That may be provided as generic code from the board supplier for use in a bare-metal system or for integrating with an OS, or it may be specific to a particular OS, or it may even include an OS. In any case it provides board specific support for higher-level software.
A kernel is board agnostic (though often processor architecture specific), and makes no direct access to hardware not intrinsic to the processor architecture on which it runs. Typically an OS or application will require a Hardware Abstraction Layer (HAL); the HAL may well be built using the BSP, or the BSP may in fact be the HAL. A vendor may even package a HAL and OS and refer to that as a BSP.
The term means what it means to whoever is using it - context is everything. For example in VxWorks, WindRiver use the term BSP to refer to the layer that supports the execution of a VxWorks based application on a specific hardware design. A board vendor on the other hand may provide a complete Linux distribution ported to the board and refer to that as a BSP.
However and to what extent a particular vendor or developer chooses to support a board is a board support package regardless of how much or how little it may contain.
BSP definition is broad. It is a supporting software package for a specific board. BSP for a tiny microcontroller probably just contains HW drivers for its peripherals. On the other hand, for an embedded CPU it may contain HW drivers, bootloader and OS kernel and what not.
So the kernel in a BSP (board support package) is just a specific version of an OS kernel that has been ported to your board.
Im probably just saying the same things already said.
You have a chip and/or board product you want to sell to other (software) developers. A reference design (board) with the chip(s) in question are used. The BSP is a vague term to mean the software that is provided to you as a software developer to ideally make your life easier in using that product (chip and/or board) and adding your software to it or developing for it. So if it is a linux or rtos or other operating system capable platform and the vendor (providing the bsp) believes that users want an operating system and a specific operating system, then instead of you having to port the os to that target, they do it for you. If something like linux that is open source, then you either are told which linux sources to download then the patches made by the bsp are added and/or the bsp contains the complete sources for the whole thing already patched. Drivers, applications as deemed necessary by the vendor etc. Multiple operating systems may be supported if the vendor feels that is needed in order to attract customers to buy that board/chip product.
The whole package of software that you get from them to make that chip/board into your own product, is the BSP.
vxWorks kernel which you can run on a Board contains vxWorks core kernel and "other components" which may change from one environment.
Core kernel contains essential programs such as Scheduler, Memory manager, Basic File systems, security features etc.
These "other components" which are part of BSP may be optional or may vary from system to system, and helps the core kernel features.
In simple words, the image dislays the defination of BSP. Please correct me if I'm wrong
I would say for a well structured code base, the application layer should be abstracted from lower layers by the HAL layer. This would allow the app layer to be portable if we want to migrate the system to a new board. If you see you have board/CPU specific logic in your app layer, you know you have broken the portability.
The HAL layer functions' bodies should contain board specific code, here is where the BSP layer code comes into play. When we want to port the system to a new board, code changes should happens in the HAL functions' bodies, while the HAL functions' declaration should not change, which leads to the app layer remains the same.
Can anyone please explain the major differences between a Soc and SBC?
SBC is a PCB, SoC a chip.
SBC may contain a SoC (a chip) in addition to other components and connectors to build a stand-alone system. SoC in itself is rarely standalone but needs at least a few extra components and at least some connectors for power and interfacing.
A bit like car(SBC) and engine(SoC). A standalone engine is not functional but needs to be placed in a car.
SOC = System on a Chip
SBC = Single Board Computer
A SOC has multiple functional units on one piece of silicon. Often multiple processors and peripherals.
A SBC is a complete PC on a single PCB. CPU, RAM, non-volatile memory(HDD or flash)...
System on Chip (SoC) and Single Board Computer (SBC) are totally different to each other. Usually SOC is an important constituent of the SBC.
System-on-a-chip (SoC) is an Integrated Circuit which houses all the critical elements of the electronic system on a single microchip. A SoC can usually have the on-chip memory, microprocessor, peripheral interfaces, , I/O logic control, etc. that are usually found inside a computer system. It is widely used across the embedded industry due to their small-form-factor, computational excellence and low power consumption.
SBCs are off-the-shelf products that can be used to develop end-products or applications for a variety of industries. SBCs come along with integrated software and hardware, which includes System on Chips, memory, power requirements, real world multimedia and connectivity interfaces such as USB, UART, CAN, HDMI, Ethernet, SDIO, MMC, Analog Audio, display etc.
in my project I need to work with device drivers, but have a hard time to understand the naming, scope and function of the abstraction layers. As I see the main layer is HAL - "hardware abstraction layer".
What are the clients of HAL, whom is HAL interfacing?
Are you talking about a specific HAL in windows or linux or something or in general?
When accessing registers from a device driver (code that drives a device, doesnt have to be a kernel thing or have an operating system at all) for example I generally recommend to create functions like PUT32(address,data), data=GET32(address). Or writel and readl, whatever you fancy. The point being to avoid creating a pointer with the address and using that pointer directly. There is a performance gain to the pointer type solution, and performance hit to the abstract PUT32(). Why I use it though is because if the code is clean enough that driver can be used as part of a kernel driver for this os, a kernel driver for that os, run standalone embedded, connect to an hdl simulation of the logic, run on a processor on the same chip, or run on a host computer that reaches into the chip via PCI or jtag, etc. One chunk of code reused from the birth of the logic (hdl sim) to the end user kernel driver.
Perhaps more to your question though think about a uart, you want to send some bytes and receive some bytes right? Create a uart_send() function and a uart_recv() function, everything above the abstraction layer uses these two functions, when you target this code to a specific platform then you implement those functions for the specific uart in that specific hardware. later on you can replace that uart with something else, so long as the new uart can send and receive the code above the abstraction layer does not have to change. Even though you have created an abstraction layer with the functions above, I personally would still use PUT8() and GET8() functions in the implementation of uart_send() and uart_recv() for the specific uart, and in a separate file implement PUT8() and GET8().
How many layers of abstraction between the driver and the actual hardware, how and where are often specific to the task and the hardware.
In computers, a hardware abstraction layer (HAL) is a layer of programming that allows a computer operating system to interact with a hardware device at a general or abstract level rather than at a detailed hardware level. Windows 2000 is one of several operating systems that include a hardware abstraction layer. The hardware abstraction layer can be called from either the operating system's kernel or from a device driver. In either case, the calling program can interact with the device in a more general way than it would otherwise.
I know little about MCUs and embedded systems.
A year ago we made contract with a company to design a special purpuse MP4 device based on the SigmaTel STMP 3650 kit. Now we have all the source code for the firmware (code, resource around 1G).
My questions are
Can we use this code to run on other STMP 3xxx famliy based devices (with acceptable modification, of course)? What about other ARM9 based devices?
ARM9 defines the processor core (but even then there are variants; yours being ARM962EJ-S), but most on-chip peripherals and support hardware including clocks, PLLs, and interrupt controller are vendor specific, you you would have to port your hardware initialisation and device driver code, and make sure that you choose a device with a comparable peripherals set to the ones your current code uses.
Moreover if the code is written in C or C++ rather than assembler, much of it may be prtable to other architectures, particularly if the application layer and hardware abstraction layer are well defined.
Another issue may be whether your existing implementation relies on any particular OS or RTOS; you may need to select a device that supports the same OS in order to reduce the porting effort.
Finally, a non-programming point, but just to keep you out of trouble; you need to be sure that you own the rights to the code you intend to reuse, and that the original client has no claim on it.
your logical successor chip is iMX233 from Freescale for a couple of reasons.
STMP3650 lead to STMP3780 by SigmaTel - same CPU core (ARM9EJ-S), mostly same architecture and registers. Then, SigmaTel was sold to Freescale and they simply copied STMP3780 to ...iMX233. Identical silicon.
We have a fully fledged MP3/MP4 player based on STMP3650 (see bones.ch website) and transfer our R&D now to iMX233. What is your project doing by now? How "good" was the design based on STMP3650 running? Do you have any chip stock left?