After reading a lot of threads, I am still a little confused about device tree mechanism. Could anyone give me a overview of how it works?
Update device tree on run time is called overlay. It need to create a .dst file and compile it. then put it into a directory.
it will tell kernel turn on the SPI hardware
Set the pin to correct model, so that the signal is available at headers
Then I need to install spidev, which is the driver of SPI in linux
This is my understanding, I would be surprised if it is correct, So please point out where ever I am wrong.
BTW, I have some silly question again:
Some guy mentioned SPI1 is used by HDMI, however, after I went through the BBB_SRM. I merely found Table13. P8 LCD conflict Pin on Pg.87 shows the pin that hdmi uses. SPI1 is on P9, so where do you guys finger out that SPI1 is used by hdmi.
where can I find source of BONESCRIPT, or how do you find where is the source of bonescript.
On BBB_SRM.pdf page 96, the table shows AIN0-AIN3 is on P8, it is different from Table 11 on page 77. is it typo?
I second this request if there is a kind and patient person who’d be willing to spend the time to write a devicetree/pin muxing tutorial for newbies. I’ve spent a week sifting through posts here, reading through all the blog pages, and looking over technical type pages…and something just doesn’t click. I’m not sure I understand enough about what I don’t understand to ask properly directed questions so I’ve sort of come to a halt.
I suspect with the BBB being adopted by more and more people that there will be a lot of folks like me who have never used Linux but are familiar with something an Arduino or PIC board and want to hop right in and start developing their projects. It’s a bit daunting to say the least - the amount of stuff to learn in order to get SPI enabled for instance. I think more and more people are going to be asking the same questions, it’d be awesome to have a good intro tutorial to point to that folks could read - I know I’m ready to put my Arduino on the shelf if I could just start harnessing the BBB and probably lots more people behind me ready to do the same!
IMHO SPI should be removed from the “feature” set for the Beaglebone, Beaglebone Black, and Pandaboard. Even if you manage to configure and build a kernel with SPI support you will find it suffers from random long latencies in the 4-15 mS range running a 1 mS servo loop. I’ve posted real time priority test code that shows the issue with SPIDEV and shows essentially perfect timing if a GPIO output is toggled instead of doing a SPIDEV write, proving the latency is in the SPI device system calls.
The Beagleboard has so far shown the best performance with this test code, but still is not good enough.
I’ve attached the test code here again for your convenience, although the SPIDEV and GPIO names will need to be changed to match your board and kernel, as this is for the Pandaboard.
If anyone can run this test code and get SPIDEV worse case latency below 1.5mS I’d love to know about it and which board and kernel you are using!
Now this performance is almost there and would probably be OK for us. This is on Beaglebone Black, correct?
Thank you so much for running this test code. I’ll endeavor to install this 3.8.13-bone26 kernel and I’ve always preferred a Ubuntu root file system, hopefully I can get this project back on track in a couple of weeks after I return from a much needed vacation.
Its the using spidev results that are the issue, the GPIO bit option was just to “prove” the real-time code was correct enough to not be the problem, and it wasn’t userspace to kernel and back overhead that was causing the long latencies latencies.
To use spidev the test program needs to be edited for the proper /dev/spidevX.Y device name string and launched as: “swave_spidev spi” as root user for realtime priority. The nature of spidev means no actual hardware needs to be connected to the spi pins.
Seeing what kernel version the apparent fix happened might be helpful in also solving the issue on Beaglebone and Pandaboard as well.