I have a laptop with Linux Mint and 4.4.0-78-generic kernel.
Also, I have some LEDs there in the /sys/class/leds directory, and I can turn them on and off in the userspace by executing "echo 255 > brightness" in Bash.
However, I want to switch them in my kernel module. Let’s say, that this module will listen a UDP socket and switch LED based on incoming packet data.
I have googled and found kernel source files called "leds-base.c", "leds-class.c" which contains functions to control LEDs. However, this functions require "struct led_classdev" to be passed, and I don't know where do I should get it.
How can I set LED brightness using its name from /sys/class/leds directory in a kernel module?
PS. I have seen a similar question, but it's about keyboard LEDs only, the LED I want to control is not a keyboard one, and can not be controlled by code in question mentioned before.
Implement an led_trigger class and call
led_trigger_event(led, LED_FULL);
and friends in your driver. You can bind your trigger to any LED by
echo my-trigger-name > /sys/class/leds/.../trigger
Related
have a USB module that accepts ASII commands to access functions. Need a way to send and receive commands in ASCII to module. speed 9600 Baud 8 bit no parity. To see if the module is awake I can send a "ver" inquire which means what software version is the Module. It will answer "ver 1". the module is a NumatoLab USBGPIO8 but the same commands can be used on all of their modules. I asked the same question of Numato labs but did not get a clear answer. Basically, I would like to print to the USB port and receive an answer. Thank you so much, Ray
I am trying to write a custom syscall handler that manipulates the LEDs on a BeagleBone Black board. I have gone through the kernel LED API (include/leds.h), but I am unable to find anything that'd give me a handle to the available LED devices or some other mechanism to manipulate (on/off/toggle) them. Most of the functions seem to require a led_classdev object, but I can't find a way of getting one.
I can do this from userspace using the /sys/class/leds/... interface. But I want to do something similar from kernel space. I am open to hard-coding any device names specific to BeagleBone Black as portability is not an issue.
I figured out a way to access/control the LEDs from kernel space - by creating a custom LED trigger. It doesn't give a way to enumerate available devices, and it requires the custom trigger to be assigned for an LED from user-space by writing to /sys/class/leds/foo/trigger. But it lets you manipulate the LEDs from kernel code once the trigger is assigned.
struct led_trigger *trigger;
...
led_trigger_register_simple("myled", &trigger); //create and register the trigger
...
//assign the trigger "myled" to the desired LED(s) from user-space
//by writing to the corresponding trigger files in /sys/class/leds/foo/
...
led_trigger_event(trigger, LED_FULL); //turn-on the LED(s) connected to the trigger
led_trigger_event(trigger, LED_OFF); //turn-off
The creation and registering of trigger can be done in a module init, for example. Also, if one needs to manipulate multiple LEDs independently, then as far as I can see, one needs to create separate triggers for each LED.
I am using the instructions of https://pimylifeup.com/raspberry-pi-rfid-rc522/ to learn how to read my rfid-rc522.
I installed all the things needed, and cloned from git all the files. I connected accordingly and double checked the wire.
The code in Write.py is
#!/usr/bin/env python
import RPi.GPIO as GPIO
import SimpleMFRC522
reader = SimpleMFRC522.SimpleMFRC522()
try:
text = raw_input('New data:')
print("Now place your tag to write")
reader.write(text)
print("Written")
finally:
GPIO.cleanup()
When I run it- The result stops after "Now place your tag to write" and nothing happens when I place my tag. Any help please? What's wrong here? The module gives red light meaning it is connected. Is it really connected? How do I know? Please help.
Edit: My title and tags were wrong in this question due to already saved data. I edited. :)
It can be multiple reasons why your reader is not retrieving any data:
The RFID cards that you are providing to the reader are not supported by the ISO 14443: Mifare Classic, 4K. (Some DesFire, etc...) are the cards you want to try. Source: https://en.wikipedia.org/wiki/ISO/IEC_14443
The MFRC522 is not receiving enough input voltage. Try to increase from 3.3V to 4V. I have tried with 5V months and the reader is still running perfectly, but be cautious. The safe range in NXP is from 2.5V to 3.6V. Source: https://www.nxp.com/docs/en/data-sheet/MFRC522.pdf
The library you are using does not support IRQ (Interruption Request). This means the process of reading UIDs is high CPU consuming and low in performance. Try to use this popular library which supports interruptions: https://github.com/ondryaso/pi-rc522 . You will need to connect another wire from the IRQ pin in the MFRC522 to one GPIO pin in the Raspberry that is free and supports reading/writing operations.
Check if SPI interfaces are enable in Raspbian. Open a terminal and run:
ls -l /dev/spi
Lastly, it could be that your reader is broken. Some chinese versions do not work as they should do. Maybe you should buy another one and try more luck.
I suppose you have connected all cables in the correct way between the MFRC522 and the Raspberry Pi. Check that again.
As known, u-boot loader supports some sort of "input device system" that allows to register a set of functions (like getc, tstc, start, etc...). So I need to implement my own hardware-specific "keyboard". What should I do? Sounds simple:
1) Create at least "init", "tstc", "getc" and "start" functions in driver file.
2) In "init" call "stdio_register" to let system know about my device.
3) Call driver "init" from my custom board init code.
What the problem? Unfortunately, it doesn't work. stdio_register returns 0 (like all OK), but "start", "tstc", "getc" were never called.
I guess I'm doing something wrong, but I cannot understand: another keyboards drivers seems to not contain any additional code for keyboard registration. Can anybody tell the truth?
Or maybe I should just hack u-boot and insert polling call somewhere in main_loop? :)
It sounds like you have created a custom device driver.
struct stdio_dev kon_dev
Try something like this at U-Boot command line to switch console to the custom driver
setenv stdin kon_dev
Of course, your custom driver will have to be debugged before you get to the happy place. It may not work the first time.
Using netconsole is similar to what you're doing. With netconsole it's possible for example to keep stdout continuously on serial device, switch stdin to nc device (that is, "setenv stdin nc", enter commands through that netcat session a while, then switch stdin back to serial.
Posix requires changing RTS pin on port opening. I want a way to avoid it.
I have no idea why you'd want to do this, but this can be done pretty easily by modifying the linux kernel driver for your serial console so it doesn't toggle RTS. For example, for the 8250-series driver in drivers/tty/serial/8250/ you could change every write to the MCR register (UART_MCR) to ensure that bit 1 (mask is UART_MCR_RTS) is never set.
Since it's abstracted away in userspace, you're out of luck if you want to do this without modifying the kernel driver.
Having the same problem, I'd give it a try by patching the ftdi_sio kernel driver. You just need to uncomment a small piece of code in ftdi_dtr_rts() like this:
static void ftdi_dtr_rts(struct usb_serial_port *port, int on) {
...
/* drop RTS and DTR */
if (on)
set_mctrl(port, TIOCM_DTR /*| TIOCM_RTS*/); // <<-- HERE
else
clear_mctrl(port, TIOCM_DTR /*| TIOCM_RTS*/); // <<-- and HERE
}
and the RTS handshake line is not longer changed upon open() call.
Note, that the uart than might not longer working with RTS/CTS hardware handshake, as long as your modified kernel driver is loaded. But you can still control the state of the RTS handshake line manually by calling e.g.:
int opins = TIOCM_RTS;
ioctl(tty_fd, TIOCMBIC, &opins);
I'd tested this with the Ctrl+A+G command of picocom 2.3a, running Kubuntu 16.04 64 bit and Ftdi FT2232H based usb uart adapter.
You might find more details on this topic here.
A change in the DTR pin can be (eventually) avoided using the command line
stty -F /dev/ttyUSB0 -hupcl
This has the effect of making DTR turn on; and subsequently when the port is opened and closed, DTR is not affected.
Source: https://raspberrypi.stackexchange.com/questions/9695/disable-dtr-on-ttyusb0/27706#27706
And there is code there to do the same thing from python via termios, this can be done before opening the port via pyserial:
import termios
path = '/dev/ttyACM0'
# Disable reset after hangup
with open(path) as f:
attrs = termios.tcgetattr(f)
attrs[2] = attrs[2] & ~termios.HUPCL
termios.tcsetattr(f, termios.TCSAFLUSH, attrs)
The OP was running this on a Raspberry Pi, but I just tried it on Linux Mint on x86_64, it worked. I don't know how RTS is affected.
The reason I find this useful, is for communication with an Arduino Nano - which has a USB-> serial chip on board - and normally the Arduino gets reset every time you open the serial port from linux (rising edge of DTR causes reset). For some applications, this is not a problem, but it's clearly useful to avoid this for other applications, and it's not so easy to remove that tiny capacitor from the Arduino which connects DTR to reset.
You will still get a single reset when the stty command is executed (after plugging in the USB cable). But at least you can then keep opening and closing the serial port after that without further resets.
calling fopen("/dev/ACM0", "r") doesn't require you do do anything:) You may not receive the data you expect though.