Can I detect insertion and removal of headset using alsa API ? Which API should I use ? My kernel is 3.0 Linux running on ARM.
Having wanted precisely this functionality for a embedded project, I did some investigations and came to the conclusion (about 6 months ago) that there isn't any generic support in ALSA for jack insertion detection.
Interestingly, I did find headphone (and microphone) detection support in the codec driver I was using (tlv310aic3xxx), but is didn't seem to be plumbed into any upper layers. I suspect that the reason this exists is is Android.
There are essentially two ways of adding this support:
Add support to the codec driver - probably exposing a sysfs node that something in user-space can then block on.
Force access to the I2C bus on which the codec is hung (the codec driver usually 'owns' the device) and programme the relevant registers from user-space.
You may face an additional architectural problem in that whilst the codec can detect insertion events, it needs some way of interrupting the CPU. The tlv310aic3xxx devices have programmable GPIO pins, which can be connecting to a interrupt line on the main CPU (if on an embedded platform, this will be another GPIO line). Without this, you'll need to poll it.
Related
I'm trying to understand all OS theory. But here a problem, I can't find any information on the net to switch in SVGA (or HDMI) to draw on a monitor. I already know we have 4x4096 KB allocated as video memory for VGA but really, it's limited if we want 1080x720 resolution. So
- How to switch to SVGA (or HDMI) ? Probably a syscall or I/O request ?
- After that, how to re-define the address of the video memory ?
- Bonus question : how to use the technology of accelerated hardware ?
Thank you in advance for your answer and sorry for my eventuals wrongs in English
The only common low-level standard for resolutions bigger than VGA is VESA BIOS Extensions (VBE). I don't know how widely it's covered with the UEFI backward compatibility, because it's almost never used nowadays.
BIOS Extensions are like drivers built into the card itself. To switch the video mode, or to have pointer to VRAM, you have to call the proper VBE service via it's interrupt. The ROM "driver", designed to work with a certain hardware, performs the needed operations and returns the result.
Unfortunately, no hardware acceleration were covered by VBE, so they became more and more obsolete as GPU became more and more important. No suitable replacement was developed, so if you want to work with bare hardware, you must know every video chip (or, at least, a chip family if they're close enough) and write a driver for each one. If PDFs are free, it's easy (I've worked with 3dfx, it's simple: write to the port N, wait until bit R on port M becomes 1 etc).
The problem is, you have to do it for every chip.
You can also read some Linux driver sources, if you want to see how all those ports and I/O are triggered.
I am upgrading the processor in an embedded system for work. This is all in C, with no OS. Part of that upgrade includes migrating the processor-PC communications interface from IEEE-488 to USB. I finally got the USB firmware written, and have been testing it. It was going great until I tried to push through lots of data only to discover my USB connection is slower than the old IEEE-488 connection. I have the USB device enumerating as a CDC device with a baud rate of 115200 bps, but it is clear that I am not even reaching that throughput, and I thought that number was a dummy value that is a holdover from RS232 days, but I might be wrong. I control every aspect of this from the front end on the PC to the firmware on the embedded system.
I am assuming my issue is how I write to the USB on the embedded system side. Right now my USB_Write function is run in free time, and is just a while loop that writes one char to the USB port until the write buffer is empty. Is there a more efficient way to do this?
One of my concerns that I have, is that in the old system we had a board in the system dedicated to communications. The CPU would just write data across a bus to this board, and it would handle communications, which means that the CPU didn't have to waste free time handling the actual communications, but could offload the communications to a "co processor" (not a CPU but functionally the same here). Even with this concern though I figured I should be getting faster speeds given that full speed USB is on the order of MB/s while IEEE-488 is on the order of kB/s.
In short is this more likely a fundamental system constraint or a software optimization issue?
I thought that number was a dummy value that is a holdover from RS232 days, but I might be wrong.
You are correct, the baud number is a dummy value. If you create a CDC/RS232 adapter you would use this to configure your RS232 hardware, in this case it means nothing.
Is there a more efficient way to do this?
Absolutely! You should be writing chunks of data the same size as your USB endpoint for maximum transfer speed. Depending on the device you are using your stream of single byte writes may be gathered into a single packet before sending but from my experience (and your results) this is unlikely.
Depending on your latency requirements you can stick in a circular buffer and only issue data from it to the USB_Write function when you have ENDPOINT_SZ number of byes. If this results in excessive latency or your interface is not always communicating you may want to implement Nagles algorithm.
One of my concerns that I have, is that in the old system we had a board in the system dedicated to communications.
The NXP part you mentioned in the comments is without a doubt fast enough to saturate a USB full speed connection.
In short is this more likely a fundamental system constraint or a software optimization issue?
I would consider this a software design issue rather than an optimisation one, but no, it is unlikely you are fundamentally stuck.
Do take care to figure out exactly what sort of USB connection you are using though, if you are using USB 1.1 you will be limited to 64KB/s, USB 2.0 full speed you will be limited to 512KB/s. If you require higher throughput you should migrate to using a separate bulk endpoint for the data transfer.
I would recommend reading through the USB made simple site to get a good overview of the various USB speeds and their capabilities.
One final issue, vendor CDC libraries are not always the best and implementations of the CDC standard can vary. You can theoretically get more data through a CDC endpoint by using larger endpoints, I have seen this bring host side drivers to their knees though - if you go this route create a custom driver using bulk endpoints.
Try testing your device on multiple systems, you may find you get quite different results between windows and linux. This will help to point the finger at the host end.
And finally, make sure you are doing big buffered reads on the host side, USB will stop transferring data once the host side buffers are full.
I've done many projects that include a PC & an arduino / PLC / some kind of other microcontroller / processor, and in every project we had a different protocol used for communication between the PC application and the embedded one. Usually the hardware / controller developer invents a simple protocol which always changes throughout the project, and goes into the form of
Barker | Size | Data | Checksum
This time I'm implementing both sides, so I figured - This has been done a million times before. There must be a base protocol for these things with implementations in C, C#, Java, and such.
What I'm looking for is a lightweight layer that transfers stream based serial communication into a message based one.
I've been looking around for one for a while, but I couldn't find anything on my own.
Do you happen to know one?
I had exactly the same requirements for a recent project and I found nothing simple enough for low-end 8-bit microcontrollers. So I designed MIN (Microcontroller Interconnect Network) to do the job (inspired by CAN and LIN).
The code is on github here: https://github.com/min-protocol/min (check out the wiki there).
I defined a layer 0 (the UART settings) and layer 1 (the frame layer, with checksums, etc.) plus a C API.
I'm also working on a higher layer that formally defines how sensor data (temperature, pressure, voltage, etc.) are packed, with a JSON representation and a tool to autogenerate the embedded code to pack/unpack them from frames. The end goal is to create a Wireshark dissector that can be clipped on to the serial line and when fed with the JSON will display the signals in human-readable form.
I wrote a blog post showing a Hello World app running on an Arduino board (with an FTDI UART-USB breakout board carrying the data up to my host PC):
https://kentindell.wordpress.com/2015/02/18/micrcontroller-interconnect-network-min-version-1-0/
This serial problem occurs so often that it would be nice if we as a community just nailed it rather than keep re-coding it for every project.
Check Open Source HDLC
I recently came across MIN - never used this one though
Also check this
Simple serial point-to-point communication protocol
Using X/Y/Z MODEM protocol must be a good choice to solve your problem. It's easy to implement and ready-to-use. I use X-MODEM on an ISP tool communicates with our cortex-m0 powered MCU, and it works pretty well.
I wish to read the EUI64 address from an AT24MAC602 memory chip interfaced to an Atmega128rfa1 MCU over the Two wire interface. I tried to modify the I2C master drivers which are available for other platforms to suit my need. However, I wasn't able to carry out these modifications successfully as the program stopped responding as soon as the slave address was written to the twi bus with Write flag set. I failed to uncover the underlying reasons for the same.
As Contiki OS is quite popular, i thought someone might have already come up with contiki specific libraries for reading writing over TWI interface for Atmega128rfa1 MCU. If so, please provide pointers to the twi drivers or documentation for the same, or suggest factors that should be considered for developing such drivers. Thank you.
If you don't have any luck finding/creating a driver for the TWI peripheral, you might consider emulating it by configuring the SDA/SCL pins as general I/O and then implementing the TWI protocol yourself. If you're just doing a one-time read of a chip ID then speed probably isn't a big concern, so this could work if you get desperate. Google should throw up a few examples of emulated TWI.
I am doing IO programming in C in Ubuntu. And I need the base address of the port to write data.
My laptop dont have a parallel port. So I bought a USB to Parallel port connector. I plugged in the device and its getting detected in /dev/usb/lp0
I ran "lsusb" to see the list of devices and I can see the ID also. But how can I get the base address ? For the usual hardware parallel devices, the base address is 0x0378. this address is not getting detected while using USB to Parallel device.
Please help.
A USB parallel port doesn't have a base address - it's not a meaningful concept for USB. I'm afraid the days of doing I/O on PC hardware via in and out instructions ended a few years ago, though lots of old tutorials still survive on the web.
You can write bytes to the parallel port as a character device, and these will appear on the printer port pins. The USB adapter will expect the other end to handshake data exactly like a printer. If you want to do general I/O prototyping, you're probably better off with a simple USB microcontroller like an Arduino.
Further discussion here.
If you are still interested to use this USB-to-parallel-printer device for your own bit-banging, it's important to know that their built-in firmware always allows controlling of D0..D7, INIT (as outputs), /ERR, ONL, PE (as inputs), but never for /ACK, BUSY (inputs), /STB, /AF, /SEL (outputs) pins.
And you need an 8-bit latch (e.g. 74HCT574) for catching data while strobing.
See here (https://www-user.tu-chemnitz.de/~ygu/bastelecke/PC/USB2LPT/faq#DIY)
especially for possible data rates.
Accessing from software side is a bit complicated but possible, and you may have to re-structure your software and hardware for making such adapters useable. I don't know for Linux case how to access, but IMHO you don't need to write a kernel-mode driver.