I'm currently trying to learn a bit about how txpower is set within the Linux ath9k wireless driver to enable the output amp on my wireless adaptor.
I've been editing the code for ath9k from here: https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v4.4.2/
On my Raspberry Pi, this is a 15+ minute compile process.
Is anybody able to tell me if it's possible to just compile the ath9k driver rather than the whole lot?
Many thanks!
Turns out it was fairly simple:
make defconfig-ath9k
make
Hope this helps somebody!
Related
I'm hoping to find a generic mechanism in Linux to toggle LEDs that are wired up to a GPIO controller in an embedded application.
I'm able to use either JTAG or my bootloader (setting the registers directly). However it'd be awesome to toggle some lights from usermode
I'm not well versed in this on Linux, is there a standard kernel driver that I can call from my usermode application? or do I need to write a driver for my application?
I've done a websearch and found ideas ranging from writing my own driver, to libraries that feel adhoc. I'm hoping to find the most 'standard' way, thought the stackoverflow crowd would have a good opinion
any tips would be great
You want to use the sysfs interface to GPIOs
http://www.kernel.org/doc/Documentation/gpio.txt
In that link search for "Sysfs Interface for Userspace"
I have no idea what type of system you are on, or if support for this is already enabled in your kernel or not, but that is where you want to look.
I remember reading some books about Linux Device drivers around the end of my university education for Comp. Science. Soon there-after I got a job and haven't really worked much with Linux/Embedded (I do mostly java stuff now). However it's something I want to look into.
Anyways I recall reading an online article (ill edit post if I can find it) about writing a USB Driver for Linux for a Little "USB Missile Turret" similar to this:
http://www.thinkgeek.com/geektoys/warfare/8a0f/
Anyways it went into detail about how to write the driver without a driver being provided (the guy just found a generic one on ebay....and figured out how to like...write the driver just by looking at the components and such). ANYWAYS it was pretty amazing.
I have a pretty good clue about how low level embedded stuff works, but thats for stuff like AVR's/PIC Microcontrollers, I have no idea how something like this would be written for like a Normal processor in a PC.
Anyways I guess what Im asking is.....how do you figure out this kinda stuff, where would I find such information.
edit: found the link
http://matthias.vallentin.net/blog/2007/04/writing-a-linux-kernel-driver-for-an-unknown-usb-device/
(It's way more confusing then I thought, I didn't realize he reverse engineered a Windows USB driver..im guessing it'd be impossible to figure out without snooping through a windows driver?)
The Linux kernel and drivers are GDFL source. You can read the code, change them, compile them, and experiment to your heart's delight with them. That is a pretty good way to learn.
Currently Roland does not make drivers for Linux, so I am starting a project to write a driver for the Roland GR-55 Guitar Synthesizer, but after looking around, I find I have several options and not sure which is the best or most current method, so I thought I'd ask before waisting a lot of time on this.
This device uses USB, it controls the MIDI and Audio devices in the GR-55.
ALSA or libusb api are two choices; both are new to me; its been years since I wrote a device driver and it was for Unix back in the 80's, but I do know I can figure out how, once I know what tools to use, which I'm guessing both use C still; I have looked at the libusb api; very nice; but I have no idea about ALSA project; seems they are geared into getting modules into the kernel to achieve this.
I would like to find programmers that have worked with Roland like Device Drivers dealing with MIDI and Audio that might be able to help point me in the right direction; I have asked Roland for help; will be waiting for a reply, but not wanting to hold my breath, I think getting started would be my best option; even if they do help, they will only be suppling technical specs, which would be great.
I hope I gave enough details; not much else to say when asking a question about Device drivers.
What is the experience running programs written in an audio synthesis/analysis language such as ChucK, Pure Data, Csound, Supercollider, etc. in an embedded device such as an Arduino Mega, Beagle Board or a custom board with a microprocessor or DSP chip?
I would like to know which language and hardware you chose and why. What were the obstacles, etc.? My objective is to run programs that can be easily programmed by musicians/producers in a board that is not too expensive.
I received input from someone who is successfully running ChucK programs in a Beagle Board (Ubuntu Linux on a Beagle Board running ChucK), but his choice of language and hardware was made very lightly, his setup is not using the DSP in the Beagle Board and it seems like overkill to run a whole Linux install to process audio signals.
Any input is appreciated!
Update: I found Zengarden which is a Pd runtime implementation (as a standalone C++ library) and runs well on ARM based devices. For now, I'll go with the BeagleBoard and Zengarden but in a later stage of the project, I'll need to replace the BeagleBoard with something that costs less.
I'd love to hear more input from the community.
Thanks everyone for your comments and answers. For everybody else's reference, I ended up writing a JACK client in C++ that parses and interprets PureData patches and ran it on a BeagleBoard with Angstrom Linux and JACK server. Here's a video and a tutorial that I wrote: http://elsoftwarehamuerto.org/articulos/691/puredata-beagleboard/
First, I am not an audio programmer, so I'm not familiar with the actual demands of the signal processing necessary to achieve what you want to achieve.
But, it's difficult to contrast something like the Beagle Board and the Arduino Mega, since they're really in different leagues of base performance. The Beagle Board is a 1 GHz ARM vs the Arduino Mega's 16 MHz. That tells me that whatever processing you may be interested in doing may well be within the capabilities of the Beagle Board, but the Arduino Mega would have almost no chance without an attached DSP to do the actual work.
The next consideration, is whether any of the packages you were considering using actually target DSPs for their runtimes. At a glance they seem like high level sound processing languages. With the Beagle Board, you may well have the processing power to evaluate and compile the sound source code that these packages use and let them compile in to their targets, but on the Arduino Mega, that seems unlikely.
If all you're doing is working with a piece of hardware that will be running the artifacts created by the packages you mentioned, then the Arduino Mega may well be suitable as the "development" is done on a more powerful machine. But if you want to work with these packages as is, and use them as a development tool, then running them on a Linux port to something like the may simply be a better option.
Again, after casual looking about, the Arduino Mega is roughly half the price of the Beagle Board, but the Beagle Board may well let you work at a much higher level (generic Linux). Whether either will be powerful enough for your final vision, I can't say. But I would imagine you could get a lot farther, a lot faster, using the more powerful system -- at least in the short term.
Recently, i began developing a driver of an embedded device running linux.
Until now i have only read about linux internals.
Having no prior experience in driver devlopment, i am finding it a tad difficult to land my first step.
I have downloaded the kernel source-code (v2.6.32).
I have read (skimped) Linux Device Drivers (3e)
I read a few related posts here on StackOverflow.
I understand that linux has a "monolithic" approach.
I have built kernel (included existing driver in menuconfig etc.)
I know the basics of kconfig and makefile files so that should not be a problem.
Can someone describe the structure (i.e. the inter-links)
of the various directories in the kernel-source code.
In other words, given a source-code file,
which other files would it refer to for related code
(The "#include"-s provide a partial idea)
Could someone please help me in getting a better idea?
Any help will be greatly appreciated
Thank You.
Given a C file, you have to look at the functions it calls and data structures it uses, rather than worrying about particular files.
There are two basic routes to developing your own device driver:
Take a driver that is similar to yours; strip out the code that isn't applicable to your device, and fill in new code for your device.
Start with the very basic pieces of a device driver, and add pieces a little at a time until your device begins to function.
The files that compose your driver will make more sense as you complete this process. Do consider what belongs in each file, but to some extent, dividing a driver among files is more an art than a science. Smaller drivers often fit into just one or two files.
A bit of design may also be good. Consider what you device does, and what your driver will need to do. Based on that, you should be able to map out what functions a device driver will need to have.
I also believe Linux Device Drivers, Third Edition may help you get on your way to driver development.
Linux files themselves include files based on what they do, what layer they are in, and what layer they access of the call stack. The Big Picture truly informs how each file is related to the next.
I had to fix a kernel driver once. My biggest tip (if you use vim) is to set it up with ctags so you can jump around the kernel source with ctrl-] every time you see a function you don't understand.