We are trying to utilize the Uart as per the new requirements, but lin driver supports only the master mode in the configuration, my doubt is how to use the autosar lin driver for uart purposes, is it possible?
The AUTOSAR MCAL does not support UARTs, except hidden behind LIN and so on.
Some MCU vendors offer Complex Device Drivers, which make the functionality available in AUTOSAR projects.
In worst case, you have to implement one yourself.
Related
Suppose I have a chip that has multiple options for interfacing with it, for example, the chip may have an I2C interface and a SPI interface and I can choose one of these interfaces and wire the device accordingly. How would I write a linux device driver for such device?
A chip with this behavior is ssd1307, which already has a driver implementation in the mainline linux kernel (https://github.com/torvalds/linux/blob/master/drivers/video/fbdev/ssd1307fb.c), implemented only for its I2C interface (the chip also has a 3/4 Wire SPI Interface). As you can see in the code, the probe function relies heavily on the fact that it is an I2C interface, so in order to use the SPI interface I would need to write an entirely new driver, repeating a lot of common code, or insert a lot of #ifdefs, which don't seem to be good approaches to me.
For chips providing several interface types, standard practice is to provide core driver and interface-specific frontends for it.
Several examples could be found e.g. in sound/soc/codecs/: pcm179x.c / pcm179x-i2c.c / pcm179x-spi.c and others.
This is not (yet?) done for ssd1307.
I can't find a proper answer on the Internet.
The Bluetooth Basic Rate / Enhanced Data Rate (BR/EDR) appeared with the 2.0 Bluetooth Core Specification to improve data rate transfers. The Bluetooth Low Energy (BLE) appeared with the 4.0 Bluetooth Core Specification to improve consumption in the IoT field. Yet, to make those two modes work together (BLE & BR/EDR) you had to use a "Smart Ready" module (or dual-mode specific module).
Today, we have the Bluetooth 5. I don't quite understand if, when I browse Bluetooth 5 SoC on the market, the BR/EDR is implemented natively. For the BLE mode, it is. From a general FAQ :
Is the low energy feature of Bluetooth a part of Bluetooth 5.0?
Yes, Bluetooth with low energy functionality, introduced in Bluetooth 4.0, is a feature within Bluetooth Core Specification version 5.0. In fact, the new features and benefits of Bluetooth 5.0 are designed specifically for Bluetooth with low energy functionality.
But for the BR/EDR mode, the Bluetooth 5 Core Specification states (p323, Vol : 2 Core System Package [BR/EDR Controller Volume]) :
Two modulation modes are defined. A mandatory mode, called Basic Rate, uses a shaped [...]. An optional mode, called Enhanced Data Rate, uses PSK modulation [...].
So, from the Core Specification, the EDR mode is optional. Yet, I can't find any SoC or module (BT5 compliant) that has this EDR mode, like it doesn't exist anymore but everyone exhibit high data transfers (more than EDR used to be with previous version).
So, is the EDR implemented natively in BT5 (as the BLE is) even if the Core Specification states it as optional ?
Where am I wrong ?
Thanks !
"Most" things in the Bluetooth Core specification are optional. You can have a BT5-compliant Bluetooth Classic chip that doesn't have any LE functionality and you can have a BT5-compliant BLE chip that doesn't have any Bluetooth classic features.
To check whether a particular Bluetooth chip supports a specific feature, just look it up at https://launchstudio.bluetooth.com/Listings/Search.
As mentioned above, lots of things Bluetooth are optional, and the nomenclature is confusing and changeable.
Bluetooth Smart Ready describes modules that can do both Smart (ie LE) as well as classic. If you are looking for a Bluetooth Smart Ready module, we've successfully used the Silicon Labs (acquired Bluegiga) BT121 module in a couple of products where we needed SPP with high speed and range (BR/EDR).
Hope that helps!
Best Regards, Dave
I been reading through the Bluetooth 4.0 core specification. However, I cannot find anywhere which states the true definition of 'dual-mode'.
From other google results, it looks like 'dual-mode' means that a BT device that has this capability can communicate with a LE device and a BR/EDR device simultaneously. However, I cannot find any official bluetooth docs that states this feature.
The closest one that I can get is:
The Brand book uses the term “dual mode” device to refer to a design
(host and/or controller) that is qualified in compliance with the
Basic Rate and Low Energy Combined Core Configuration as defined in
the Bluetooth specification. It is also referred to in the Bluetooth
specification as a BR/EDR/LE design.
from here
Could someone point out the location where 'dual-mode' is defined?
There is some different logic.
The two most prevalent implementations of the specification are
Bluetooth Basic Rate/Enhanced Data Rate (BR/EDR), which was adopted as
version 2.0/2.1, and Bluetooth with low energy (LE), which was adopted
as version 4.0/4.1/4.2. Each implementation has different use cases
and each implementation uses a different chipset to meet essential
hardware requirements. Dual-mode chipsets are also available for
applications that include both use cases. https://www.bluetooth.com/specifications/bluetooth-core-specification
There is Bluetooth 2.x - BR/EDR spec and there is Bluetooth 4.x (now 5.0). They are individuals specification with different purposes and different tech implementation (different modulation, different DSP blocks, different modes of work, etc). Manufacturer like TI, STM and so on just implement both of theese specs on one chip (System on Chip) or in SiP (System in Package). And theese SoC and SiP named "dual-mode devices" and often BT 2.0 and BT 4.x work in theese SoCs (SiPs) simultaneously.
How is bluetooth low energy implemented at a device driver level in linux?
Is there a new bluetooth stack code for every new bluetooth version ?
Bluez is the stack for Linux Bluetooth. New version of Bluetooth have resulted in changes in the code, but it's not a complete rewrite or anything drastic like that. Newer versions of Bluetooth are typically extensions of the existing protocol with the exception of Low Energy. Low Energy is completely supported at the kernel level in Linux, but there aren't a lot of convenience libraries for higher level interaction with LE.
Due to the incompleteness of Bluez with LE I've had to interact with the kernel code directly in order to implement functionality with LE. Also, I had to use older kernels that aren't supported by Bluez 5.x and had to use Bluez 4.x.
Already Tim and jhonnash have provided comprehensive information to your question. However, I would like to add one more information from Android Mobile point of view.
New version of Android uses Bluedroid as Bluetooth stack. This is quite different from Bluez.
Bluez has functionality distributed both in user space and kernel space. All the protocols like RFCOMM, HCI and L2CAP are implemented at kernel level and Profiles are implemented at User space. As Tim mentioned, to support Low energy, Bluez has to provide support at kernel level as well as at user space. This some times get difficult to track and understand. Any new changes may require modification in kernel as well as in user space code.
On the other hand, Bluedroid has some advantage over Bluez. Bluedroid has implemented its complete functionality at user space. Due to which any new functionality only needs to be added at user level code. No dependency on Kernel code.
Also, to answer your question of "Is there a new bluetooth stack code for every new bluetooth version ?" No complete rewrite is required for new version of Bluetooth as Bluetooth new versions are backward compatible, so only those portion of codes are added to the already existing stack which is new.
Regards
As your question is not completly clear that's why I also try to give all the possible protocols available to access bluetooth low enery stack for linux.
In UHID Driver "HoG (HID over GATT/Bluetooth-Low-Energy): GATT is a Bluetooth protocol implemented in user-space. When user-space opens an LE (low-energy) connection to a Bluetooth device, the device can advertise HID capabilities via GATT."
As GATT service is properly defined in this link.
There can be other protocols than GATT to access the Low-energy devices. HID Over GATT implementation is done in this manner.
In Linux, HAL provides hardware abstraction and device driver too provide hardware abstraction. Can you please clarify me the difference between two ?
The device driver communicates with a specific device at a specific buffer and control flag block location. A hardware abstraction layer abstracts away the details of how specific devices work. For example, the driver for a USB mouse is very different from the driver for a PS2 mouse but at the HAL layer they are both mice and can be treated interchangeably.
I would say that HAL provides hardware abstraction using device drivers. From a certain point of view, no device can work without a driver. HAL goes one step ahead, offering a uniform (or, "easier") API for the application.
You can bypass HAL and talk directly to the device driver, but you can not bypass the device driver and talk directly to the hardware (this last sentence is more or less valid in general, depending on OS and environment).
The main difference is what they provide abstraction for. HAL abstracts processors, device drivers abstract different devices. So in a sense HAL is the "device" driver of the processor or the motherboard in PCs.
Back in the day, every programmer who coded an app also codes drivers for the various hardware that they wanted to support. So, if you have an idea to develop an app which needs to use network capabilities, you also needed to know how to program hardware drivers for the network card. Then came in the HAL.
So instead of having your software and OS directly reaching out to the hardware, there is now a layer in between called the HAL. The HAL lies underneath the operating system layer or within.
Now nobody is allowed to access the hardware, except that they do it through and by the hardware abstraction layer(HAL). Just the HAL is allowed to access the hardware.
Now it's something which is standard. All Devs have to do is make the game/app work with the HAL.
Now we have the drivers. The drivers tell the HAL how to access the actual hardware.
So whoever makes the sound card, they just make a driver that tells the HAL how to access that sound card.
So overall, our software interacts with the HAL, The HAL uses drivers to interact with the hardware. We are telling the HAL how to access that sound card or network card etc. with the use of the drivers.