For a project I'm thinking of using this relatively new IC from TI - the ADS7138. The issue (I believe, though I may be wrong) is that there is no driver for this chip in the kernel. Does anyone have any suggestions for a work around to talking to this driver? Is there another driver I could use or am I stuck writing a custom driver specific for this IC?
I've worked on a board bring-up project with the same IC. I couldn't find a driver for it so I wrote one myself. I hope it works for you as well:
ADS7138 Driver
Till you find a compatible kernel driver or develop one yourself, you can quickly experiment with the ADC from user space using the i2c-tools. You can use either the command line tools or use the API to write your own app, but be cautious if you use the command line tools like i2cget(8), first read the man pages and pay attention to the warning section.
To use the API, open(2) the i2c device, set the slave address with ioctl(2), then use smbus APIs like i2c_smbus_write_word_data(), i2c_smbus_read_word_data() etc. You may take a look at the tools code like i2cget.c itself to see how the API is used. Following is a simple code to read a register from an I²C chip connected to /dev/i2c-0.
int fd = open("/dev/i2c-0", O_RDWR);
ioctl(fd, I2C_SLAVE, slave_address);
__s32 res = i2c_smbus_read_word_data(fd, register_address);
close(fd);
See kernel documentation or the web about i2c/smbus and instantiating i2c devices for more details.
Related
I am trying to make some custom firmware for a MIDI controller (AKAI LPD8).
There is an STM32F102R8T6 chip in the unit.
I am trying to reach it with a programmer to wipe it, but it seems to not be responsive.
Some information and thing I have tried:
The firmware that came with the unit works, so the chip is not broken
Removed the components connected to the programming pins (PA9-PA10 and PA13-PA14)
I am able to pull BOOT0 high and have it not run the main program, but I am however not able to get a life sign using either an ST-Link2(clone) connected to PA13/14, nor a USB to serial adapter connected to PA9/PA10, so I am not sure what mode it is in
The connection has been checked, and RX-TX etc is the correct way around (but also for the sake of trying it all, I reversed the connections as well...).
Tried both the STM32CubeProgrammer and stm32flash, but none connects.
I am actually not sure if AKAI have locked the chip in such a way that you cannot even do a full chip erase and use the chip for something new? The NRST pin is strangely not doing anything to the running of the firmware either when I try to pull it low.
Is there a way to reprogram these chips when they come off of a commercial product, or are they permanently locked?
Any solution/tips?
Many of the STM32 parts have "proprietary code read-out protection" (google PCROP) which but you might be lucky and they haven't enabled it in the option bytes. Read the documentation for that and the bootloader documentation and get a good idea of what you expect it to do if it is enabled and if it isn't.
If you have a scope, try watching the SWD/JTAG pins to see if there is any response from the device. (If you aren't even sure if it is in reset then scope the crystal if there is one).
If you haven't got a scope, you might be able to to verify what it is doing by seeing if it sets the pins and pull-resistors to how they would be expected to be in the bootloader mode, eg: UART TX should be high if it is enabled, even it it isn't transmitting anything. Put a strong pull-down (~1k) on there and see if it still reads high.
After hours of trying different ways of making it work (also tried the alternate mapping of the UART port), and probed the TX pin as suggested by Tom V to no avail, I have given up working on that specific chip and ordered an upgrade from the STM32F4 family instead to replace it with. A lot more power and useful peripherals.
A bit of a non-answer to the specific question. Frustrating to not have found out what was wrong (chip or approach) but being mindful of the sunk cost fallacy, I think it was best to just replace the chip with a fresh one and start development from there.
I have a 600W digital step up converter with broken STM8S103K3T6C and another that is currently working OK. Is there a way to copy (dump) firmware from the working one and upload it to the new chip. Since I have only one working, I have to be extra careful not to damage the working controller. I do have some basic experience with STM32, but I am grateful for any help I could get. I have a copy of ST-Link v2 programmer. Apparently (if there is a way), it has to be done via SWIM (which I don't nothing about, started reading few days ago). Not sure what is the proper way to start. Converter itself has UART pins at the right side of the board.
Thanks in advance.
if the chip is not locked, yes it's possible using SWIM interface. use STVP tool to extract firmware from the old one or to program it to the new one. it is bundled in a package called "ST toolset" for STM8 and downloadable from ST website. the SWIM needs 1 pin (plus reset if target uses that pin). despite that the STM8s hvae 3~5V supply, it's better to use 3.3V supply for it for the sake of the other circuitry. you can extract it even when the device is on, so there's no need to connect a supply pin from programmer to it.
I'm working on a project that is using a Raspberry Pi with Raspbian and an SGTL5000 based sound card (FePi.) I have no problem selecting the card and getting samples in both directions - once I have configured the multiplexer to properly select line In/Out. I did this with Alsamixer. I want to automate the process so that the only step required is to run the application.
I don't see a way to do this using PyAudio/PortAudio. Is my only option the ALSA API or is there a way to do this with PyAudio (or PortAudio) that I'm not spotting?
Thanks in advance for any insight you can provide.
Oz (in DFW)
I ran into a similar problem, I wanted to automate changing mux settings but I wanted to adjust inputs not exposed by alsamixer too.
To deal with the limitations of the driver I ended up porting over the Teensy 3.x sgtl5000 control software to the pi yesterday
https://github.com/Swap-File/pi-sgtl5000
You could force feed the same commands via i2c via python.
The only downside is, once you start force feeding the sound card i2c commands, you break alsamixer (and anything else that might try to adjust it's own volume settings).
My question is quite simple.
I encountered this sys_vm86old syscall (when reverse engineering) and I am trying to understand what it does.
I found two sources that could give me something but I'm still not sure that I fully understand; these sources are
The Source Code and this page which gives me this paragraph (but it's more readable directly on the link):
config GRKERNSEC_VM86
bool "Restrict VM86 mode"
depends on X86_32
help:
If you say Y here, only processes with CAP_SYS_RAWIO will be able to
make use of a special execution mode on 32bit x86 processors called
Virtual 8086 (VM86) mode. XFree86 may need vm86 mode for certain
video cards and will still work with this option enabled. The purpose
of the option is to prevent exploitation of emulation errors in
virtualization of vm86 mode like the one discovered in VMWare in 2009.
Nearly all users should be able to enable this option.
From what I understood, it would ensure that the calling process has cap_sys_rawio enabled. But this doesn't help me a lot...
Can anybody tell me ?
Thank you
The syscall is used to execute code in VM86 mode. This mode allows you to run old "real mode" 32bit code (like present in some BIOS) inside a protected mode OS.
See for example the Wikipedia article on it: https://en.wikipedia.org/wiki/Virtual_8086_mode
The setting you found means you need CAP_SYS_RAWIO to invoke the syscall.
I think X11 especially is using it to call BIOS methods for switching the video mode. There are two syscalls, the one with old suffix offers less operations but is retained for binary (ABI) compatibility.
I have written a Loadable Kernel Module (LKM) which wraps the audio-driver under /dev/snd/pcmC0D0p .
Therefore I moved pcmC0D0p to pcmC0D0p_bak, renamed my driver to pcmC0D0p and passthru every command like MMAP, IOCTL etc. (but doing other things before forwarding the MMAPed-data).
This is bad, I know (but it's my first step in linux-programing) but it worked.
Today, I read in an article about Userspace device drivers.
Now I'm wondering: should this really be possible? Write a "driver" with userspace-code, implemented methods like MMAP & IOCTL and put it in place of a normal kernel-device (/dev/snd/pcmC0D0p)?
It isn't, isn't it?
IF it's possible, has anyone a simple example, a reference? Anything is really welcome!
It is possible to write userspace device drivers, but not quite in the way you're thinking.
An example is the uio_pci_generic module, this can be programmed (via /proc) with the ID of a PCI device and will make the device's memory available to you via mmap. You can receive interrupts by blocking on a read call.
Note how this does not allow you to pretend to be a driver, only to perform driver-like actions (communicating directly with a hardware device, receiving interrupts, etc). No userspace program can ever service a call to ioctl, or expose itself as a character device, without the help of some kernel module.