• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
SPI access using extender
#1
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.
  Reply
#2
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/introdu...y-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
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#3
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.
  Reply
#4
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/produc...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
block            gpiochip2  loop-control        ptmx   ram7     tty10  tty24  tty38  tty51  tty8       vcs4      vcsu4
btrfs-control    gpiomem    mapper              pts    ram8     tty11  tty25  tty39  tty52  tty9       vcs5      vcsu5
bus              hwrng      media0              ram0   ram9     tty12  tty26  tty4   tty53  ttyAMA0    vcs6      vcsu6
cachefiles       initctl    mem                 ram1   random   tty13  tty27  tty40  tty54  ttyprintk  vcsa      vga_arbiter
char             input      memory_bandwidth    ram10  raw      tty14  tty28  tty41  tty55  uhid       vcsa1     vhci
console          kmsg       mmcblk0             ram11  rfkill   tty15  tty29  tty42  tty56  uinput     vcsa2     video10
cpu_dma_latency  log        mmcblk0p1           ram12  serial1  tty16  tty3   tty43  tty57  urandom    vcsa3     video11
cuse             loop0      mmcblk0p2           ram13  shm      tty17  tty30  tty44  tty58  v4l        vcsa4     video12
disk             loop1      mqueue              ram14  snd      tty18  tty31  tty45  tty59  vchiq      vcsa5     watchdog
fb0              loop2      net                 ram15  stderr   tty19  tty32  tty46  tty6   vcio       vcsa6     watchdog0
fd               loop3      network_latency     ram2   stdin    tty2   tty33  tty47  tty60  vc-mem     vcsm-cma  zero
full             loop4      network_throughput  ram3   stdout   tty20  tty34  tty48  tty61  vcs        vcsu
fuse             loop5      null                ram4   tty      tty21  tty35  tty49  tty62  vcs1       vcsu1
gpiochip0        loop6      port                ram5   tty0     tty22  tty36  tty5   tty63  vcs2       vcsu2

there isn't any /dev/ttyS0 active.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#5
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/documentatio...onfig-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.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#6
Added the attachment of the breakout board again.
I also found it on your site -
https://www.hilscher.com/products/produc...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/produc...-en-reecs/?

Does it support a Raspbian OS image? I see it doesn't have an SD card slot.

Thanks,
Irina.


Attached Files Thumbnail(s)
   
  Reply
#7
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
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#8
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.
  Reply
#9
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.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
Photo [SOLVED] netPI Access Problem Rahulsagar 5 209 October-18th-2018, 12:05 PM
Last Post: Armin@netPI
  FRAM access marcel 1 121 March-15th-2018, 05:58 PM
Last Post: Armin@netPI

Forum Jump:


Users browsing this thread: 1 Guest(s)