2
\$\begingroup\$

I am using Beagle Bone Black with Arch Linux ARM OS to communicate with ltc-6804 chip via SPI port. I have came to a point that the interrupt from the OS in the middle of sending read command and receiving measured values causing a trouble for me to get a valid measurement from the chip. Is there any way to "protect" the part of the code being interrupted on the run? In the other words, let the send and read section complete without any interruption.

\$\endgroup\$
  • \$\begingroup\$ Move the time-critical code into an OS driver, then you can enable/disable interrupts. \$\endgroup\$ – pjc50 Sep 10 '16 at 11:34
  • \$\begingroup\$ A detail example or reading material/website will be well appreciated. This is my first project dealing with linux. \$\endgroup\$ – danteDev Sep 10 '16 at 12:08
  • \$\begingroup\$ stackoverflow.com/questions/2595735/… perhaps, or more generally shop.oreilly.com/product/0636920030867.do \$\endgroup\$ – pjc50 Sep 10 '16 at 13:41
  • \$\begingroup\$ I am just going to buy that book. I have read the link before posting here, the answer seems like it is not possible to achieve what I want. \$\endgroup\$ – danteDev Sep 10 '16 at 14:25
2
\$\begingroup\$

This is a different approach to your problem, and is not about working within Linux. Instead it is about using other BeagleBone Black resources to solve the problem.

As well as the ARM Corex-A8, the BeagleBone Black also has two more processors, called Programmable Real-Time Unit Subsystem and Industrial Communication Subsystem (PRU-ICSS), often just PRU.

The two PRUs run independently of the ARM running Linux, and so are not affected by Linux scheduling; they won't be interrupted or pre-empted by Linux.

PRUs are intended for real-time processing, and have access to all I/O. They are RISC cores each running at 200MHz, so should be plenty fast enough, and be able to do anything you need. You could dedicate one to your SPI communication task.

They can be programmed in C or assembler. There are several useful articles on the web this one on Hackspace has useful links to key examples and technology. IIRC there are examples showing how to the main 'Linux processor' interacts with a PRU.

Edit:
This is a course on using the PRU.

\$\endgroup\$
  • \$\begingroup\$ This sounds promising, I will go into it. \$\endgroup\$ – danteDev Sep 11 '16 at 1:25
  • \$\begingroup\$ @danteDev - If you search, using terms like BeagleBone and PRU or PRI-ICSS a bunch of useful looking links pop up. The Hackspace article seemed to have a bunch of helpful ones, and a good place to start. The early articles were about using the PRU assembler, which looked doable but arduous. However, when TI released the C compiler, it all seemed much more usable. \$\endgroup\$ – gbulmer Sep 11 '16 at 13:15
1
\$\begingroup\$

You are looking for the wrong solution to the problem. Fix the software properly instead.

SPI is completely synchronous. Since you're the master, you own the clock. With properly designed SPI routines, there should be no harm in interrupt stealing cycles arbitrarily. All that should do is stretch out time between transitions, which should not be a problem.

\$\endgroup\$
  • \$\begingroup\$ The problem is, the slave will fall to sleep mode(5 miliseconds) if the interrupt is taken longer than the timer countdown to sleep mode during the interruption. Is it still the same case? \$\endgroup\$ – danteDev Sep 10 '16 at 11:53
  • \$\begingroup\$ @dant: That's a odd slave if it really goes to sleep after 5 ms with chip select still asserted. 5 ms is a very very long time for a interrupt. Either you have a very badly designed interrupt strategy, or something else is going on. This smells more like a non-real-time operating system stalling one of many processes for a while, not a interrupt taking the horrendously long time of 5 ms. \$\endgroup\$ – Olin Lathrop Sep 10 '16 at 19:54
  • \$\begingroup\$ Yes, there are a lot processes going on, and I will keep adding more processes in the progress. Is that a problem? I didn't touch anything on the "design interrupt" part, so, badly designed interrupt doesn't seems like relevant to user space program, am I right? From user space program, I just send read command and read result from the slave, as simple as that. What is going on in between, I have no idea. Oh, I have to emphasize, this problem happens in a rare occasion, approximately 1 invalid out of 10000 read. I want to find out and solve this problem. \$\endgroup\$ – danteDev Sep 11 '16 at 1:15
1
\$\begingroup\$

No interrupt should be taking 5ms, that is forever....

However, you might be being preempted, in which case you may wish to consider using one of the posix realtime schedulers instead of the default one, see the man pages for sched_setscheduler for details.

This is far more a software question then a hardware one however.

Regards, Dan.

\$\endgroup\$
  • \$\begingroup\$ No kidding, I have observed more than 10ms in occasion but no more than 15ms. Preempt and interrupt are not the same thing? Please direct me to proper link if this is not suitable to be posted here. i will have a read on the "sched_setscheduler" though. \$\endgroup\$ – danteDev Sep 10 '16 at 12:35
0
\$\begingroup\$

If it happens infrequently, set a flag in the interrupt routine that is inspected by the spi read routine. If set then repeat the read operation after clearing said flag.

\$\endgroup\$
  • \$\begingroup\$ Yes, it does happen in a very rare occasion but it is very critical to the realibility of the system. A detail example or reading material/website will be well appreciated. This is my first project dealing with linux. \$\endgroup\$ – danteDev Sep 10 '16 at 12:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.