Jump to content

vlad59

Members
  • Posts

    180
  • Joined

  • Last visited

Everything posted by vlad59

  1. Hi, I'm not fluent with pyA20 but I worked with DH11/DHT12 (before using onewire, si7201 or bme280 and never getting back) I would remove all PULLUP or PULLDOWN from your code, Looking at the photo you don't use the bare sensor but an all-in-one -> I'm almost sure you already have an embedded pullup (between 1kΩ and 4kΩ so way better than the integrated ones) and you may also have a small decoupling cap as a bonus. Did you try your pin with a simple led to check if you are using the good one ? Back then I had a lot problem with the cpu speed, try to force a higher frequency (that will help all the sleeps to be more accurate) and try to kill all other daemon that you don't need.
  2. The only thing I wanted to change is to set scaling_min_freq to 528000 for consistency. But it won't change a single thing. Anyway thanks a lot for your answer, my curiosity is satisfied .
  3. Hi, No real problem, just a question. I'm using latest Armbian Jessie 5.25 with my good old Banana Pi. root@marvin:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 144000 312000 528000 720000 864000 912000 960000 root@marvin:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq 480000 root@marvin:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 960000 Please notice that 480MHz (the min freq) is not in the available frequencies. So that gives the following output with cpufreq-info : root@marvin:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 244 us. hardware limits: 144 MHz - 960 MHz available frequency steps: 144 MHz, 312 MHz, 528 MHz, 720 MHz, 864 MHz, 912 MHz, 960 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 960 MHz. The governor "schedutil" may decide which speed to use within this range. current CPU frequency is 528 MHz (asserted by call to hardware). cpufreq stats: 144 MHz:0,00%, 312 MHz:0,00%, 528 MHz:98,22%, 720 MHz:1,04%, 864 MHz:0,08%, 912 MHz:0,23%, 960 MHz:0,43% (39367) analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 244 us. hardware limits: 144 MHz - 960 MHz available frequency steps: 144 MHz, 312 MHz, 528 MHz, 720 MHz, 864 MHz, 912 MHz, 960 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance, schedutil current policy: frequency should be within 480 MHz and 960 MHz. The governor "schedutil" may decide which speed to use within this range. current CPU frequency is 528 MHz (asserted by call to hardware). cpufreq stats: 144 MHz:0,00%, 312 MHz:0,00%, 528 MHz:98,22%, 720 MHz:1,04%, 864 MHz:0,08%, 912 MHz:0,23%, 960 MHz:0,43% (39367) Should I set /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq to 528000 or is there a problem with 480MHz not being in available frequencies ? IIRC I had the same problem with the previous kernel (Armbian 5.24), I do not remember if it happened before.
  4. Hi this is latest Armbian on my Banana Pi with a SSD drive : root@marvin:~# uname -a Linux marvin 4.9.5-sunxi #1 SMP Fri Jan 20 22:01:51 CET 2017 armv7l GNU/Linux root@marvin:~# dmesg | grep scsi [ 3.942302] scsi host0: ahci-sunxi [ 4.285757] scsi 0:0:0:0: Direct-Access ATA SanDisk SDSSDA24 00RL PQ: 0 ANSI: 5 [ 4.361854] sd 0:0:0:0: Attached scsi generic sg0 type 0 root@marvin:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 223.6G 0 disk └─sda1 8:1 0 223.6G 0 part / mmcblk0 179:0 0 7.4G 0 disk └─mmcblk0p1 179:1 0 7.3G 0 part /media/mmcboot Everything is working as expected. My power source is a good quality 2A adapter.
  5. Answering questions like that is always tricky but I got a Banana Pi (so A20) running 24/7 with a SSD for more that two years (since July 2014). At first it was with legacy kernel but now it's using vanilla 4.X. it has some I2C sensors directly connected to GPIO, one UART is also used for my Moteino network. No random crash, every restarts was because of me or electrical problems. I'm trying to do the same with H3 but not having real SATA support (so no SSD) is a problem (I have a NFS / DLNA Server on it). Depending on your needs (domotic you said), Nanopi Air could be completely enough.
  6. is that pin already used for something else ?
  7. Exactly, SFTP performance were 2 times better with CESA but both my Dockstars NAND died after running 24/7 for 2 years.
  8. IIRC, a while ago, I made some benchmark with hardware crypto engine on a Dockstar and I was using : openssl speed -elapsed -evp aes-128-cbc the -elapsed was essential for the comparison
  9. Another advice. If you need a good quality sensor (especially for humidity), BME280 is a better choice (with a higher price, I know) and you get a pressure sensor for free. it's also using i2c so easier to handle. If you wish to keep the price low SHT21 can be found around 3€ (Aliexpress) and it's still i2c.
  10. Hi, I'll try to help even if I only own many DHT22 and no DHT21. I have one Banana Pi (basically the same as Lamobo R1) which is reading temperature and humidity (with the DHT22), here is my configuration : * the program used is lol_dht22 on top of WiringBp * the DHT22 is powered with 3.3V (not 5V) * my cables are small (10~15cm) * I have a 4.7K pullup resistor (it was mandatory for me, removing it caused bad CRC almost everytime), I guess you can use resistor from 1K up to 10K with the same effect. * I used it with legacy kernel (3.X) for one year and use it with modern kernel (4.X) for another year and it's still going * my Banana pi is up 24/7 and read value from DHT22 every 15 minutes So my advice : use 3.3V, use a real pullup and make sure there is zero load on your Lamobo when you make the test (to make sure all timings can be handled)
  11. I've advised to change the minimal frequency to an higher value (not lower) : 600MHz instead of 480MHz That's mainly because delayMicroseconds is a busy loop so having an higher frequency will make it more precise. Linux is not a realtime OS so you don't have much choice. Of course if you need 100% reliability, your best choice is to connect your DHT22 to an Arduino and connect your Arduino to your Orange Pi with an UART.
  12. You can try this project for DHT22 : https://github.com/technion/lol_dht22 I made some modifications here : https://github.com/seblucas/lol_dht22and I've been using it for a year and a half on my Banana Pi doing a reading every 15 minutes. So far I loose on average 1 reading per day. You can see here that the program has to wait for specific amount of time. So if you want to use your DHT22 with a lot of reliability, you'll have to keep the CPU load low and maybe tweak your cpufreq settings to set a minimal freq at around 600MHz this should help lowering the errors you see.
  13. I should be receiving 2 nanopi Neo in 3 weeks hopefully. I'll make all the tests needed as soon as received. <off topic>I can confirm that my Nanopi M1 work fine even at 744MHz so no need to lower the DRAM settings for them</off topic>
  14. This was actually easy, I only need the dts directory and the kernel headers (they were already installed) and that's it. The compile script look like that : #!/bin/sh IDE=sun7i-a20-bananapro SRC=$IDE.dts TMP=$IDE.tmp.dts DST=$IDE.dtb cpp -nostdinc -I /usr/src/linux-headers-4.5.2-sunxi/include -undef -x assembler-with-cpp $SRC > $TMP dtc -O dtb -b 0 -o $DST $TMP #rm $TMP I'll check tonight if the DTB I compiled is exactly the same as the one from Armbian. EDIT : An additional interest of having all the DTS files is that you can quickly find the DTB file you're currently using : root@bananapipro:~/test/dts# grep "`cat /proc/device-tree/model`" *.dts sun7i-a20-bananapro.dts: model = "LeMaker Banana Pro";
  15. Thanks for the confirmation. Another quick question, currently I can install the kernel headers (patched Armbian version). Would it be possible to have the complete patched kernel sources through apt.armbian.com ? If that's possible, we could have access to the real DTS file (with comments, unprocessed) and use dtc on them (like shown here). It would make the job easier most of the time and there would be no need to recompile the full kernel. I always find it hard to manually edit decompiled DTB.
  16. Hi I'm currently working on this and while I'm fluent (or at least I hope so) in FEX modification (two commits were merged), DT is newer for me. I'll certainly need some guidance here. My first question is how do you know which DTB file you're currently using. For now my method it to use cat /proc/device-tree/model and try to guess the file in /boot/dtb. It worked, but there's certainly a better method. boot.cmd is using ${fdtfile} so no help here boot.src is compiled so no help there either. Thanks in advance.
  17. Here is the graph for more than an hour of cpuburnA7 with my Nanopi M1 without heatsink. So my conclusion : * No crash also so the setting from Banana Pi M2+ seems good. I'll make a lima_memtest run but I think it'll be fine. * The heatsink does help (the CPU stayed mostly at 648MHz with 3 cores with the heatsink and was much erratic without) * The Nanopi M1 performance under load is way lower than Orange Pi (see tkaiser post) I think I'll use my NanoPI with Openelec to replace my Raspberry Pi 2. I'll make a test this weekend and ask my daughters to watch Frozen / Any Ghibli movie one or two times on it . That's not what I have planned but that'll do. @tkaiser Can I make a PR on github to update the nanopim1.fex or do you want to fix differently ? Should I add the nanopi M1 page on linux-sunxi's Wiki ? That should close the Nanopi case for now unless anybody need another test (once the nanopi are in the hands of my daughters, tests will be way harder to plan)
  18. At last one good news. I made three one hour runs of lima_memtester at 696, 720 and 744 MHz and they all passed without any crash or redish background. Tomorrow I'll remove the heatsink, clean the CPU and remake a cpuburn-a7 to be absolutely sure that my previous graph is trustable. @tkaiser Let me know if you need something else.
  19. Here is attached the graph for an hour long test of my NanoPI M1 with cpuburn-A7 It's actually not that bad, most of the time it was using 3 cores at 648MHz at 85°C. IMHO it could maybe be using a slightly higher clock speed while staying at 1.1V (going up to 90~95°C). For a little while the forth core was used again but then the frequency went to 320MHz (it seems that 240MHz don't work with my Nanopi for now) which way too low comparing with the performances with 3 cores. I'll start another test with lima_memtester (with a higher DRAM speed) and check your other questions afterwards.
  20. Hi, Finally I made a full hour run on my NanoPI M1 at 624MHz, the culprit was definitely the SOC temperature / cooling strategy. It's not shown on the screenshot by the 2 cores killed came back after a little while. I'll make other runs at higher frequencies, but the graph made me wonder about the actual cooling table. As soon as 2 cores were killed the temperature dropped from 93°c to 85°C and more or less stayed around 84°C for the rest of the lima run. CPU Frequency even jumped to 628MHz for small periods of time. I think there is some enhancement possible here. What if (I know I don't like sentences starting like that) we changed the cooling strategy : * 1st action : limit the CPU frequency to ~672 MHz so that the CPU is powered with 1.1V * 2nd action : kill 2 cores but stay with the same CPU frequency limit * 3rd action : stay with 2 cores (that seems possible if I understand correctly the graph) but limit the freq to 480 or 320 Playing with frequency alone seems not optimal here. It also seems that killing one core only has a very limited impact on the SOC temperature. Is there any documentation about ths_para / cooling_table (the comments are mostly fine, but the more the better) ?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines