Problems compiling zephyr shield example - c

I have an STM32 lorawan discovery board with an attached x_nucleo_iks02a1 shield. I'm trying to run the microphone sample, and I get an error at line 52
const struct device *mic_dev = device_get_binding(DT_LABEL(DT_INST(0, st_mpxxdtyy)));
// identifier "DT_N_INST_0_st_mpxxdtyy_P_label" is undefined
I looked at the zephyr.dts file and noticed that there is no compat listed with the string st_mpxxdtyy so I suppose that is the reason for the failure. The board I am using is not a nucleo but does have the same arduino compatible headers. Do I need to port this shield to this board?

Copy the overlay file x_nucleo_iks02a1_mic.overlay from /zephyrproject/zephyr/boards/shields/x_nucleo_iks02a1 to the root of your projectfolder.
Now you should be able to retrieve the device structure with:
const struct device *mic_dev = device_get_binding("MP34DT05");

Related

U-Boot add node to devicetree during startup

I work on a custom board with a Cyclone V SoC.
I need to add some informations to U-Boot device tree at startup and these informations are stored in an I2C device.
It appears that U-Boot device tree is read-only during its execution but before relocation. The function board_fix_fdt (void *rw_fdt_blob) can be used to make changes on the device tree before relocation.
The problem I have is that I cannot access the I2C device at this time. The driver doesn't seem to be loaded yet.
Can someone give me any hints on how I can enable the I2C at this stage ?
U-Boot version is 2018-05.
The solution is to add in u-boot device tree the i2c driver and also the reset driver for pre-relocation states :
&rst {
status = "okay";
u-boot,dm-pre-reloc; // HERE
};
&i2c2 {
status = "okay";
u-boot,dm-pre-reloc; // and HERE
}

I've added a MAX7320 i2c output chip. How can I get the kernel to load the driver for it?

I've added a MAX7320 i2c expander chip to i2c bus 0 on my ARM Linux board.
The chip works correctly from userspace with commands such as /usr/sbin/i2cset -y 0 0x5d 0x02 and /usr/sbin/i2cget -y 0 0x5d.
There is a drivers/gpio/gpio-max732x.c file in the kernel source, which is compiled into the kernel that I'm running. (I've built it from source.)
How do I tell the kernel that it should instantiate the gpio-max732x driver on "i2c bus 0, chip id 0x5d"?
Do I need to modify the device tree .dts file and put a new .dtb file in /boot/dtbs/?
What would the clause for instantiating a gpio-max732x module look like?
P.S. I've seen https://lkml.org/lkml/2015/1/13/305 but I can't figure out how to get the patch files.
Device Tree
There must be appropriate Device Tree definition for your chip, in order for driver to instantiate. There are 2 ways to do so:
Modify .dts Device Tree file for your board (look in arch/arm/boot/dts/), then recompile it and re-flash it to your device.
This way is preferred in case when you have access you kernel sources for your board and you are able to re-flash .dtb file to your device.
Create Device Tree Overlay file, compile it and load it on your device.
This way is preferred when you don't have access to kernel sources for your board, or you are unable to flash new device tree blob to your device.
Your device definition in Device Tree should look like (according to Documentation/devicetree/bindings/gpio/gpio-max732x.txt):
&i2c0 {
expander: max7320#5d {
compatible = "maxim,max7320";
reg = <0x5d>;
gpio-controller;
#gpio-cells = <2>;
};
};
Kernel configuration
As your expander chip (MAX7320) has no input GPIOs, you don't need IRQ support for MAX732x. So you can disable CONFIG_GPIO_MAX732X_IRQ in your kernel configuration.
Matching device with driver
Once you have your Device Tree loaded (with definition for MAX7320), MAX732x driver will be matched with device definition, and instantiated. Below is explained how matching happens.
In Device Tree file you have compatible property:
compatible = "maxim,max7320";
In MAX732x driver you can see this table:
static const struct of_device_id max732x_of_table[] = {
...
{ .compatible = "maxim,max7320" },
...
When driver is being loaded, and when Device Tree blob is being loaded, kernel tries to find the match for each driver and Device Tree definition. Just by comparing strings above. If strings are matched -- kernel instantiates driver, passing corresponding device parameters to it. Look at i2c_device_match() function for details.
Obtaining patches
The best way is to use kernel sources that already have Device Tree support of MAX732x (v4.0+). But if it's not the case, then...
You can cherry-pick patches from upstream kernel to your kernel:
$ git remote add upstream git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ git fetch --all
$ git cherry-pick 43c4bcf9425e
$ git cherry-pick 479f8a5744d8
$ git cherry-pick 09afa276d52e
$ git cherry-pick 996bd13f28e6
And if you still want to apply patches manually (worst option, actually), here you can find direct links to patches. Click (patch) link to get a raw patch.
Also check later patches for gpio-max732x.c here.
Hardware concerns
To be sure that your chip has 0x5d I2C address, check that configuration pins are tied to next lines (as per datasheet):
Pin Line
-----------
AD2 V+
AD0 V+

Char Device Driver with Port Expansion using MCP23017

I am new to Linux Kernel Development and I want to implement a Char device driver which handles Port expansion using a MCP23017 with a RaspberryPi (Raspbian Wheezy) using C.
A control for port expansion (MCP23017) is required. A less of a driver in the true sense, but more with porting functions in a driver.
 
The module is addressed via I2C. I need to implement the following functions in the driver:
· Configuration of the I2C address
· Configuration of the IOs
· Configuration of Pull-Ups
· Configuration of interrupts
· Read / write the IOs
It is important that up to 8 modules can be opened/operated simultaneously (8 is the max. possible number of addresses of the block).
I have seen a number of examples in the internet and implemented a simple char device driver with init, open, read and write functions and also tested I2C operations for MCP23017. I have got a brief idea about a device driver but don't know how to further implement the functions.
I would like to know/clarified about the following:
How does the dev_open work? How can I try to open a device through a linux command and check if the device is opened/ the number of times the device is opened through dmesg command?
I want 8 different modules to be opened simultaneously using the device driver and the Configuration of the MCP23017 IOs, Pullups and Interrupts. How is it done?
Errors:
/home/pi/i2c_gpio/mcp23017.c: In function ‘mcp23s08_direction_input’:
/home/pi/i2c_gpio/mcp23017.c:269:9: error: implicit declaration of function
‘gpiochip_get_data’ [-Werror=implicit-function-declaration]
struct mcp23s08 *mcp = gpiochip_get_data(chip);
/home/pi/i2c_gpio/mcp23017.c: In function ‘mcp23s08_probe_one’:
/home/pi/i2c_gpio/mcp23017.c:615:11: error: ‘struct gpio_chip’ has no
member named ‘parent’
mcp->chip.parent = dev;
/home/pi/i2c_gpio/mcp23017.c:681:2: error: implicit declaration of
function ‘gpiochip_add_data’ [-Werror=implicit-function-declaration]
status = gpiochip_add_data(&mcp->chip, mcp);
^

Generation of RTE_Components.h

I'm working with MDK-Pro and the File System library.
In my application, I require an SPI interface to the SD card. I've managed to setup the project properly, except that in the RTE_Components.h file that Keil generates the line #define RTE_Drivers_MCI0 which subsequently triggers a preprocessor error ("SDIO not configured in RTE_Device.h").
Although I can manually comment out this line in RTE_Components.h, every so often Keil updates this file and I get the above problem. Does anyone know what exactly generates this file, and how I can stop it from adding the SDIO-related definitions into the project?
The RTE_Components.h is not supposed to be modified and will always be automatically generated. That the stack tries to connect via MCI interface is related to your configuration made in the "FS_Config_MC_0.h".
// <o>Connect to hardware via Driver_MCI# <0-255>
// <i>Select driver control block for hardware interface
#define MC0_MCI_DRIVER 0
// <o>Connect to hardware via Driver_SPI# <0-255>
// <i>Select driver control block for hardware interface when in SPI mode
#define MC0_SPI_DRIVER 0
// <o>Memory Card Interface Mode <0=>Native <1=>SPI
// <i>Native uses a SD Bus with up to 8 data lines, CLK, and CMD
// <i>SPI uses 2 data lines (MOSI and MISO), SCLK and CS
// <i>When using SPI both Driver_SPI# and Driver_MCI# must be specified
// <i>since the MCI driver provides the control interface lines.
#define MC0_SPI 1

need AT-Command to copy files from sd-card

i have usb-modem that i can comunicate with it using AT-Command.
i can send and recive sms using it.
we know that we can insert an SD-Card into the usb-modem and use it as a storage device
but i been stuck for days searching how i can work on files on sd card using AT-Command??
please help. thanks in advance
I don't think you can do this. The AT command-set is only for doing "phonestuff". Calling, texting (which in itself is an extension), and such.
The usual reason for usb-modems to have built-in storage is so you can store the drivers there. This would let you use the modem on any computer without needing to connect to the internet to get the drivers.
Are you sure the modem doesn't expose the card as a drive as other USB devices do (e.g cameras, phones, etceteras)? I can't see a way of retrieving files off it using ATxx commands.
Edit, I did a little digging and found this:
https://wiki.archlinux.org/index.php/Huawei_E1550_3G_modem#AT_commands
And I am wondering if any of the following can point you in the right direction:
AT^U2DIAG=0 - the device is only Modem
AT^U2DIAG=1 - device is in modem mode + CD ROM
AT^U2DIAG=255 - the device in modem mode + CD ROM + Card Reader
AT^U2DIAG=256 - the device in modem mode + Card Reader
AT+CPIN=<PIN-CODE> - enter PIN-code
AT+CUSD=1,<PDU-encoded-USSD-code>,15 - USSD request, result can be found (probably) in /dev/ttyUSB2.
So it would appear you can put the device in a card-reader mode using AT^U2DIAG=256. I'd be interested to see if, when you execute this, whether your drive will then be mapped. I can't really find anything to get files off it after you do this.

Resources