The CM108 from C-Media has 4 GPIO pin that you can access via a hid interface.
Using the generic write function in Windows I was able to write to the gpio pins.
However I'm trying to do the same thing in Linux without success.
The linux kernel detect the device as a hidraw device.
Note: I was able to read from the device, just not write. (I've run the app as root just to make sure it wasn't a permission issue).
I got this working, here's how.
I needed to create a new linux hid kernel mod. (it wasn't that hard)/*
/*
* Driver for the C-Media 108 chips
*
* Copyright (C) 2009 Steve Beaulac <steve#sagacity.ca>
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation, version 2.
*/
/*
* This driver is based on the cm109.c driver
*/
#include <linux/device.h>
#include <linux/hid.h>
#include <linux/module.h>
#define DRIVER_VERSION "20090526"
#define DRIVER_AUTHOR "Steve Beaulac"
#define DRIVER_DESC "C-Media 108 chip"
#define CM108_VENDOR_ID 0x0d8c
#define CM108_PRODUCT_ID 0x000c
#ifdef CONFIG_USB_DYNAMIC_MINORS
#define CM108_MINOR_BASE 0
#else
#define CM108_MINOR_BASE 96
#endif
/*
* Linux interface and usb initialisation
*/
static int cm108_hid_probe(struct hid_device *hdev, const struct hid_device_id *id)
{
int ret;
ret = hid_parse(hdev);
if (ret) {
dev_err(&hdev->dev, "parse failed\n");
goto error;
}
ret = hid_hw_start(hdev, HID_CONNECT_HIDRAW);
if (ret) {
dev_err(&hdev->dev, "hw start failed\n");
goto error;
}
return 0;
error:
return ret;
}
static struct hid_device_id cm108_device_table[] = {
{ HID_USB_DEVICE (CM108_VENDOR_ID, CM108_PRODUCT_ID) },
/* you can add more devices here with product ID 0x0008 - 0x000f */
{ }
};
MODULE_DEVICE_TABLE (hid, cm108_device_table);
static struct hid_driver hid_cm108_driver = {
.name = "cm108",
.id_table = cm108_device_table,
.probe = cm108_hid_probe,
};
static int hid_cm108_init(void)
{
return hid_register_driver(&hid_cm108_driver);
}
static void hid_cm108_exit(void)
{
hid_unregister_driver(&hid_cm108_driver);
}
module_init(hid_cm108_init);
module_exit(hid_cm108_exit);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL");
used This makefile
obj-m += cm108.o
and compile the module
make -C /lib/modules/`uname -r`/build/ M=`pwd` EXTRAVERSION="-generic" modules
sudo make -C /lib/modules/`uname -r`/build/ M=`pwd` EXTRAVERSION="-generic" modules_install
depmod -a
I had to modify the modules.order file so that my module would get queried before the generic hid linux module.
This modules make sure that the hidraw uses Interface 2.
Then I can use fopen to read and write to the GPIO pin of the CM108 chip.
BTW: when writing you need to write 5byte the 1st byte is used for the HID_OUTPUT_REPORT
Most hardware in Linux is accessible as a file. If the driver created a hardware node for it on the file-system, you're in luck. You will be able to write to it using regular file routines. Otherwise, you may need to do some assembly magic, which may require you to write a kernel module to do it.
Here is a complete example of how to write to the CM108/CM119 GPIO pins on Linux.
https://github.com/wb2osz/direwolf/blob/dev/cm108.c
You don't need to run as root or write your own device driver.
I have the opposite problem. I'm trying to figure out how to do the same thing on Windows.
Related
My goal is to write a simple .dts file (to be compiled to .dtbo using DT 1.4.4) to configure a GPIO output on boot on a Beaglebone Black Rev C running Debian 10.3
I intend to place the .dtbo in /lib/firmware and then specify it in /boot/uEnv.txt
I understand some parts of the .dts file and have tried decompiling exisiting .dtbo files in /lib/firmware/ for guidance but none of them are a simple GPIO output example. A lot of online resources involve make and make install but I believe DT should be able to handle it by now right?
I was able to get the following to compile but with issue:
/* dtc -O dtb -o BB-P8_13-LED.dtbo -b 0 -# BB-P8_13-LED-00A0.dts */
/dts-v1/;
/plugin/;
/ {
compatible = "ti,beaglebone-black";
/* identification */
part-number = "BB-P8_13-LED";
version = "00A0";
/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
"P8.13", /* GPIO_23 */
/* the hardware ip uses */
"gpio23";
fragment#0 {
target = <&am33xx_pinmux>;
__overlay__ {
bb_gpio23_pin: pinmux_bb_gpio23_pin {
pinctrl-single,pins = < 0x024 0x07 >; /*P8_13 GPIO23 MODE7*/
};
};
};
fragment#1 {
target = <&gpio23>;
__overlay__ {
leds {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&bb_gpio23_pin>;
compatible = "gpio-leds";
P8_13 {
label = "P8_13";
default-state = "on";
};
};
};
};
};
Q: Why does loading this .dtbo in /boot/uEnv.txt cause all other GPIOs to disappear from /sys/class/gpio/? I thought fragment0 was for excluding a single gpio, not all of them.
###Additional custom capes
uboot_overlay_addr4=/lib/firmware/BB-P8_13-LED-00A0.dtbo
Q: Where are the files for controlling the GPIO (for testing) or rather what can I add to my .dts file so the gpio23 still appears in /sys/class/gpio or even /sys/class/leds? Ultimately I want to be able to control this GPIO with Node-RED.
Q: Do I need to be consistent with my use of P8.13 vs. P8_13? I think I'm mixing up terminology used in .dts files that get compiled with make vs DT.
Q: I think my fragment#1 P8_13 child node is missing something to specify the gpio bank and active high/low setting. Something like "gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;" Where can I look to research which bank GPIO23 is in? What does the '19' mean in that statement?
So Dr. Derek Molly did a really nice job of laying this out and I was able to use the example in his repo. Here is a page he made for explaining how to configure GPIO at boot using Device Tree Overlays:
http://derekmolloy.ie/beaglebone/beaglebone-gpio-programming-on-arm-embedded-linux/
Even though his solution is for kernel 3.8 I was able to get the following to compile on 4.19
/* dtc -O dtb -o BB-P8_13-LED-00A0.dtbo -b 0 -# BB-P8_13-LED-00A0.dts */
/dts-v1/;
/plugin/;
/{
compatible = "ti,beaglebone-black";
part-number = "BB-P8_13-LED";
version = "00A0";
fragment#0 {
target = <&am33xx_pinmux>;
__overlay__ {
pinctrl_test: BB-P8_13-LED {
pinctrl-single,pins = <
0x024 0x27 /* P8_13 9 PULLUP ENABLED OUTPUT MODE7 - The LED Output */
>;
};
};
};
fragment#1 {
target = <&ocp>;
__overlay__ {
test_helper: helper {
compatible = "bone-pinmux-helper";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_test>;
status = "okay";
};
};
};
};
All that needs to be edited for a different GPIO pin is the "0x024" (address offset) and the "0x27" to set various aspects of the GPIO like pullup vs. pulldown and pinmux mode. Derek Molly has an older version of his guide which has the table for building the pinmux binary values (that need to be converted to hex): http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/
Most of the information is available in the Beaglebone SRM which I should probably read at some point.
The .dts file in my first answer did not fix my problem. GPIO P8_13 still boots as an input. After more digging and testing I have discovered it is NOT possible to make a GPIO direction survive a reboot. It will always boot to the default and the best you can do is enable a pullup or pulldown resistor to keep the pin high or low until a custom service file (or program) can write to /sys/class/gpio/gpioXXX/direction. I even tried decompiling am335x-boneblack.dtb, editing it, and re-compiling with no luck.
This is sad and incredibly frustrating. What good is an output that flickers during reboot? Guess I'll have to compensate with fancy external circuitry.
Per the original question, you can author a dts file where the GPIO remains in /sys/gpio/class/. See the article I wrote below for an example that works this way.
https://takeofftechnical.com/beaglebone-black-led-control/
I'm relative new to device drivers on linux.
What im trying to achieve is that on boot-up of my Raspberry an external RGB driver will receive an i2c command so you can see a LED light up at boot.
My approach is trying to accomplish this via a kernel module that will be loaded at bootup.
I tried a lot of things to achieve this, but at the moment I feel like I have a knowledge gap. Maybe someone can help me? (note that its not a hardware issue, from user space I can send commands to the device.)
My kernel module code is as following:
#include <linux/i2c.h>
#include <linux/init.h>
#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/hwmon.h>
#include <linux/hwmon-sysfs.h>
#include <linux/regmap.h>
MODULE_AUTHOR ("Niels");
MODULE_DESCRIPTION("driver rgb led");
MODULE_LICENSE("GPL");
/*CAT3626 control registers*/
#define CAT3626_ADDRESS 0x66
#define CAT3626_ENA 0x03
#define CAT3626_REGA 0x00
#define CAT3626_REGB 0x01
#define CAT3626_REGC 0x02
struct cat3626 {
struct device *dev;
struct regmap * regmap;
};
enum {
cat3626,
};
static const struct of_device_id cat3626_dt_ids[] = {
{ .compatible = "onsemi,cat3626", .data = (void *)cat3626},
{ }
};
MODULE_DEVICE_TABLE(of, cat3626_dt_ids);
static const struct i2c_device_id cat3626_id[] = {
{"cat3626",cat3626},
{ }
};
MODULE_DEVICE_TABLE(i2c, cat3626_id);
static const struct regmap_config regmap_config = {
.reg_bits = 8,
.val_bits = 8,
};
static int cat3626_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
struct cat3626 *cat3626;
const struct of_device_id *match;
int ret;
cat3626 = devm_kzalloc(&client->dev, sizeof(struct cat3626), GFP_KERNEL);
if (!cat3626){
return -ENOMEM;
}
dev_set_drvdata(&client->dev, cat3626);
cat3626->dev = &client->dev;
cat3626->regmap = devm_regmap_init_i2c(client, ®map_config);
if (IS_ERR(cat3626->regmap)) {
dev_err(cat3626->dev, "regmap allocation failed\n");
return PTR_ERR(cat3626->regmap);
}
i2c_set_clientdata(client, cat3626);
match = of_match_device(cat3626_dt_ids, &client->dev);
if (!match) {
dev_err(&client->dev, "unknown device model\n");
return -ENODEV;
}
ret = i2c_smbus_write_byte_data(client, CAT3626_ENA, 0x30); /* write LED C on*/
ret = i2c_smbus_write_byte_data(client, CAT3626_REGC, 19); /* write mA*/
return ret;
}
static struct i2c_driver cat3626_driver = {
.driver = {
.name = "cat3626",
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(cat3626_dt_ids),
},
.probe = cat3626_probe,
.remove = cat3626_remove,
.id_table = cat3626_id,
};
module_i2c_driver(cat3626_driver);
Here is the makefile:
ifneq ($(KERNELRELEASE),)
obj-m := hiber_rgb_driver.o
else
KERNELDIR ?= \
/lib/modules/`uname -r`/build/
PWD := `pwd`
default:
$(MAKE) -C $(KERNELDIR) \
M=$(PWD) modules
endif
clean:
rm -f *.ko *.o Module* *mod*
In the /boot/config.txt file I have added this:
dtoverlay = i2c-gpio, bus = 80, i2c_gpio_delay_us = 2, i2c_gpio_sda = 44, i2c_gpio_scl = 45.
In addition I made a custom dtoverlay:
/dts-v1/;
/plugin/;
/ {
fragment#0 {
target = <&i2c80>;
__overlay__ {
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
cat3626: cat3626#66 {
compatible = "onsemi,cat3626";
reg = <0x66>;
clock-frequency = <400000>;
};
};
};
};
Unfortunalty on boot-up nothing happens.
All I get from the bootup dmesg is the following:
rgb_driver: loading out-of-tree module taints kernel
Anyone can give me any help, or a maybe a different approach to achieve my goal?
Thanks in advance!
A couple of things to look at - a tainted kernel is often feature-reduced and you probably don't want to go there if you don't have to. I'd try to solve the tainting issue. I've built kernel modules as standalones and not hit the taint issue. You may wish to revisit your makefile, this is a more standard module-building makefile with a couple of wrinkles as, of course, you are crossing compiling -
PWD = $(shell pwd)
obj-m += hiber_rgb_driver.o
all:
make ARCH=arm CROSS_COMPILE=$(CROSS) -C $(KERNEL) SUBDIRS=$(PWD) modules
clean:
make -C $(KERNEL) SUBDIRS=$(PWD) clean
and build it with something like -
make KERNEL=<LINUX_SOURCE_DIR> CROSS=<TOOLCHAIN_DIR>/bin/arm-linux-gnueabihf-
So there is that.
Next, your device probe stuff looks interesting. I don't have time to debug it for you, but I'd suggest adding some printk's in there to verify the probe is getting hit. If it is, then great, it's just a matter of figuring out why you are not 'matching'. If it is not getting hit, then read on ..
As you probably know, i2c buses are a little special when it comes to device probing. There is no real automated or magical probing that would normally happen on say a PCI bus. Instead you need to build out a device tree that the kernel can walk at boot-time to complete all of the probes.
I see that you've created an overlay snippet. You need to make sure that thing is compiled into a '.dtb' byte code binary that the kernel can parse and then put in the correct place in your boot media where grub can find it.
You may also need to update your device's master dtb to refer to this overlay, so that the kernel knows where it might go. Think of the device's dtb as being an artificial christmas tree, and the overlay as a limb that could be attached at some point in the future - you'll need to specify the attachment points in the device dtb. I wish that I could be more precise here, but hope sets you off in the correct direction on this point at least.
I think, this is a C related question.
This question is also asked in STM32 forum.
Kindly clear me the structure
Right at the moment, in AC6+Eclipse environment build error shows,
view
C:/STM32_toolchain/common/Drivers/STM32F0xx_HAL_Driver/Inc/stm32f0xx_hal_adc.h:238:2: error: declaration for parameter 'ADC_HandleTypeDef' but no such parameter
}ADC_HandleTypeDef;
^
but when you search stm32f0xx_hal_adc.h file its written as
typedef struct
{
ADC_TypeDef *Instance; /* !< Register base address */
ADC_InitTypeDef Init; /*!< ADC required parameters */
DMA_HandleTypeDef *DMA_Handle; /*!< Pointer DMA Handler */
HAL_LockTypeDef Lock; /*!< ADC locking object */
__IO uint32_t State; /*!< ADC communication state (bitmap of ADC states) */
__IO uint32_t ErrorCode; /*!< ADC Error code */
}ADC_HandleTypeDef;
Is it means, ADC_HandleTypeDef is not declare in stm32f0xx_hal_adc.h?
I think the definition __IO is declared in core_cm0.h if using CMSIS. You need to have this included in order to build HAL drivers.
You have to include this file, even if the file in the project it will not be included if you do not enable the peripheral in the CubeMx. Because there is a file called stm32f4xx_hal_conf.h you will see all files that enabled by CubeMx and if not enabled it will be comment like bellow.
/**
* #brief Include module's header file
*/
#ifdef HAL_RCC_MODULE_ENABLED
#include "stm32f4xx_hal_rcc.h"
#endif /* HAL_RCC_MODULE_ENABLED */
I'm using a led matrix shield (http://www.wemos.cc/Products/oled_shield.html) with a wemos. I'm using Arduino IDE.
The exemples work perfectly (https://github.com/wemos/D1_mini_Examples/tree/master/04.Shields/OLED_Shield/Use_SparkFun_Library)
But when I try to print text, the screen remains empty. Here is my code
#include <Wire.h>
#include <SFE_MicroOLED.h> // Include the SFE_MicroOLED library
#define PIN_RESET 255
#define DC_JUMPER 0
MicroOLED oled(PIN_RESET, DC_JUMPER);
void setup()
{
oled.begin();
oled.clear(ALL);
oled.clear(PAGE);
oled.display();
oled.setFontType(0);
oled.setCursor(0, 0);
oled.print("Hello, world");
oled.display();
}
void loop()
{
}
Any idea ?
I solved the issue. I modified SFE_MicroOLED lib.
The fonts are loaded in the program memory (via PROGMEM directive). This makes the code fail on wemos.
I remove PROGMEM directive on a fork of this lib (https://github.com/landru29/SparkFun_Micro_OLED_Arduino_Library)
I just check if the arch is ARDUINO_ESP8266_NODEMCU
https://github.com/landru29/SparkFun_Micro_OLED_Arduino_Library/blob/master/src/util/7segment.h#L37 (idem for all other font files in the same folder)
Is it possible to side-step _NSGetExecutablePath on Ubuntu Linux in place of a non-Apple specific approach?
I am trying to compile the following code on Ubuntu: https://github.com/Bohdan-Khomtchouk/HeatmapGenerator/blob/master/HeatmapGenerator2_Macintosh_OSX.cxx
As per this prior question that I asked: fatal error: mach-o/dyld.h: No such file or directory, I decided to comment out line 52 and am wondering if there is a general cross-platform (non-Apple specific) way that I can rewrite the code block of line 567 (the _NSGetExecutablePath block) in a manner that is non-Apple specific.
Alen Stojanov's answer to Programmatically retrieving the absolute path of an OS X command-line app and also How do you determine the full path of the currently running executable in go? gave me some ideas on where to start but I want to make certain that I am on the right track here before I go about doing this.
Is there a way to modify _NSGetExecutablePath to be compatible with Ubuntu Linux?
Currently, I am experiencing the following compiler error:
HeatmapGenerator_Macintosh_OSX.cxx:568:13: error: use of undeclared identifier
'_NSGetExecutablePath'
if (_NSGetExecutablePath(path, &size) == 0)
Basic idea how to do it in a way that should be portable across POSIX systems:
#define _XOPEN_SOURCE 500
#include <stdio.h>
#include <limits.h>
#include <stdlib.h>
static char *path;
const char *appPath(void)
{
return path;
}
static void cleanup()
{
free(path);
}
int main(int argc, char **argv)
{
path = realpath(argv[0], 0);
if (!path)
{
perror("realpath");
return 1;
}
atexit(&cleanup);
printf("App path: %s\n", appPath());
return 0;
}
You can define an own module for it, just pass it argv[0] and export the appPath() function from a header.
edit: replaced exported variable by accessor method