SPI access using extender - Printable Version +- Hilscher Community Forum (https://forum.hilscher.com) +-- Forum: netPI 3 - Docker featuring Industrial Raspberry Pi 3 platform (https://forum.hilscher.com/forum-1.html) +--- Forum: Hardware (https://forum.hilscher.com/forum-4.html) +--- Thread: SPI access using extender (/thread-546.html) |
SPI access using extender - Irina Grinberg - January-16th-2020 Hi, My name is Ira and I work at CoreTigo. Currently working with the netPI I would like to test SPI functionality. Using the extender it seems I can only access /dev/spidev1.0 and /dev/spidev1.1, but I can't add these interfaces when creating a new container. Please advise on how can I access SPI interface using the extender. Thanks, Ira Grinberg. RE: SPI access using extender - Armin@netPI - January-16th-2020 Hello Irina, before you start to develop a NPIX extender you need to understand the principle of the standard Raspberry Pi system and the plug-on modules called HAT. https://www.raspberrypi.org/blog/introducing-raspberry-pi-hats/ What HAT is for standard Raspberry Pi is NPIX for netPI to extend the basic hardware with extended hardware. So on a standard Pi you apply a HAT on the 40 pin header and with netPI you shift in NPIX modules. HAT 40 pin header is the same as netPI's internal mPCIe connector ... it is just a different form factor. So since we use the same mechanism with netPI as known from standard PI also the software behaviour is the same. Since HAT/NPIX may provide any connectivity like SPI, I2C, UART etc. the module "tells" the Linux system about its supported interfaces. This is done with the ID EEPROM that is located on the HAT/NPIX at I2C0 bus. If there is no EEPROM Linux cannot detect the possibilities of the module and does not load the respective driver. And this is your problem. Linux during the startup phase reads out the ID EEPROM ... which in your case is not there ... and will not load the SPI driver. This is why you do not see the SPI devices mappable at all. Here is the spec how to generate an ID EEPROM binary file in general for HAT + the tools: https://github.com/raspberrypi/hats We have for example made the NPIX-CAN module that uses the SPI1.0 interface provided by the NPIX slot to connect to the MCP2515 CAN chip. I could provide you the binary file for the ID EEPROM ... so that you in turn can burn your ID EEPROM to get fast to the missing SPI 1.0 device in Linux and finally in your container. For burning ID EEPROMS you need to use EEPROM writer for series production or for tests you can also use netPI with a different SD card loaded with Raspbian OS. Thx Armin RE: SPI access using extender - Irina Grinberg - January-16th-2020 Hi Armin, Thank you for the fast reply. Just to make sure we're on the same page, the extender (breakout) I'm referring to is attached as a file. Also, I have an issue exposing /dev/ttyS0 using the container, which is usually accessible when using a regular Pi. RE: SPI access using extender - Armin@netPI - January-16th-2020 Hi there. I do not see an attachment in your last post. When I speak about the "NPIX module technique" I mean modules that fit in breakout at the bottom of a netPI device where module such das the CAN module https://www.hilscher.com/products/product-groups/industrial-internet-industry-40/netiot-edge/3004/ can be shifted in. The description of those modules you find at https://www.netiot.com/netpi/industrial-raspberry-pi-3/ in the download section. So do we speak about the same interface? With the /dev/ttyS0 I disagree on a standard raspberry pi. All interfaces on a standard Pi can only be activated using the "raspi-config" tool. By default neither I2C, nor SPI, nor UART nor SSH is actviated. If you see /dev/ttyS0 active then you must have activated it with the raspi-config before. Look here are the devices on my Raspberry Pi 3B: Code: autofs gpiochip1 loop7 ppp ram6 tty1 tty23 tty37 tty50 tty7 vcs3 vcsu3 there isn't any /dev/ttyS0 active. RE: SPI access using extender - Armin@netPI - January-16th-2020 One remark: If you would use netPI during your first tests with the original Raspbian OS image (with antoher SD card you insert into netPI's SD card slot) instead of the secured netPI image then you have much more options to enable SPI, TTY and so on using netx to "raspi-config" tool also the config.txt file as described here https://www.raspberrypi.org/documentation/configuration/config-txt/ For example to enable the /ttyS0 interface you have to add the Code: enable_uart=1 entry in the confix.txt file. The config.txt file serve to statically configure the Linux device tree ... while the ID EEPROM is made for flexible and dynamic use without the need to make edits in config.txt by any user. It is adjusting the Linux hardware device tree automatically. RE: SPI access using extender - Irina Grinberg - January-16th-2020 Added the attachment of the breakout board again. I also found it on your site - https://www.hilscher.com/products/product-groups/industrial-internet-industry-40/netiot-edge/3003/? You are correct, I did enable the UART and SPI modules in the Raspbarry Pi configurations. I am using this NetPi - https://www.hilscher.com/products/product-groups/industrial-internet-industry-40/netiot-edge/niot-e-npi3-51-en-reecs/? Does it support a Raspbian OS image? I see it doesn't have an SD card slot. Thanks, Irina. RE: SPI access using extender - Armin@netPI - January-16th-2020 You are doing well. The evalboard you are referencing "opens" you the NPIX slot's mPCIe socket signals to pin headers and of course you can use it for your tests. But nevertheless you should not forget how the overall Raspberry chip/Linux OS behaviour is working in principle with this slot in accordance to the HAT specification. I agree that netPI does not have an SD card slot you can access to immediately. This is because of security reasons that noone can remove the SD card during runtime. You have to unscrew the 4 housing retaining screws. By removing the housing upper part you get access to the SD card slot. Please keep the existing SD card safe and use your own SD card with Raspbian OS. And yes this netPI hardware uses 100% the same schematics as the RPi 3B. So any image/SD card made for original Pi will run in this device 1:1. Thx RE: SPI access using extender - Irina Grinberg - January-16th-2020 Hi Armin, I opened the box and unfortunately there is no way to remove the existing SD card (it's glued completely in this version of the product). Is there any way to enable SPI and UART in the constraints of the secured netPI image? Thanks, Irina. RE: SPI access using extender - Armin@netPI - January-16th-2020 Well Irina, you have an "old" device. Since January 2019 the SD card is no longer sealed on netPI and open to everybody. In the first stages of the netPI product year 2017/2018 we had the idea to make it as secure as possible which also covers also the physical removement of the SD card. You see a barcode label on your product and in its lower right corner the value "1" which is #REVISION 1 of the hardware. You need a #REVISION 2 of hardware. With #REV1 there is really no chance to make any edits via Linux, config.txt or any other method to enable SPI or UART manually other than ID EEPROM hooked to the extension board. This is the maximum secured Pi device you every can think of. The netPI image is a Linux secure-boot alike signed image that is also bound to the serial number of the Raspberry Pi CPU ... it cannot be changed or opened in terms of software. You need #REV2. |