tag:blogger.com,1999:blog-68380644522690767262024-03-05T23:58:16.973-08:00Beaglebone Black GSOC 2013Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.comBlogger39125tag:blogger.com,1999:blog-6838064452269076726.post-79894126515338379132013-09-22T03:00:00.001-07:002013-09-22T03:00:41.418-07:00Success at last :)Finally. Patches for continuous sampling got accepted in IIO.<br />
<br />
<a href="http://thread.gmane.org/gmane.linux.kernel.input/32024">http://thread.gmane.org/gmane.linux.kernel.input/32024</a><br />
<br />
All the hard work paid of in the end. Achievement unlocked.<br />
:)<br />
<br />
A hiccup n warning here n there mentioned by the autobuild scripts. but no biggy. sending a couple of cleanup patches in a jiffy<br />
<br />
<a href="http://thread.gmane.org/gmane.linux.kernel.iio/9638">http://thread.gmane.org/gmane.linux.kernel.iio/9638</a><br />
<br />
Now for rebasing stuff for koen's trees. A long blogpost describing how to get the driver to work from userspace. The trigger stuff on the blog is redundant and misleading now. I'll put a note in the start of those posts pointing to the new one when its done..Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com36tag:blogger.com,1999:blog-6838064452269076726.post-42385320226017874142013-09-18T23:38:00.001-07:002013-09-18T23:39:29.610-07:00Round 11. 2 steps forward. 1 step backwardThe devm usage initially guided by iio was incorrect as pointed out by Dmitry.<br />
<br />
reverted the change. Go forward. Go backward. But like Koen pointed out once. Any feedback is good feedback. MIA is the worst. So i should remain thankful :)<br />
<br />
<br />
And on another note,<br />
fifo storage was 32 bit. But actual adc data was 16 bit.<br />
iio didn't like it. Changed it. memory usage is a bit optimized now.<br />
<br />
<a href="http://thread.gmane.org/gmane.linux.kernel.input/32024">http://thread.gmane.org/gmane.linux.kernel.input/32024</a><br />
<br />
And the hope/wait begins Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-12820008928125584852013-09-18T09:38:00.002-07:002013-09-18T09:38:59.321-07:00Finally. So close yet so far.IIO likes the driver except for one tiny bit.<br />
Using a 32 bit buffer to store 12 bit adc data.<br />
<br />
Except for that minor change jonathan stated 'Very very nearly there' :)<br />
<br />
I'll make the changes and test the thing and get it done in some time<br />
<br />
Thankfully, i'll be walking away with a completeness feeling from GSoC :)Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-15483733371590168982013-09-18T04:30:00.001-07:002013-09-18T04:30:38.364-07:00Round 10. quick updateI misunderstood the new devm interfaces.<br />
Dmitry and Jonathan were kind and explained it to me.<br />
<br />
I updated and resent the series.<br />
<br />
<a href="http://thread.gmane.org/gmane.linux.kernel.input/31993">http://thread.gmane.org/gmane.linux.kernel.input/31993</a><br />
<br />Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-43682465320241404742013-09-17T01:47:00.003-07:002013-09-17T01:49:37.684-07:00Round 9! Continuous Sampling supportFinally put another couple of rounds of energy into the IIO driver..<br />
<br />
It should get accepted now. *hopefully*<br />
<br />
3.12-rc1 has started!<br />
<br />
any ways.<br />
<br />
I have restructured the driver the way Jonathan wanted. *again*!<br />
<br />
I sincerely hope there isn't any big structural issue now.<br />
Small fixes/rebase is ok. <br />
<br />
<a href="http://thread.gmane.org/gmane.linux.kernel.iio/9438">http://thread.gmane.org/gmane.linux.kernel.iio/9438</a><br />
<br />
Fingers crossed..<br />
<br />
I need to rebase stuff for Koen's trees too.. Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-56150036243192528492013-09-10T23:52:00.001-07:002013-09-10T23:52:40.297-07:00Rework. Again.This is getting quirky.<br />
<br />
http://thread.gmane.org/gmane.linux.kernel.input/31730<br />
<br />
Feedback from IIO thankfully. Now I don't have to sit idle.<br />
<br />
But I'm in new territory now.<br />
basically IIO wanted me to implement a trigger based continuous sampling where the iio trigger occurred on every fifo threshold interrupt.<br />
I implemented it.<br />
<br />
But after seeing it. Now they want something else instead :) <br />
<br />
And that is tricky and new territory.<br />
Up till now. IIO relies on existing drivers as a template for people like me who have to write another driver.<br />
<br />
However. there is no existing driver that I can use. Because the am335x has a hardware fifo. and IIO drivers for adc's are mostly for external adcs and one-shot. Even if continuous. They use external triggers for sampling. Kind of like a continuous one-shot.<br />
<br />
But for the am335x. As an ADC i'd say its better! But doesn't fit existing IIO models. Especially the internal triggerless sampling based on the ADC clock and fifos.<br />
One would think a fifo and adc sampling is simple. It is. But the firmware is a pain. And fitting it in the IIO model/ABI is even more of a pain.<br />
<br />
IIO has support for this. But no existing driver that uses it.<br />
I would look at existing drivers for help every time.<br />
Now i have to look deeper inside the IIO core and get things to work..<br />
<br />
Apart from the fact that there might be unknown issues in the core itself as its basically untested I guess..Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-35308372396596330442013-09-03T12:09:00.001-07:002013-09-03T12:09:41.468-07:00stumbling blocksExchanged an email with Jonathan..<br />
I missed the window for submitting the patches for 3.12. He said that they'll go for 3.13 now.<br />
<br />
I don't think they'll be reviewing the patches during the merge window..<br />
<br />
I guess I'll rebase the work and push it to the trees koen maintains. and write a few blogposts on the new interface for the continuous sampling.<br />
<br />
Not exactly sure what to do now lol. this patches stuff got delayed by two weeks that the merge window will last. I'll have to push on these patches after gsoc timelines perhaps.Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-5493489274464555712013-09-01T04:20:00.000-07:002013-09-01T04:20:49.802-07:00Round 7! continuous modeThis is getting really tiring now.<br />
Send patches. wait for feedback that messes with your head.<br />
Do it all over again. No wonder the world works on automated test scripts etc.<br />
my testing is slow i think. other than that. updates using git rebase are getting really good.<br />
<br />
*LOL*<br />
I didn't check the iio branch and found that it had gone ahead by dozens of commits..<br />
<br />
had to check right after sending the mails for round 7 lol..<br />
<br />
Anyways. hope they dont mind the spam. sent round 8 immediately with updates. thats why they use scripts. some of em probably check if remote branch has gone ahead or not..<br />
<br />
<a href="http://thread.gmane.org/gmane.linux.kernel.input/31730">http://thread.gmane.org/gmane.linux.kernel.input/31730</a><br />
<br />
Anyways. i think i missed the time window and the patches are going to be rebased and sent etc etc after 3.12..<br />
<br />
Lets see what Jonathan has to say about them..Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-21507249273450291022013-08-28T12:04:00.000-07:002013-08-28T12:04:39.766-07:00Round 6 list feedbackSome serious stuff going on the lists.. The Linux Kernel really is scrutinized awesomely.<br />
<br />
<a href="http://thread.gmane.org/gmane.linux.kernel.iio/8861">http://thread.gmane.org/gmane.linux.kernel.iio/8861</a><br />
<br />
Highlights:<br />
- Quirks in error handling paths for freeing the device due to devm_iio_alloc<br />
- error handling technique for trigger alloc in the probe. should be in trigger alloc function.<br />
- missing lines for removing trigger in remove function.<br />
- TSC/ADC IRQ sharing is confusing and messed up. Explanations.<br />
Missing entry in Kconfig.<br />
<br />
Refix and resend. And then the wait begins again.<br />
Although, the main guy reviewing Sebastian is leaving for 3 weeks.. Hope Jonathan gives the driver time and accepts it for the next cycle.Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-69999154888520765632013-08-25T15:53:00.003-07:002013-08-26T05:04:15.176-07:00Round 6. Continuous mode the way iio wantsIIO didn't like my usage of their trigger oscilloscope style. Messed their ABI.<br />
Soo. there is an internal trigger in the driver that occurs for every threshold.<br />
<br />
After the changes and some cleanup.<br />
<br />
I'm back online with round 6. hope iio likes the driver this time.<br />
<br />
<a href="http://thread.gmane.org/gmane.linux.kernel.iio/8861">http://thread.gmane.org/gmane.linux.kernel.iio/8861</a><br />
<br />
Major changes in the way driver works.<br />
<br />
Previously i would use a sysfs trigger to trigger the start of sampling after enabling the buffer.<br />
<br />
IIO didn't like that. And suggested that I create a driver trigger that would automatically trigger upon the FIFO threshold being reached every time.<br />
<br />
So. I did that. It took a while to restructure the driver.<br />
<br />
I do note one thing. Previously I would get the illusion that the adc driver is working alongside the touchscreen events.<br />
I think I was wrong. I looked at the code, thought, and checked the irq status again and again. Only one side is active at one instant.<br />
<br />
Which makes sense sorta. Cause the way I understand the hardware. The SW steps can happen (adc) or the HW steps can happen (TSC). So one of em has to give in.<br />
<br />
Although, at the moment, the ADC is at max sampling frequency. Perhaps configuring the adc with a slower sampling rate might allow the TSC steps to be configured. I'm not going deep into the sampling frequency yet. it has to do with the step delay register. the way i see it. i think all the channels can have individual sampling frequencies as well.<br />
<br />
IIO was designed with loads of flexibility in mind. but i think it was made with external adc chips in mind. not internal powerful adcs like this am335x one.Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-44336663681794458902013-08-18T11:24:00.002-07:002013-08-18T11:24:14.229-07:00IIO list feedback Update + Short HiatusFeedback from the IIO lists has been great.<br />
<br />
<a href="https://lkml.org/lkml/2013/8/13/553">https://lkml.org/lkml/2013/8/13/553</a><br />
<br />
and<br />
<br />
<a href="https://lkml.org/lkml/2013/8/13/666">https://lkml.org/lkml/2013/8/13/666</a><br />
<br />
I use the IIO ABI in a slightly non-standard way to get things done.<br />
The trigger in IIO is for triggering a single sample of data. I guess its for ADCs using the DRDY style signals etc. Thats not useful for me to to have continuous sampling.<br />
<br />
I used trigger to start the trigger oscilloscope style. To trigger a large buffer of samples.<br />
<br />
Jonathan actually suggested that such a feature could be great in the IIO core and was open to a proposal for it. Even gave a couple of paragraphs for the interface.<br />
<br />
<br />
Given the nature of the am335x sampling and fifos, the IIO trigger model doesn't fit well to trigger every sample in continuous sampling mode.<br />
<br />
Jonathan suggested to use internal triggers that occurred every time the FIFO thres handler is called. Just so that the driver fits IIO ABI a bit more/closer.<br />
<br />
I don't see any problems with implementing the driver the way IIO wants.<br />
<br />
But I'm taking a short break to finalize my MSc. thesis report this week.<br />
<br />
GregKH is great and cool with it.Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-80224951684610693702013-08-13T09:51:00.002-07:002013-08-13T09:51:38.540-07:00Round 4More patchesssss<br />
<br />
Small fix to MFD here<br />
http://thread.gmane.org/gmane.linux.kernel/1543722<br />
<br />
TSC fixes and Continuous mode here.<br />
http://thread.gmane.org/gmane.linux.kernel.input/31427<br />
<br />
I left out a fix for rc1 of the new one. Because I sent around various patches sporadically. One fix in iio. One fix in mfd.<br />
<br />
I cant send the last fix because if plays around with everywhere.<br />
<br />
But no issues.Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-59877102992584761972013-08-12T03:14:00.001-07:002013-08-12T03:14:49.785-07:00And fixeslots of tiny fixes here n there<br />
<br />
It turned into a chain of fixes. I'd fix one and then find another in the process.<br />
Fixes would become bugs and then fixes for that lol ;) <br />
<br />
Lets see.<br />
<br />
HW preempt enabled.<br />
Before, ADC was given priority. Not TSC. TSC event couldn't mess with ADC sampling. By enabling HW pre-emption, TSC event is given priority. This was done in an attempt to fix the TSC not registering a pen UP event even if the finger was lifted. (during ADC continuous mode sampling in the background)<br />
<br />
There is a small delay in the TSC IRQ which lets the TSC sequencer settle before checking for pen UP events. Had to increase that delay slightly to allow a pen UP to be registered.<br />
<br />
Locks in mfd.<br />
One fix is already in the staging. And I forgot that the function comes in pairs. I sent a fix for the set function. But forgot the clr function lol. While fixing the continuous mode driver, i found the need for the clr function and realized that the fix is mising here..<br />
<br />
TSC steps enable issue<br />
TSC steps would disable if I mess with the ADC. Because the ADC would also play with the step enable register. the common mfd core locks for set/clr help. But not completely.<br />
In some cases (during the reg_SE read, update, write, some bit would go bad), the TSC steps wouldn't be enabled properly. And that would caused the wrong configuration to hang. So had to add a mask to the mfd core.<br />
<br />
TSCADC disable in ADC code.<br />
The continuous mode code was littered in dozens of places with areas that would enable/disable the entire module. I think this was the real culprit causing the entire thing to hang. Put checks around to not disable the entire module if the TSC is alive.<br />
<br />
<br />
Reg_SE written with 0x00 on ADC side.<br />
Previously, channels for continuous sampling would enable and disable in iio_trigger_preenable. That would mess step enb register. There was even a write 0x00 for the SE register in there.<br />
Now they update the SE register via the common mfd core.<br />
<br />
I guess I was looking only at the ADC before and I didn't realize.<br />
During the bug fix phase, I'm looking at both TSC and ADC and making sure they work.<br />
<br />
Now I have a working continuous mode with TSC events that can occur simultaneously and TSC doesn't hang.<br />
<br />
But I have a different issue lol. Asking greg about it.<br />
Fix in mfd tree.<br />
Fix in iio tree.<br />
My patch series depends on both trees. lol.<br />
and splitting them can be tricky.<br />
<br />
lets see. greg said something about split. most of em can be split except for one fix which can go later.<br />
lets see.<br />
<br />
have to sort out the code and send it to the subsystems.Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-72240458889489906722013-08-05T10:31:00.001-07:002013-08-07T07:50:22.709-07:00BUGGGGGGGGSI have noticed three(lol. Update. 6 now) bugs in the TSC ADC driver.<br />
<br />
Subtle ones. Quite possible won't occur in use cases at all.<br />
<br />
Bug 1. (resolved)<br />
<br />
When I am waiting for a trigger, the touchscreen stops working..<br />
<br />
This one is cause the following line on the ADC side disables the TSC steps.<br />
<br />
tiadc_writel(adc_dev, REG_SE, 0x00);<br />
<br />
the tsc is ok after trigger.<br />
But if i do an event during waiting for trigger.<br />
tsc works. but adc doesnt. meaning tsc is disabling all configuration i did for continuous mode!<br />
<br />
Managed to move around the bit masks to the poll handler function. <br />
This one is ok.<br />
<br />
Heard back from iio list with some comments.<br />
I'll resend the patches with this bug fix squashed in.<br />
<br />
Bug 2. (sudo resolved)<br />
<br />
If I do a<br />
while(true)<br />
do<br />
cat in_voltage*<br />
done<br />
<br />
to continuously read samples using one-shot adc mode.<br />
<br />
The touchscreen registers clicks randomly!!<br />
<br />
Although this is a wild test case, it shouldn't happen<br />
<br />
Update: <br />
This is weird. Shouldn't waste time on this bug.<br />
<br />
while (true)<br />
do<br />
cat in_voltage4_raw; <br />
cat in_voltage5_raw;<br />
cat in_voltage6_raw;<br />
cat in_voltage7_raw;<br />
done<br />
<br />
wouldn't make the tsc register events or go haywire.<br />
<br />
but<br />
<br />
while (true)<br />
do<br />
cat in*; <br />
done<br />
<br />
would register events on TSC. Strange. I quadruple checked all the ADC reg configs even! everything is ok. The TSC shouldn't receive interrupts.<br />
<br />
What happens is that HW steps which aren't supposed to run unless a touch is registered actually do seem to run 'once'.<br />
This fills FIFO0 which threshold interrupts.<br />
<br />
Thus, a random click and PEN UP somewhere. Uncool.<br />
But anyways. Seems random. Especially since the expanded while loop didn't register the same phenomena.<br />
<br />
Useless. No more time wasting on this bug. managed to catch another unknown one during this process lol. bug 4!.<br />
<br />
I have to say. The more bugs I encounter. The more I understand the driver and TSADC module. The more I realize I know nothing!<br />
<br />
Bug 3. (left for later)<br />
<br />
This one is even more subtle.<br />
The old 3.8 touchscreen driver was very smooth and registered clicks properly.<br />
The one after sebastians patches seems as if the mouse is going slightly haywire sometimes.<br />
Sometimes click takes the mouse somewhere random. This is a really subtle one.<br />
<br />
I'll spend time on this if I get the chance. My focus is more ADC. But obviously. Community is community. And I'm in a good position to fix this.<br />
Basically have to compare the previous driver and the one after sebastians patches in mainline. Somewhere some calculation(i guess) is different. Although sebastians work is based on the same arago. But something feels off..<br />
<br />
Bug 4. (Resolved. Patch upstreamed :) )<br />
<br />
This time its the MFD driver. the MFD driver has a small function to update the Step enable register.<br />
Problem is. It used a reg_cache. Which isn't updated anywhere. So if I use a TSC and ADC. The reg_cache gets loaded with FFFF and all steps are enabled no matter what. ADC steps disable themselves after one sample. Which makes it ok.<br />
But sorta. The FIFO1 still gets filled up with samples.<br />
<br />
The current read_raw code was ok in the sense that it flushed the entire fifo.<br />
But too many TSC touches and the ADC FIFO will fill up with useless samples. That'll make a mess most probably.<br />
So yea. good thing I caught this bug. I'll send it as a fix to the MFD list..<br />
<br />
(OOO. Just realized. Steps updation might be why continuous Bug 6 isn't working. Damn. I'll have to check again..) (Update again lol. Dimitry from input pointed out as well. IRQs might be hanging..)<br />
<br />
Fix was simplish.<br />
added a read in there which checks current steps. <br />
<br />
Bug 5 (Resolved!)<br />
This is a fine example of a bug you add for no reason and then have to fix!<br />
<br />
I was aiming to optimize the read_raw function. But indirectly added some redundant samples that wouldn't flush. This would make a mess.<br />
<br />
If I read channel 5, I'd return early thinking I was efficient. Didn't realize Channel 6 and 7 would be in FIFO and those needed flushing.<br />
<br />
So if i read channel 7 after 10 sec. I'll get the old value. And more old data would be in the fifo. "Unoptimized the bug again". I'll squash this fix in the next series I send to IIO.<br />
<br />
Although I personally don't like the idea of sampling all channels and then flushing them out. the continuous mode code can be used to enable one channel only. Its a simple mask.<br />
<br />
But alas. I'll see if i want to clean up things. it works as it is anyways..<br />
<br />
Bug 6 (WIP)<br />
I dont know if this is a viable test case or not.<br />
A simple delay in a userspace application might make this go away. But yes. its bad.<br />
<br />
While waiting for trigger.<br />
<br />
If i'm pressing down on TSC,<br />
<br />
and trigger the adc.<br />
<br />
The entire TSCADC module hangs. Nothing works.<br />
<br />
I think the IRQs hang somehow. Cause cat /proc/interrupts stops registering anything.<br />
<br />
Maybe both handlers return none or something. And the IRQs of the TSCADC module don't occur again.<br />
Tried moving around stuff to end. But didn't work.<br />
Added ovverun handling but nope.<br />
<br />
Russ tried pointing it out on a patch. But Greg said level interrupts are ok.<br />
<br />
(Update, Dimitry from the input list pointed out the same for the patch I sent. What will happen if both IRQs go off.. Thats why system hangs maybe..)<br />
<br />
I guess this might be something really quirky.<br />
Its an awful usecase anyways..<br />
<br />
Maybe both overrun and stop the TSCADC module. and the IRQ handlers don't go into ovverun. This is quirky to debug.<br />
<br />
If I'm making a GUI running on TSC acquiring samples. I'll add a delay between the button press and the ADC sampling to avoid this race condition.<br />
<br />
But yea. something like a GUI oscilloscope on a BBB might seem far of. I don't think the module can handle such complexity for real time sampling and display.<br />
But sorta periodic trigger buffer sampling display might work. Anyways.<br />
Oscilloscope on BBB might be a fun idea but I need to work on the GSoC project for now!Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-76487407861370639042013-08-01T12:57:00.001-07:002013-08-01T12:57:11.775-07:00Triggering the IIO ADC driver using a GPIO surveyIn continuous mode, the ADC driver can be triggered using a GPIO.<br />
<br />
(For details on continuous mode: <a href="http://beagleboard-gsoc13.blogspot.co.uk/2013/07/sampling-analogue-signals-using-adc-on.html">http://beagleboard-gsoc13.blogspot.co.uk/2013/07/sampling-analogue-signals-using-adc-on.html</a>)<br />
<br />
GPIO numbering on the BBB can be a bit tricky due to the multiple banks.<br />
If you don't know what I'm talking about, see<br />
<a href="http://www.armhf.com/index.php/using-beaglebone-black-gpios/">http://www.armhf.com/index.php/using-beaglebone-black-gpios/</a><br />
<br />
Now that we know which GPIO to use for triggering your ADC, we try to look at how to connect the gpio to the IIO driver.<br />
<br />
As usual, the IIO subsystem is cryptic. Diving deep into IIO code is very tricky. I'm not that good yet I guess.<br />
<br />
I've asked on the iio list. Could be something really simple i'm missing.. <br />
Have tried googling for a couple of hours.<br />
<br />Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com3tag:blogger.com,1999:blog-6838064452269076726.post-55920703573935196472013-07-27T15:19:00.003-07:002014-06-21T03:34:19.668-07:00Sampling analogue signals using the ADC on the Beaglebone BlackNOTE: THIS CODE IS OLD. TRIGGER HAS NOT BEEN IMPLEMENTED IN THE IIO DRIVER ANYMORE. FOR RUNNING THE LATEST IIO DRIVER, you have to modify generic_buffer.c and remove trigger checks.<br />
06-Jun-2014<br />
<br />
<br />
<br />
7 channels of the ADC are available on the expansion port of the Beaglebone Black. Accessing them can seem like a daunting task at first but it is quite simple once you get the hang of it.<br />
<br />
The kernel that ships with the BBB as of 27 July doesn't support the stuff below. So compile one from the latest sources available at <br />
<a href="https://github.com/beagleboard/kernel/tree/3.8">https://github.com/beagleboard/kernel/tree/3.8</a>. <br />
<br />
If you don't know how to compile the latest kernel sources, check the following links for help on how to compile the kernel.<br />
<br />
<a href="http://beagleboard.org/linux">http://beagleboard.org/linux</a><br />
<br />
<a href="http://wiki.beyondlogic.org/index.php/BeagleBoneBlack_Building_Kernel#Compiling_the_BeagleBone_Black_Kernel_2">http://wiki.beyondlogic.org/index.php/BeagleBoneBlack_Building_Kernel#Compiling_the_BeagleBone_Black_Kernel_2</a><br />
<br />
<a href="http://eewiki.net/display/linuxonarm/BeagleBone+Black">http://eewiki.net/display/linuxonarm/BeagleBone+Black</a><br />
<br />
<br />
After booting the BBB, you have to configure the ADC pins and enable the Touchscreen/ADC (TSADC) module in the processor. This is done via the device tree(DT) files.<br />
<br />
DT is a standard format since kernel 3.8 that tells the kernel what it needs to do to enable the TSADC module and configure the ADC pins.<br />
<br />
Thanks to the great people at BB.org, you only need to do this<br />
<pre><code> </code></pre>
<pre><code> echo BB-ADC > </code>/sys/devices/bone_capemgr.*/slots</pre>
<br />
Check that it loaded correctly using <code>dmesg</code><br />
You can also list the current configured peripherals using <br />
<br />
<pre><code> </code><code>cat </code>/sys/devices/bone_capemgr.*/slots</pre>
<br />
<br />
Now checking the analogue value at one instant is simple<br />
All you need to do is type the following<br />
<br />
<pre><code> </code><code>cat /sys/bus/iio/iio:deviceX/in_voltageY</code><code>_raw</code></pre>
<br />
where X is your adc device number and usually 0.<br />
And Y is your analogue channel number.<br />
<br />
Some people might be happy with one sample every once in a while in their applications.<br />
<br />
However, the ADC is capable of much more. If you need to sample a signal continuously via a C/C++ application from the userspace, you are in luck.<br />
<br />
The am335x driver is a standard IIO driver. And the IIO subsystem provides a sample test application to test the driver. Or in our case, to read from the driver.<br />
<br />
The test application can be found in your kernel sources in the drivers/staging/iio/Documentation directory titled generic_buffer.c<br />
<br />
Or if you want to take the easy route, check the following link for sources.<br />
<br />
<a href="https://github.com/ZubairLK/adc-iio-continuous-sampling-userspace">https://github.com/ZubairLK/adc-iio-continuous-sampling-userspace</a><br />
<br />
There are two parts to continuous sampling.<br />
Configuring the ADC and the buffer.<br />
Triggering the driver to tell it when to start filling in the buffer.<br />
<br />
The IIO subsystem supports a trigger mechanism which is separate from the main ADC driver. The ADC driver supports any standard IIO trigger. And IIO provides trigger files which enable triggering via GPIOs or sysfs files.<br />
<br />
Here I'll explain the sysfs way of doing things.<br />
<br />
To add a sysfs trigger file type the following<br />
<br />
<pre><code> </code><code>echo 1 > /sys/bus/iio/iio_sysfs_trigger/add_trigger</code><code></code></pre>
<br />
this creates a trigger directory in <br />
<br />
<br />
<pre><code> </code><code>/sys/bus/iio/trigger0</code></pre>
<br />
Note: If you dont see this directory. You don't have a supported kernel. Compile the one using the latest sources.<br />
<br />
<br />
Running the following pulses the trigger.<br />
<br />
<code></code><br />
<pre><code> </code><code>echo 1 > </code><code>/sys/bus/iio/trigger0/trigger_now</code></pre>
<code> </code><br />
The trigger alone is useless. We need to connect this trigger to the adc driver.<br />
<br />
Compile generic_buffer.c from the above github repo.<br />
<br />
Then run the file using the following parameters<br />
<br />
<pre><code> </code><code></code><code>./generic_buffer -n TI-am335x-adc -t sysfstrig1 -l 128</code></pre>
<code> </code><br />
The application searches for an IIO driver named 'TI-am335x-adc'.<br />
Connects the trigger named "sysfstrig1" to the driver.<br />
And configures the buffer size for 128 samples.<br />
<br />
You might have noticed that you haven't exactly specified which channel you wish to sample. That is enabled separately via sysfs.<br />
<br />
All this might seem confusing at first. But the IIO subsystem is designed to be highly configurable and adaptable to accommodate a variety of peripherals such as accelerometers, gyros, adcs etc.<br />
<br />
Enabling which channel to sample using the triggered buffer mechanism is as simple as <br />
<br />
<pre><code> </code><code></code><code>echo 1 > /sys/bus/iio/iio:deviceX/scan_elements/in_voltageX_en </code></pre>
<code><br /></code>
Where X is the channel number.<br />
<br />
If you wish to enable another channel. Go ahead. The generic_buffer application will list both channels. Just note that the buffer is common for both channels.<br />
<br />
e.g. 128 will result in 64 samples of 2 channels.<br />
<br />
generic_buffer.c is just a starting point for your userspace application.<br />
To sum up, you need to run the following to read continuously from the ADC.<br />
<br />
<code></code><br />
<pre><code> </code>echo 1 > /sys/bus/iio/devices/iio_sysfs_trigger/add_trigger</pre>
<pre><code> </code><code></code><code>echo 1 > /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage7_en</code></pre>
<pre><code> </code><code></code>echo 1 > /sys/bus/iio/devices/iio\:device0/scan_elements/in_voltage5_en</pre>
<pre><code> </code><code></code><code>/home/root/main -n TI-am335x-adc -t sysfstrig1 -l 128 </code></pre>
<br />
And then run this in another terminal to trigger the driver to start sampling<br />
<br />
<pre><code> </code><code></code><code>echo 1 > </code><code>/sys/bus/iio/trigger0/trigger_now</code> </pre>
<br />
The generic_buffer application will display the length of samples.<br />
<br />
Enjoy hacking with the BBB.<br />
Leave a comment if you have a question or notice a bug somewhere.Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com38tag:blogger.com,1999:blog-6838064452269076726.post-30638521439950168322013-07-27T04:17:00.000-07:002013-07-27T04:17:02.475-07:00Fixes accepted and upstreamed. Continuous mode Upstream effort Round 3The fixes I sent upstream were accepted! :)<br />
<br />
So now the adc driver will have correct one-shot adc reading since 3.11-rc3.<br />
<br />
Greg KH has a way with patches. This space is wrong. Fix.<br />
And he'll stop reviewing the thing! lol.<br />
<br />
Thankfully I'm getting comfortable with git rebase.<br />
Fix and resend.<br />
<br />
GregKH This indent is wrong. Fix.<br />
Fix and resend.<br />
<br />
A dozen exchanges like this came the much awaited.<br />
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org><br />
And then<br />
Signed-off-by: Russ Dill <russ.dill@ti.com><br />
<br />
Finally! <br />
<br />
I have sent the patch upstream<br />
<a href="http://thread.gmane.org/gmane.linux.kernel.input/31272">http://thread.gmane.org/gmane.linux.kernel.input/31272</a><br />
<br />
Lets see what IIO has to say about it. I'm kinda happy with the driver now. It wasn't good previously.<br />
The only intricate thing in my mind is the way I used IIO triggers.<br />Triggers are meant to be used for acquiring one sample. I used the iio trigger to acquire a buffer of samples. Who knows. Maybe they aren't solely for acquiring one sample and its my misjudgment. I couldn't find from the wikis..<br />
<br />
Lets see<br />
<br />
ZubairLKAnonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-65646178125800827012013-07-20T09:44:00.000-07:002013-07-20T09:44:03.706-07:00Upstream effort 2After greg kh pointed out some really newbie mistakes, I redid the patches.<br />
<br />
1 - messed up authorship. patches seemed as if I authored them.<br />
<br />
Corrected with. git commit --author "orig author <br />
<br />
2- code formatting issues were handled at the end by 3 patches.<br />
totally non-standard practice. each patch has to have correct formatting.<br />
redid the entire series.<br />
<br />
Also, squashed some patches together.<br />
Learned git rebase in the process which is really powerfulllllll. <br />
<br />
I resubmitted the patch series <br />
<br />
<a href="http://thread.gmane.org/gmane.linux.kernel/1527809">http://thread.gmane.org/gmane.linux.kernel/1527809</a><br />
<br />
Feedback has been cool. Jonathan(King of IIO) pointed out that part of the patch series is a fix. The ones that fixed the first sample read issue by adding a timeout in sampling.<br />
<br />
He wanted to separate the patch series into fix and feature..<br />
<br />
I just did the fix part. <a href="http://thread.gmane.org/gmane.linux.kernel.iio/8326">http://thread.gmane.org/gmane.linux.kernel.iio/8326</a><br />
<br />
Now. The feature part is tricky. While working on continuous mode, I realized that its one big patch. Then a number of bug fixes. Whats the point. I did squash some bug fixes in the big patch. but left out some bug fixes too..<br />
to maintain git history.<br />
<br />
Jonathan asked to squash the rest of the bug fixes in too.. Lars-Peter acked that as well.<br />
<br />
It'll basically reduce the patch series to around 3 i think.<br />
1 for tsc tweaks related to shared irq.<br />
1 for mfd tweaks maybe.<br />
1 big one for the adc driver.<br />
n voila.<br />
<br />Jonathan also pointed out that the show mode and set mode are redundant as the buffer enabled bit can be used. wow. I was impressed. one look and he removed a bunch of code in the driver because it is there in the subsystem already. just check a boolean!!<br />
<br />
he wanted some comments about irqs that i have to look into. i didnt know the answer directly lol.<br />
<br />
this upstream thing is tricky stuff!<br />
<br />
In any case, I have one ack which at least fixes the adc for one-shot mode in the mainline!<br />
now for continuous mode.. I wanted to fix the triggers too. Lets see..<br />
<br />
ZubairLKAnonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-40771411213858144142013-07-17T10:48:00.001-07:002013-07-17T10:48:17.238-07:00Upstream effort part 1I'm not expecting the mainline to welcome all the patches with open arms :p<br />
<br />But let the bashing begin. :) <br />
<br />
Upstreaming continuous support for the ADC drivers for the BBB.<br />
<br />
http://thread.gmane.org/gmane.linux.kernel.iio/8197Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-717794659505011412013-07-15T14:53:00.000-07:002013-07-15T14:53:22.386-07:00Project videoA bit late. but better late than never :)<br />
<br />
I liked the idea of two narrating robotic voices from a youtube video once. the cooler software xtranormal is being shutdown. But this goanimate website is cool stuff too.<br />
<br />
Exporting the video to youtube costs money lol. i'll pay the fee if it passes bb.org and is needed on youtube. Their own online player is pretty cool. Should be sufficient.<br />
<br />
<br />
<a href="http://goanimate.com/videos/0HlsnXKhbIHA?utm_source=embed&uid=0HtFlkRZ1qzk" target="_blank">gsoc project video beagleboard</a> by <a href="http://goanimate.com/user/0HtFlkRZ1qzk" target="_blank">ZubairLK</a> on <a href="http://goanimate.com/?utm_source=embed" target="_blank">GoAnimate</a><br />
<iframe allowtransparency="true" frameborder="0" height="258" scrolling="no" src="http://goanimate.com/player/embed/0HlsnXKhbIHA" width="400"></iframe>Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-38172723838288648572013-07-14T03:04:00.000-07:002013-07-28T06:55:30.870-07:00Continuous sampling mode for ADC driver for BBB. Kernel 3.10!EDIT. THIS IS AN OLD POST.<br />
READ THIS FOR UPDATED INFORMATION<br />
<a href="http://beagleboard-gsoc13.blogspot.com/2013/07/sampling-analogue-signals-using-adc-on.html">http://beagleboard-gsoc13.blogspot.com/2013/07/sampling-analogue-signals-using-adc-on.html</a> <br />
<br />
<br />
Finally got it to work!<br />
<br />
That was a rather large pain. And I'm not sure how it will be received by the mainline folk either. <br />
<br />
Basically the 3.2 based tree by TI had patched their am335x driver for continuous sampling. However, iio had changed quite a bit from 3.2 till 3.10.<br />
<br />
Forward porting all changes meant going through everything and checking the latest stable drivers to see what the difference was. The differences were minor. But there nonetheless..<br />
<br />
And this is a rather large changeset! I was concerned that the patch was becoming rather huge. But then. It is a rather large feature. So can't do this in small increments.<br />
<br />
The first patch adds continuous sampling and some fixes to it all bundled together. The original author is Patil Rachna. I kept the bug fixes later on by Russ dill as separate patches. <br />
<br />
Thank-fully the driver was there and I was only reworking it. Going through the TRM helped a bit in understanding the flow a bit. But I didn't have to make it from scratch which would have been an even bigger pain. Especially as the TRM can be very cryptic..<br />
<br />
Patches available at<br />
<br />
<a href="https://github.com/ZubairLK/kernel/tree/3.11/patches/adc">https://github.com/ZubairLK/kernel/tree/3.11/patches/adc</a>Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-21313437574222626862013-07-07T15:00:00.000-07:002013-07-07T15:00:06.908-07:00Ring Buffer issuesAccess to the ADC using the /dev/iio entries is supported on the kernel side by implementing buffers.. /dev/iio is basically used for continuous sampling.<br />
<br />
One-shot sampling is implemented via the sysfs interfaces. One-shot is up and running. So now I turned my attention to continuous sampling.<br />
<br />
TI has implemented it for 3.2 in the following commit.<br />
<a href="http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=b332370651a7d64d3c6ed8780d939fc18163e141;hp=09597d7a244a8e6f5ea79da3c5dced3a5ea620c4">http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=b332370651a7d64d3c6ed8780d939fc18163e141;hp=09597d7a244a8e6f5ea79da3c5dced3a5ea620c4</a><br />
<br />
I went through it manually and applied all the changes to my adc file.<br />
<br />
However..<br />
<br />
I found out that it was a big time waste. The underlying buffer being used by the driver in the 3.2 based tree was implemented in ring_sw.c<br />
<br />
This buffer was depreciated and none of the drivers use it any more! <br />The linux kernel has moved on to another kfifo based implementation or something.<br />
<br />
This patch is might require some really nitty gritty work.. Or it might just be a few carefully chosen lines to replace..Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-50620330418718559852013-07-07T14:46:00.002-07:002013-07-07T14:46:32.251-07:00Uboot tftpboot notes<br />
https://gist.github.com/17twenty/2718613 Good stuff on automating tftp boot.<br />
<br />
uenv to boot from the kernel on my laptop<br />
<br />
optargs=quiet drm.debug=7<br />
<br />
ipaddr=192.168.0.250 <br />
serverip=192.168.0.1<br />
#run tftpboot 0x80200000 uImage<br />
#uenvcmd=run loaduimage run loadfdt run mmcargs bootz 0x802800000 - 0x80F80000<br />
<br />
bootargs=console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait<br />
uenvcmd=echo "Booting from Network";tftpboot 0x80200000 uImage; bootm 0x80200000Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-86397753601342696292013-07-05T17:41:00.001-07:002013-07-14T10:09:04.442-07:00Pull requestsTook a while to get git up and running the way i wanted.<br />
It can have a steep learning curve!<br />
<br />
And we have pull requests<br />
https://github.com/beagleboard/kernel/pull/48 for the 3.8 tree<br />
https://github.com/beagleboard/kernel/pull/47 for the 3.11 tree<br />
<br />
Time to chill for the weekend!<br />
:)<br />
<br />
Update. They've been merged. Yeaaaaaaaaaaa :) Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0tag:blogger.com,1999:blog-6838064452269076726.post-42685684136535821452013-07-05T15:59:00.002-07:002013-07-05T15:59:55.350-07:004 wire resistive touchscreen HW emulator<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhyZcYNywFOwYnkGIHlAW-IZ8d0sjxBEhceXRLPAKPx4RlZWUs0cqeqMx3WKkX_L9h2wm5wT5WFE-2oFloRRl8yXBVOD9ALOT-92HKPy_Hu1lbsxEj-xRqgynDBTcPEhjJPNhuZLgSGW_k2/s1600/13+-+1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="360" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhyZcYNywFOwYnkGIHlAW-IZ8d0sjxBEhceXRLPAKPx4RlZWUs0cqeqMx3WKkX_L9h2wm5wT5WFE-2oFloRRl8yXBVOD9ALOT-92HKPy_Hu1lbsxEj-xRqgynDBTcPEhjJPNhuZLgSGW_k2/s640/13+-+1.jpg" width="640" /></a></div>
<br />
While the TSC is on its way, I couldn't just move on with tinkering the ADC drivers without knowing if I've accidentally broken the TSC ones.<br />
<br />
So here comes the hardware 4 wire touchscreen emulator!<br />
<br />Folks at #beagle-gsoc were pretty helpful in guiding me on how to test the TSC without the TSC.<br />
<br />
"evtest /dev/input/touchscreen0 " runs a great utility detecting touchscreen input.<br />
<br />
And the hardware is just resistors/potentiometers.<br />
<br />
I googled and after a while. This is what I could come up with. Note : Dont use 100K ohm resistors. I tried. It doesnt work. :p<br />
These are in the range of 10K ohms.<br />
<br />
The circuit is kinda like.<br />
<br />
AIN0 --- Pot1 Pot4 ---AIN2<br />
| |<br />
Pot 3<br />
|<br />
Button<br />
| |<br />
AIN1 --- Pot2 Pot5--- AIN3<br />
<br />
<br />
evtest gives great output. pot 3 controls the pressure value.<br />
pot 1/2/4/5 control X/Y coordinates. <br />
<br />
So.<br />
Who needs a touchscreen when you have potentiometers! :)Anonymoushttp://www.blogger.com/profile/06742416523901835791noreply@blogger.com0