Jump to content

Recommended Posts

Posted

If you are asking for kernel 3.4.x than it's confirmed working. You have to check .fex configuration if it's enabled and wire properly. spi module is enabled by default.

 

For 4.x I haven't try yet ... 

Posted

I've 3.4.x

 

Could you give me a example in C or better for me in python?

I'm trying with a MCP23S17 but for the moment....nothing...

 

Thx

Posted

This file is in every kernel source.

 

Wrote on mobile phone

Posted
I progress...but....This code works with Linksprite OS (ubuntu12.11) but not here.
root@pcduino3nano:~/SPI/Pcduino_SPI# python3 Pcduino_SPI_example.py 


SPI device: /dev/spidev0.0
SPI speed: 12000000
SPI bits per word: 8
IOC_MESSAGE:  1075866368
IOC_TRANSFER:  b'h\x9e\x98\xb6\x00\x00\x00\x00\x88\x97\x92\xb6\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'


Traceback (most recent call last):
  File "Pcduino_SPI_example.py", line 32, in <module>
    test(IODIRB, 0b00000000)
  File "Pcduino_SPI_example.py", line 27, in test
    spi.transfer([OPCODEW], 0)
  File "/root/SPI/Pcduino_SPI/Pcduino_SPI.py", line 497, in transfer
    fcntl.ioctl(self.handle, self._IOC_MESSAGE, spi_ioc_transfer)
OSError: [Errno 22] Invalid argument
 
Maybe the problem is here?
The pin mode with LS OS :
   10 : 1
   11 : 2
   12 : 0
   13 : 2
 
With your's 'in' ou 'out':
   10 : out
   11 : in
   12 : in
   13 : in
 
I can send my python code if you want.
 
Thx a lot

 

 

EDIT :

With spi_test.c

 

With LinkSprite Ubuntu 12.11 ('00 00 00' because nothing between MISO and MOSI)

ubuntu@ubuntu:~/SPI$ ./spidev_test
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 

With Armbian 

root@pcduino3nano:~/SPI/Pcduino_SPI# ./spidev_test
spi mode: 0
bits per word: 8
max speed: 500000 Hz (500 KHz)
can't send spi message: Invalid argument
Aborted


EDIT2 : 

 

If I change spidev.h and add 1 line, the spidev_test.c is ok (but not my python :angry: )

BUT...if I add this line in LinkSprite Ubuntu12 the test fails !!!

 

Anybody have an answer ????

/usr/include/linux/spi/spidev.h

the struct in there is already written as you proposed:

struct spi_ioc_transfer {
        __u64           tx_buf;
        __u64           rx_buf;

        __u32           len;
        __u32           speed_hz;


        __u16           delay_usecs;
 add -> __u16           interbyte_usecs;
        __u8            bits_per_word;
        __u8            cs_change;
        __u32           pad;

        /* If the contents of 'struct spi_ioc_transfer' ever change
         * incompatibly, then the ioctl number (currently 0) must change;
         * ioctls with constant size fields get a bit more in the way of
         * error checking than ones (like this) where that field varies.
         *
         * NOTE: struct layout is the same in 64bit and 32bit userspace.
         */
};
Posted

Hi Igor,

 

Maybe I did'nt understand the configuration.

 

For kernel 3.4.x., BY DEFAULT .fex, .dts and linux-sun7i-default.config are already configured and SPI works OR I must change anything?

 

Thx

 

Posted

For kernel 3.4.x., BY DEFAULT .fex, .dts and linux-sun7i-default.config are already configured and SPI works OR I must change anything?

 

For 3.4 only fex/script.bin matters (and maybe kernel configuration but since we're using the same for all A20 devices and SPI is known to work this should already be ok). So the best idea is to do a diff between the fex file used by the linksprite image (use bin2fex if it's only available as script.bin) and our fex.

Posted

Hi tkaiser,

 

Thx for your answer. the fex file are the same (for SPI conf).

 

The problem could be in the linksprite kernel : 3.4.079 and your's : 3.4.110?

Posted

Thx for your answer. the fex file are the same (for SPI conf). [...] 3.4.079 and your's : 3.4.110?

 

Only comparing the SPI section might not be enough since pins might be used in a conflicting manner in other sections. And regarding different kernel versions. The version shouldn't be the problem but if they adjusted some SPI related stuff in the kernel sources that we do not have then...

 

Did you had a look into their kernel Github repo? I would suspect not since at least for their latest pcDuino they moronically refrain from publishing sources and play the GPL violator game.

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines