• Content Count

  • Joined

  • Last visited

About p-i-u.de

  • Rank

Recent Profile Visitors

404 profile views
  1. AFAIK, as that used for the internal SPI Flash ( I got a Rev 1.4 Board), however I can test tomorrow if it works with the default values
  2. I have built the custom kernel with this patch being applied, changed the target path to target-path = "/spi@ff1e0000"; as SPI1 is not usable on rock pi 4, compiled with dtc and moved it to /boot/dtb/rockchip/overlay/rockchip-spidev2-1.dtbo having this in /boot/armbianEnv.txt overlays=spidev2-1 Now when I reboot I get /dev/spidev0.1 So, what wonders me is, a) why does it come up as spidev0 and b) how do I know which gpio pin is used for CS? Otherwise I'm ready to test What do I miss?
  3. actually I meant to get the patch in the upstream kernel sources. I've currently setting up my build environment and will start a build. Will need a few days until I'm done with testing, as I can just use certain timeslice each day to not interfere with my other projects.
  4. I have a device to check,. Hmmmh should we do some advocacy work to get the patch into the mainline Kernel? As from the post to me it seems that has simply just forgotten
  5. to what I understood it seems to be possible https://patchwork.kernel.org/patch/9780471/ if you can tell me what work is to do maybe I can help
  6. Mainly, because I wasn't aware of them plus second I also want to access the gpio without being root and I develop in Java so need some native JNI library. Leaving just User Space IO where I'll have a look at. Actually the MRAA Library developed by Intel first exists since 2015 so it was there before the alternatives, the question should have been why did the others re-invent the wheel :-)
  7. I also plan to add Tinkerboard Support as I got this board, too. However I know what you mean by time constraints which is also a very limiting factor for me. What would you think are the most important boards to add? OrangePi, Odroid?
  8. What do you mean by R&D? Resources and Development? Note: the Github Repo is mine, which means I have done the modifications. Only problem though I'm not a C Coder and could need some help by an experienced C developer here and there
  9. As WiringPi was never meant to support other boards nor does the author like to support other boards and it is officially depreciated now (http://wiringpi.com/wiringpi-deprecated/). I want to ask why not put some efforts into libmraa https://github.com/intel-iot-devkit/mraa and put it into the Armbian repository. I have already a fork which fixes Rock Pi 4 on recent mainline 5.3 kernels with updated debian build scripts here: https://github.com/bootsy52/mraa, so debian packages could be simple built using dpgk-buildpackage. Why I think it is a good idea to supply libmraa with the Armbian repository Supporting multiple boards is a desired goal of the project Supporting a board is really easy, for Rock Pi for example this is just the files src/arm/rockpi4.c include/arm/rockpi4.h and an entry in src/arm/arm.c, that's it Instead of multiple forks of wiringPi and different sources of different versions (or even different gpio implementations) just have one common implementation for all boards with wiringPi you need additional bridges if you want to code in other languages like Java or Python for example, with MRAA you have out of the box bindings for Python, Java, Javascript, C/C++ and NodeJS support What do you think? @Igor
  10. I can confirm latest 5.3.11 buster server Image working fine on RockPI 4A with EMMC. Further more I used CP2102 successfully to connect via putty on serial console of RockPI at 1500000 https://www.amazon.de/Anpro-CP2102-Konverter-Stecker-eingebautem/dp/B0757FQ5CX
  11. Thanx for the tip, I've used what Linus Torvalds used in his spidev_test.c program so I thought that is the correct way (I'm not a C Coder)
  12. That part with AFTER seems an important one, however here comes the sad story short in hope that maybe at least another one who has this specific setup reads this post and finds this helpful. So the reason why i was always getting "Failed to perform SPI transfer": Bad Address had nothing to do with hardware but with the fact that we are on aarch64 on Rock PI and simply the libwidgetlords libraries where obiously not tested under 64bit as they used (uint32_t) instead of (unsigned long) in their code. So everybody who has a RockPI 4 and Pi-SPi-8AI Raspberry Pi Analog Input (4 - 20 mA) Interface follow this to get it to work Note you currently have to use the Armbian DEV branch so that overlays work put this in /boot/armbianEnv.txt (Note I also enabled uart4 as I use this for another device), you cannot use the 40 gpio to 26gpio Ribbon cable as we use SPI2 instead of SPI0 so you have to connect the board using jumper cables. So connect PIN 26 of the 8AI Board to PIN 33 of the RockPI, Pin 19 to 29 on RockPI, Pin 21 to 31 on RockPI and Pin 23 to 7 on RockPI For those of you who wonder how to connect the sensors to this board, using 2 wire sensors INPUT (voltage supply) goes in the V+ Terminal and the Output from the sensor goes into A1 - A8 overlays=spi-spidev uart4 param_spidev_spi_bus=2 Clone the git repository git clone https://github.com/widgetlords/libwidgetlords.git change includes (don't know if that's necessary but these are the ones used in spidev_test.c program by Linus Torvalds) and the following in src/spi.c #include <errno.h> #include <fcntl.h> #include <linux/spi/spidev.h> #include <stdint.h> #include <stdio.h> #include <string.h> #include <sys/ioctl.h> #include <linux/ioctl.h> #include <unistd.h> from this static const char prefix[] = "/dev/spidev0."; spi.tx_buf = (uint32_t)data; spi.rx_buf = (uint32_t)data; to this static const char prefix[] = "/dev/spidev2."; spi.tx_buf = (unsigned long)data; spi.rx_buf = (unsigned long)data; change SPI_8AI to 0 because we use /dev/spidev2.0 not /dev/spidev2.1 include/pi_spi.h #define SPI_8AI 0 Please find also attached a Java Implementation using MRAA to get access to this board (then there is in fact no need anymore for the libwidgetloard libraries at all) pi_spi.h spi.c SensorMRAA.java
  13. Yes, that's what I've done to see if it's active after I got the Input/Output error and it was not there only ttyS0, ttyS2 Regarding SPI, thanx I'll try that above once again, maybe the error lies somewhere else, as i had cabling like that already before but get always "Bad address" however /dev/spidev2.0 is there
  14. I already used jumper cables and tried to exacty do that which also doesn't work, as far as my understanding of the Chip Select = 1 is, that CS = 1 means active high getting to low and CS = 0 being active low, so it seems without spi-add-cs1 overlay I am quite lost on this BTW, could it be that the uart4 overlay is also not yet functioning? as I get Input/Output error on ttyS4
  15. I'm using this board https://widgetlords.com/products/pi-spi-8ai-raspberry-pi-analog-input-interface the Pi-SPi-8AI 4-20 mA Variant, till now I've not found any way to get it working. Do you have any hints how to make the correct overlay or where to start? That is the overlay what they use for Raspberry PI https://github.com/widgetlords/libwidgetlords/blob/master/overlays/pi-spi.dts however I was not able to translate it to rk3399. Note I have an older Variant with 2 Jumpers to select CE1 and 22