Guidance for user mode SPI on Grasshopper 2.6.28.4

9 posts / 0 new
Last post
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I have tried to find help on this by searching the forum but cant find any thread containing all the necessary steps.

To me it seems like there are a lot of skilled users out there that have had success in doing this but the threads often dies without the final solution being presented.

It would be really nice if some one could describe were to do the physical connection, necessary kernel modification, changes to board initialization (setup.c?), and finaly (I guess?) a simple code example to read/write to an spi device.

In my particular case I will try to connect to an LTC2498 - a 16ch 24-bit A/D, but I guess the necessary steps are similar to other devices.

Thanks in advance!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Between http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=64228 and http://www.avrfreaks.net/wiki/index.php/Documentation:Linux/Serial you should be able to configure your kernel. Note that the section in the second link is buried inside code to do with serial ports, it really should be moved in to it's own section :-)

As far as writing code to talk to a spidev device, see the spidev documentation, either in a kernel source tree or http://www.mjmwired.net/kernel/Documentation/spi/spidev

As far as the hardware connections go, connect power, ground, mosi, miso, sclk and a chip select between the AVR32 and your device. Make sure the number of the chip select you choose matches the number of the chip select you put in the spidev device block in setup.c

Any specific questions we'll be more than happy to answer them but google searches like "spidev site:avrfreaks.net" /should/ give you the info you need :-)

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for replying!

I have been googling, believe me... What I would like to have is the "whole picture" condensed on the same spot. A bit like a HowTo.

This is what I believe are the categories needed to be covered, some of them already containing found info:

1. Electrical SPI connection to the Grasshopper board.
1.1 CS pin = PA3 - PA5
1.2 MISO pin = PA0
1.3 MOSI pin = PA1
1.4 CLK pin = PA2

2. Kernel modification to enable SPI.
2.1 run "make linux26-menuconfig" to configure kernel
2.2 Add an * at "Devic drivers -> SPI Support -> User Mode SPI device driver support".
A question here: module or built in, which is to prefer?
2.3 run "make" to build the kernel after changes to board init in setup.c in section 3 is done.

3. Changes to board initialization in setup.c.
3.1 Path to the file setup.c for the Grasshopper?
3.2 See squidgit's links above - Thanks!

4. Example code for user mode SPI access to an SPI device.
4.1?

This far I found out some of the info. If it isn't obvious enough I can mention that I'm a newbie on this...

Please correct me where I'm wrong and also, all help is really appreciated!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

niroma wrote:
Thanks for replying!

I have been googling, believe me... What I would like to have is the "whole picture" condensed on the same spot. A bit like a HowTo.

There's a spot set up, if you could fill it with your experiences we'd appreciate it! http://www.avrfreaks.net/wiki/index.php/Documentation:Linux/SPI
Quote:

1. Electrical SPI connection to the Grasshopper board.
1.1 CS pin = PA3 - PA5
1.2 MISO pin = PA0
1.3 MOSI pin = PA1
1.4 CLK pin = PA2
Well it's the same for any board, but right
Quote:
2. Kernel modification to enable SPI.
2.1 run "make linux26-menuconfig" to configure kernel
2.2 Add an * at "Devic drivers -> SPI Support -> User Mode SPI device driver support".
A question here: module or built in, which is to prefer?
Entirely up to you. Building as a module makes the core image slightly smaller leading to faster boot times but requires you to "modprobe" the spidev module before use.
Quote:
2.3 run "make" to build the kernel after changes to board init in setup.c in section 3 is done.
Right
Quote:
3. Changes to board initialization in setup.c.
3.1 Path to the file setup.c for the Grasshopper?
3.2 See squidgit's links above - Thanks!
Always arch/avr32/boards//setup.c in the kernel source tree
Quote:
4. Example code for user mode SPI access to an SPI device.
4.1?
There are full example codes in Documentation/spi in a kernel source tree (as mentioned in the documentation link above)

Looks like you're doing well! As I say, if you could please document the steps you take to get it working on the SPI page of the wiki it'd be much appreciated. I don't have time to do it myself at this stage, plus as I've done it so many times I'm sure I'd end up leaving out steps which are non-obvious to the newbie :-)

Thanks!
-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, I guess I will struggle with this for a while before I get something useful out of it. If however this thread, with help from you and others, ends up with a working solution I would gladly try to summarize it for the wiki.

The SOC I'm using is "ICnova AP7000 Base" = "Grasshopper" from In-Circuit and I also use Buildroot from their CD image.
It seems like there might be some differences in the source tree due to their adaptions to the board.
One thing is the file setup.c that doesn't seem to exist. Instead, I guess, there is a file spi.c in
project_build_avr32/base/linux-2.6.28.4/arch/avr32/boards/icnova
and the initialization is done in
project_build_avr32/base/linux-2.6.28.4/arch/avr32/boards/icnova/icnova_base.c.
Perhaps this results in In-Circuit sitting on the answers to some of the questions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The following is what I have figured out so far, on my own and with help from others.

1. Electrical SPI connection to the Grasshopper board (and others).
1.1 CS pin = PA3 - PA5
1.2 MISO pin = PA0
1.3 MOSI pin = PA1
1.4 CLK pin = PA2

2. Changes to board initialization in setup.c.
2.1 Path to the file setup.c for the Grasshopper?
Here the source tree from In-Circuit differs from the traditional. Normally this is done in
arch/avr32/boards//setup.c but In-Circuit has for some reason no setup.c. Instead there is a file
project_build_avr32/base/linux-2.6.28.4/arch/avr32/boards/icnova/icnova_base.c
and spi devices are supposed to be added in
project_build_avr32/base/linux-2.6.28.4/arch/avr32/boards/icnova/spi.c
Adding to spi.c does however not seem to work. Instead I have added my device to icnova_base.c. See http://forum.embedded-projects.net/viewtopic.php?id=1271. (Sorry for linking to another forum...)

2.2 What to add? (See also squidgit's links above - Thanks!)
I added the following to icnova_base.c:

//After the last #include
#include 

//then
static struct spi_board_info spi0_board_info[] __initdata = {
	   {
	      .modalias   = "spidev",	//Must be spidev
	      .chip_select   = 0,
	   },
};

//Before "return 0;" in routine "static int __init icnova_init(void)"
at32_add_device_spi(0,spi0_board_info,ARRAY_SIZE(spi0_board_info));

2.3 Some device properties not supported by Atmel spi driver?
Like jesperv (see link above) mentioned the .max_speed_hz must not be set in the device struct.
With .max_speed_hz I get the following in the boot up messages:
atmel_spi atmel_spi.0: Atmel SPI Controller at 0xffe00000 (irq 3)
atmel_spi atmel_spi.0: can't setup spi0.0, status -22
and without it, only the first line.

3. Kernel modification to enable user mode SPI.
3.1 run "make linux26-menuconfig" to configure kernel.
For the ICnova this should be done in the top level folder.

3.2 Add an * at "Devic drivers -> SPI Support -> User Mode SPI device driver support".
The * makes the driver built in to the kernel, which seems easier to me since you won't have to load it later.

3.3 Run "make" to build the kernel (after the changes in section 2 is done). This might be obvious for gurus, but it seems important to issue the "make" command immediately after "make linux26-menuconfig" to get the right things compiled.

4. Example code for user mode SPI access to an SPI device.
4.1 Like squidgit mentioned there is a lot of info in
/project_build_avr32/base/linux-2.6.28.4/Documentation/spi.
There are also some code examples in that folder. I have compiled the spidev_test.c using
..//build_avr32/staging_dir/usr/bin/avr32-linux-gcc spidev_test.c -o spidev_test
and then copied it to /usr/bin on the board.

4.2 To be able to use the SPI device it must have an device file under /dev on the board. This is created manually using:
# mknod /dev/spidev0 c 153 0

4.3 Now spidev_test should be able to run:
# spidev_test -D /dev/spidev0
spi mode: 0
bits per word: 8
max speed: 500000 Hz (500 KHz)
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00 00 00 00 00
00 00
#

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

niroma wrote:
4.2 To be able to use the SPI device it must have an device file under /dev on the board. This is created manually using:
# mknod /dev/spidev0 c 153 0
Did /dev/spidev0.0 node not appear automatically? It should!

Rather than running mknod, does it appear if you run "mdev -s"? If it does it means the grasshopper startup scripts don't correctly install a hotplug handler, if not then I donno, odd..

Thanks!
-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Did /dev/spidev0.0 node not appear automatically? It should!
Nope, it doesn't. In-Circuit on the other forum says in one message "The board doesn't create new device-nodes automaticly." I guess he is right...

Tried mdev:
# mdev -s
-sh: mdev: not found

Looked at busybox configuration using
# make busybox-menuconfig
and mdev is not selected.

One thing I wonder about is the name of the device file. You expected it to be spidev0.0 but the mknod command I found gives it the name spidev0. The first 0 is the bus number and the second is the chipselect according to the spi documentation in the kernel source.
Is it just mdev that has this naming convention, meaning this is free to choose?
The connection to the spi master is the number 153 used in the mknod command, I guess, since
# cat /proc/devices
lists spi at this number, right?

Finally, I thought there should be some hits on
# dmesg | grep spi
but there isn't. Strange?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

niroma wrote:
Quote:
Did /dev/spidev0.0 node not appear automatically? It should!
Nope, it doesn't. In-Circuit on the other forum says in one message "The board doesn't create new device-nodes automaticly." I guess he is right...

Tried mdev:
# mdev -s
-sh: mdev: not found

Ah yeah OK, if there's no hotplug handler then indeed there won't be any automatic device node creation. Seems a little odd that the IC guys don't ship the board with mdev but meh, whatever :-)
Quote:
One thing I wonder about is the name of the device file. You expected it to be spidev0.0 but the mknod command I found gives it the name spidev0. The first 0 is the bus number and the second is the chipselect according to the spi documentation in the kernel source.
Is it just mdev that has this naming convention, meaning this is free to choose?
Right enough. The kernel will request that the device node be called spidevX.Y and mdev rules will abide by this. However the actual in-kernel interface doesn't know anything about the name of the device file, the linkage between the device file and the driver is entirely through the major/minor device numbers. As such you're free to pick which ever text name you choose. The only consideration might be that if one day you do move to a board with mdev (or the new in-kernel solution devtmpfs) the node will be called spidevX.Y and you might like to keep compatibility.
Quote:
Finally, I thought there should be some hits on
# dmesg | grep spi
but there isn't. Strange?
Yeah I would have thought there should be messages from the registration of atmel_spi and the spidev nodes. At a guess then, the grasshopper board has the log level turned down a bit. Try grepping through /proc/kmsg which will always contain all messages of all levels.

-S.