0

I am trying to initiate a spi communication between an omap processor an sam4l one. I have configured spi protocol and omap is the master. Now what I see is the test data I am sending is correctly reaching on sam4l and I can see the isr is printing that data. Using more printf here and there in isr makes the operation happen and the respective operation happens, but if I remove all printfs I can't see any operation happening. What can be the cause of this anomaly? Is it a usual case of wrong frequency settings or something? If code is needed I will post that too but its big. Thanks

Iharob Al Asimi
  • 52,653
  • 6
  • 59
  • 97
Nikhil Chaubey
  • 1
  • 2
  • 1
    printf() works in an ISR? – Martin James Jan 29 '15 at 18:56
  • It should not be used but it is working. – Nikhil Chaubey Jan 29 '15 at 19:04
  • 1
    Never use printf in isr. More info: http://stackoverflow.com/questions/12704196/c-printf-in-interrupt-handler – Eugene Sh. Jan 29 '15 at 19:05
  • I think if I use printf and the code don't work then its a problem. But here I am removing printf and then its not working. – Nikhil Chaubey Jan 29 '15 at 19:08
  • 1
    `printf` is slow - if your problem is timing related, then maybe your printf's are slowing things down enough that it manages to work. – Katie Jan 29 '15 at 19:17
  • please post the (minimal) interrupt function, as that seems to be where the root of the problem is located. – user3629249 Jan 29 '15 at 20:06
  • on a plain jane SPI interrupt function the following items need addressing: 1) check that the interrupt is from the SPI peripheral. 2) if buffer not full, read one byte else set buffer overrun error indication goto 6 3) save that byte into a 'global' buffer 4) increment the 'global' index into that buffer. 5) if full message received -or- buffer full then set 'global' indication of buffer available 6) clear interrupt available flag 7) exit. Since both the main and the interrupt are handling the same data there needs to be a mutex. also, double buffering would help to avoid lost chars – user3629249 Jan 29 '15 at 20:15

2 Answers2

0

I think you are trying to print message in driver.

As printing message on console with slow down your driver, it may behave slowly and your driver work well.

Use pr_info() for debug and change setting to not come message on console by editing /proc/sys/kernel/printk to 4 4 1 7

-> It will store debug message in buffer.

-> Driver not slow down because of printing message on screen.

-> And you can see it by typing dmesg command later.

Then find orignal problem which may cause error.

Ratnesh69
  • 11
  • 3
0

If a routine works with printf "here and there" and not otherwise, almostcertainly the problem is that there are timing issues. As a trivial example, let's say you write to an SPI flash and then check its content. The flash memory write will take some times, so if you check immediately, the data would not be valid, but if you insert a printf call in between, it may have taken enough time that the read back is now valid.

Richard at ImageCraft
  • 605
  • 3
  • 6