chrisf Posted June 21, 2017 Posted June 21, 2017 13 hours ago, Frostbyte said: I just happened to use it on the RPi3 simply because it was more accessible and easy to install. My sensor is a DHT22. I could try the code in the last link you provided, but I'm afraid that it won't work as it's not designed for the tinkerboard. I had a read on the available ASUS.GPIO code here and here, to see if I can get any hints on how I can modify the pdif2_DHTXXD to work with the tinkerboard, but I just can't understand anything.. I had another look at DHTXXD and it uses another library called pigpiod, which in turn directly access the GPIO registers, so is probably not worth porting to another SoC. I would go the route of using different sensors, like the BMP085 or BMP280, which offer a standard I2C interface instead of a proprietary one that requires bit-banging - which is always a bad idea to do on a non-real-time OS. There is many libraries that work with those sensors and they all use the standard /dev/i2c interfaces. Here's one that supports the Tinkerboard: https://github.com/mattjlewis/diozero 1
TonyMac32 Posted June 21, 2017 Posted June 21, 2017 Oh my, I'm going to have to agree with you on that, I looked up the sensor when I saw it was a 1-wire bus... It's a "special 1-wire bus not compatible with the Dallas 1-wire". Bummer.
Frostbyte Posted June 21, 2017 Posted June 21, 2017 5 hours ago, chrisf said: I had another look at DHTXXD and it uses another library called pigpiod, which in turn directly access the GPIO registers, so is probably not worth porting to another SoC. I would go the route of using different sensors, like the BMP085 or BMP280, which offer a standard I2C interface instead of a proprietary one that requires bit-banging - which is always a bad idea to do on a non-real-time OS. There is many libraries that work with those sensors and they all use the standard /dev/i2c interfaces. Here's one that supports the Tinkerboard: https://github.com/mattjlewis/diozero Incredible find, I may just go get a couple of HTS221 to replace my DHT22 then. I would like however to pose the following questions (excuse my ineptitude, as I'm fairly new to sensors): Since you mentioned that the current adafruit implementation may return garbage if another process takes over the CPU while the sensors are being read, are I2C-based sensors also susceptible to that? From my understanding I2C uses some sort of special bus, but how exactly does this all work out? Does it interface with the kernel to figure out what to do? (instead of talking directly with the GPIO) If it's main purpose is to be hardware-agnostic, in theory it should work for every system that there's kernel support for it, right? In order to use it, do I just plug the necessary cables to designated pins (like 3.3v, GND and Data), and just run a sensor check specifying the GPIO # and the sensor type? (I see that Nagios has a designated check_sensor plugin) I've read that there are some cable-length limitations with I2C, I currently use 1-meter wires, will I face a problem? Do sensors share the bus? Can I use multiple I2C sensors on the same board? Provided I have enough GPIO pins and power to feed them. Thanks in advance. 1
chrisf Posted June 21, 2017 Posted June 21, 2017 Just now, Frostbyte said: Incredible find, I may just go get a couple of HTS221 to replace my DHT22 then. I would like however to pose the following questions (excuse my ineptitude, as I'm fairly new to sensors): Since you mentioned that the current adafruit implementation may return garbage if another process takes over the CPU while the sensors are being read, are I2C-based sensors also susceptible to that? From my understanding I2C uses some sort of special bus, but how exactly does this all work out? Does it interface with the kernel to figure out what to do? (instead of talking directly with the GPIO) If it's main purpose is to be hardware-agnostic, in theory it should work for every system that there's kernel support for it, right? In order to use it, do I just plug the necessary cables to designated pins (like 3.3v, GND and Data), and just run a sensor check specifying the GPIO # and the sensor type? (I see that Nagios has a designated check_sensor plugin) I've read that there are some cable-length limitations with I2C, I currently use 1-meter wires, will I face a problem? Do sensors share the bus? Can I use multiple I2C sensors on the same board? Provided I have enough GPIO pins and power to feed them. Thanks in advance. I2C is not susceptible to timing issues, it's a two wire protocol with and clock and data line (it's also known as TWI) I2C could be done over GPIO, but the Tinkerboard (and every other SoC) has hardware to do the I2C communication independent of the CPU. Most PMIC chips are connected to the SoC by an I2C bus. I2C is designed for communication between chips on a single board though, not for long wire lengths. A metre shouldn't be too bad though, if you don't try high-speed I2C (keep it at 100kHz, not 400) You can use multiple i2C devices on a single bus, provided they have different addresses. The Tinkerboard has two I2C buses on its GPIO header, you'll need the right device tree to enable them. You can also buy I2C multiplexers. For temperature sensors on my old Cubieboard I used a DS2482 which is a 1-wire controller with an I2C interface. Made communication a lot more reliable than using the 1wire GPIO driver. Longer distance would be easier with lower pull-up resisters. 4.7K is typical, 2.2K is probably about as low as you can go 2
Frostbyte Posted June 21, 2017 Posted June 21, 2017 1 hour ago, chrisf said: I2C is not susceptible to timing issues, it's a two wire protocol with and clock and data line (it's also known as TWI) I2C could be done over GPIO, but the Tinkerboard (and every other SoC) has hardware to do the I2C communication independent of the CPU. Most PMIC chips are connected to the SoC by an I2C bus. I2C is designed for communication between chips on a single board though, not for long wire lengths. A metre shouldn't be too bad though, if you don't try high-speed I2C (keep it at 100kHz, not 400) You can use multiple i2C devices on a single bus, provided they have different addresses. The Tinkerboard has two I2C buses on its GPIO header, you'll need the right device tree to enable them. You can also buy I2C multiplexers. For temperature sensors on my old Cubieboard I used a DS2482 which is a 1-wire controller with an I2C interface. Made communication a lot more reliable than using the 1wire GPIO driver. Longer distance would be easier with lower pull-up resisters. 4.7K is typical, 2.2K is probably about as low as you can go These two I2C buses on the Tinkerboard GPIO header that you're speaking about, are these dependent or independent of the CPU? I plan on measuring values once every minute, so I guess I won't need to run it at high speed. Thanks for all the info, it's really been helpful!
TonyMac32 Posted June 21, 2017 Posted June 21, 2017 They are hardware I2C peripherals, so they have buffers/control registers/etc, they are not software implementations that can be disrupted by other tasks. Worst case you overflow a buffer before reading it. 1
TonyMac32 Posted June 26, 2017 Posted June 26, 2017 I have split 2 major support issues into their own threads, Bluetooth and Reboot. I have gotten Bluetooth working on nightly builds of the default kernel, you need to use rtk_hciattach on every boot (add it to startup). Next/dev kernels are still a work in progress. 1
tkaiser Posted June 26, 2017 Posted June 26, 2017 On 12.6.2017 at 4:30 AM, TonyMac32 said: I ran iperf3 just for kicks Can you also provide numbers for the reverse direction please (-R) since all iperf3 results I found on the net are only Tinkerboard --> other device and never vice versa.
TonyMac32 Posted June 27, 2017 Posted June 27, 2017 Kernel 4.4.73 Reverse mode, remote host 10.0.0.15 is sending [ 4] local 10.0.0.52 port 53276 connected to 10.0.0.15 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 109 MBytes 913 Mbits/sec [ 4] 1.00-2.00 sec 110 MBytes 925 Mbits/sec [ 4] 2.00-3.00 sec 109 MBytes 918 Mbits/sec [ 4] 3.00-4.00 sec 109 MBytes 918 Mbits/sec [ 4] 4.00-5.00 sec 110 MBytes 922 Mbits/sec [ 4] 5.00-6.00 sec 111 MBytes 930 Mbits/sec [ 4] 6.00-7.00 sec 111 MBytes 930 Mbits/sec [ 4] 7.00-8.00 sec 111 MBytes 933 Mbits/sec [ 4] 8.00-9.00 sec 111 MBytes 931 Mbits/sec [ 4] 9.00-10.00 sec 111 MBytes 931 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.08 GBytes 927 Mbits/sec 2 sender [ 4] 0.00-10.00 sec 1.08 GBytes 925 Mbits/sec receiver Kernel 4.12 Reverse mode, remote host 10.0.0.15 is sending [ 4] local 10.0.0.49 port 47608 connected to 10.0.0.15 port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 108 MBytes 906 Mbits/sec [ 4] 1.00-2.00 sec 108 MBytes 907 Mbits/sec [ 4] 2.00-3.00 sec 108 MBytes 909 Mbits/sec [ 4] 3.00-4.00 sec 108 MBytes 910 Mbits/sec [ 4] 4.00-5.00 sec 109 MBytes 911 Mbits/sec [ 4] 5.00-6.00 sec 109 MBytes 911 Mbits/sec [ 4] 6.00-7.00 sec 109 MBytes 915 Mbits/sec [ 4] 7.00-8.00 sec 110 MBytes 920 Mbits/sec [ 4] 8.00-9.00 sec 109 MBytes 914 Mbits/sec [ 4] 9.00-10.00 sec 109 MBytes 912 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.06 GBytes 913 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.06 GBytes 912 Mbits/sec receiver
Frostbyte Posted July 7, 2017 Posted July 7, 2017 So, until I get an I2C sensor to play around with; I decided to not let my existing DHT22 to go to waste. I studied the wiringPi library a little bit and came up with my own DHT22 nagios plugin. It can be found here for anyone else interested.
TonyMac32 Posted July 17, 2017 Posted July 17, 2017 As the NEXT image has moved to 4.12, I'll be moving the wireless patch over. Sorry about not catching that sooner, the switch killed compilation due to the Mali driver. There still won't be Bluetooth or reboot fix, I'm afraid...
Myy Posted July 17, 2017 Posted July 17, 2017 I'll take care of the patches this week. I thought that the rc1 would be released today, but it seems to have been released yesterday. I'll incorporate the Mali r18p0 drivers this time, as they have incorporated various patches and are now directly usable with 4.11 kernels, lowering the number of patches required to integrate it with 4.13 kernels ! Yay ! For the reboot fixes, I'll wait until I get more logs from the Tinkering branch, in order to have a clearer understanding of the shutdown process. For the bluetooth fixes, since nobody got it working with the weird Rockchip RFKill thingy, I'll try another way. That said, the main focus with this release will be : The hardware video decoder/encoder chip. RK3288 boards are mostly advertised for their abilities to play videos smoothly, and a lot of tinkerboard owners just want to watch movies on Netflix with it. Trying to start pushing patches to arm-soc . The more patches are integrated into the arm-soc branch, the less we'll have to maintain in the future. And the less, the merrier, when it comes to maintaining patches. Now, this might take a few days to get the first release coming, and the new releases will be done in a new repository that will be splitted in two. One of the kernel build scripts and patches, and one with the actual kernel files. That way, people looking for the builds won't have to download 100M of data and people looking for prebuilt kernels will have a clean repo and releases. 1
lafalken Posted July 17, 2017 Posted July 17, 2017 Sounds great! Would like to see an clean version without desktop too. I would like to use this card as webb server, but is it stable enough for such use? For that I would use a usb-hdd, network cable and power. All other things like wireless is of no use for me. But a reboot that does not work is not very good ;(
Myy Posted July 17, 2017 Posted July 17, 2017 Well, the reboot issue will be a problem if you want some kind of unattended web server that you can upgrade through SSH. If you can unplug / plug the cable back, it will be a hassle, but not a blocker though. Since servers don't reboot that often, and personal servers on personal networks, shielded from the outside, almost never reboot, you might not even face it. Anyway, I don't see any problem in using that board for a test web server, though Tinkerboard owners might be aware of network issues that I don't. Note that you can run : systemctl set-default multi-user.target To boot your system directly in text mode, instead of booting in desktop mode. From there, you might be able to delete desktop packages and keep only the server packages you need. 1
Myy Posted July 18, 2017 Posted July 18, 2017 Ok... turns out that the mainlined rk3288.dtsi references a "job" IRQ that is completely unknown and fail the Mali GPU detection... However, I did it the same way before and it worked. So I don't know what they've added that could fail... Anyway, I've started to do some prep work for my new repositories. The first one is here and contains my new patches : https://github.com/Miouyouyou/RockMyy EDIT : Well my 4.12 DTB file works so it's clearly an issue generated by the new definition... Oh... please... /tmp/RockMyy/linux/drivers/gpu/arm/midgard/mali_kbase_core_linux.c if (!strncmp(irq_res->name, "JOB", 4)) { irqtag = JOB_IRQ_TAG; } else if (!strncmp(irq_res->name, "MMU", 4)) { irqtag = MMU_IRQ_TAG; } else if (!strncmp(irq_res->name, "GPU", 4)) { irqtag = GPU_IRQ_TAG; } else { dev_err(&pdev->dev, "Invalid irq res name: '%s'\n", irq_res->name); return -EINVAL; } I replaced the strncmp calls by strncasecmp and... it works... Well, I'll reassemble the patches, and commit this. 1
Frostbyte Posted July 19, 2017 Posted July 19, 2017 I am aware that this board has severe powering issues when using the USB power connector.. After struggling a lot to find a reliable PSU, I ended up buying the "official" RPi PSU that's supposed to provide 2.5 amps, however I still get a shutdown once every 2.5-3 weeks. (I suspect it's power) Are these patches going to improve this by any chance, or will I forced to craft and use a 3A GPIO PSU? I'm kind of reluctant, because I've heard that there are no fuses/protection in the GPIO and you can easily toast the board that way. The reboot fix will be awesome, however. PS: I'm also coding a nifty little Nagios check for the SHT31-D I2C sensors that just arrived, when my friend takes care soldering the pin headers and making the wires for me, I expect to get it on github soon. 1
TonyMac32 Posted July 23, 2017 Posted July 23, 2017 The next nightly should have the reboot fix on kernel 4.12. Please test and comment.
Igor Posted July 23, 2017 Posted July 23, 2017 6 hours ago, TonyMac32 said: The next nightly should have the reboot fix on kernel 4.12. Please test and comment. NEXT nightly = 4.12.3, updated this morning. https://dl.armbian.com/tinkerboard/Ubuntu_xenial_next_desktop_nightly.7z 3
bedalus Posted July 23, 2017 Posted July 23, 2017 I flashed the file from the download link above: Armbian_5.32.170724_Tinkerboard_Ubuntu_xenial_next_4.12.3_desktop.7z After entering root/1234/etc and getting to the desktop, the first thing I tried was a reboot, and it successfully rebooted back to the desktop. I tried again from the newly rebooted desktop, and success again. 4
Frostbyte Posted July 24, 2017 Posted July 24, 2017 Any clue when we can expect the 4.12.3 kernel to hit the repo? It still has the 4.11.5-rockchip one.
Frostbyte Posted July 24, 2017 Posted July 24, 2017 It doesn't appear to be. I ran apt-get update, upgrade and dist-upgrade and I get the following: root@Tuxbox:~# uname -r 4.11.5-rockchip Perhaps it's not going to reach the repo until it's thoroughly tested?
RickyTerzis Posted July 24, 2017 Posted July 24, 2017 HI...i am a new user here. In my case my board idea is a little closer to my heat sink modification than I like, but if I make a proper board I want to include a USB charge port for powering external HDD's assuming they won't spin up on the USB alone. Supply used: Odroid XU4 5.0 V 4 Amp, I stuck a capacitor on there, will probably include an overvoltage protection diode as well.
TonyMac32 Posted July 24, 2017 Posted July 24, 2017 I've been playing with some board artwork to make a general "Pi-formfactor fixing Hat", I agree that a modified heatsink gets a bit close. I have a 10mm heatsink and think an 8 would be maximum. For a charge port, you'd ideally want to make it a colored port (red I think) so it's obviously for a singular purpose.
bedalus Posted July 25, 2017 Posted July 25, 2017 There's something different about the 4.12.3 kernel, I can use my bluetooth keyboard with it. It's not using the native bluetooth, it's got it's own dedicated dongle. When I tried the stable versions (both legacy and mainline) I couldn't log in, I'm guessing because the drivers aren't enabled in these older kernels. Did the config change in the daily build? Are the commits in the source repo (sorry, this is a passing thought, and I'm at work, so shouldn't really be on here!) Edit: Home from work. I think I found the commit: https://github.com/armbian/build/commit/ffb032449e1063d6f43862a9b2c430d99c54137d but I can't spot what might have been turned on that allowed the bluetooth dongle to function.
TonyMac32 Posted July 26, 2017 Posted July 26, 2017 I can't tell you for sure, to be honest, I haven't done anything with external peripheral drivers. Can you drop me the link that running armbianmonitor -u gives you? My guess is the USB dongle presents a 3-wire HCI device, which I enabled to begin work on the on-board bluetooth.
Recommended Posts