Jump to content

billybangleballs

Members
  • Posts

    18
  • Joined

  • Last visited

Reputation Activity

  1. Like
    billybangleballs reacted to TheOWL in [Orange Pi One] How to enable UART?   
    OHHHHHH Sh!t......it works!!!
    I sign up an account just to thank martinayotte !!! You are like god for me now !
  2. Like
    billybangleballs reacted to blprasad in Orange Pi Zero, Python GPIO Library   
    billy thanks for your input.
  3. Like
    billybangleballs reacted to TonyMac32 in armbianmonitor -m & OPi0   
    I can confirm this, thank you for the info, on the NanoPi NEO Air I'm getting similar results testing my heat sink solution:
     
    Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU 01:47:08: 912MHz 0.53 0% 0% 0% 0% 0% 0% 33°C 01:47:13: 240MHz 0.49 0% 0% 0% 0% 0% 0% 33°C 01:47:18: 240MHz 0.49 0% 0% 0% 0% 0% 0% 33°C 01:47:24: 240MHz 0.45 0% 0% 0% 0% 0% 0% 33°C <snip> 01:51:12: 912MHz 3.87 0% 0% 0% 0% 0% 0% 45°C 01:51:17: 912MHz 3.88 0% 0% 0% 0% 0% 0% 46°C 01:51:22: 912MHz 3.89 0% 0% 0% 0% 0% 0% 46°C 01:51:28: 912MHz 3.90 0% 0% 0% 0% 0% 0% 46°C 01:51:33: 912MHz 3.91 0% 0% 0% 0% 0% 0% 46°C 01:51:38: 912MHz 3.92 0% 0% 0% 0% 0% 0% 46°C 01:51:43: 912MHz 3.92 0% 0% 0% 0% 0% 0% 46°C 01:51:48: 912MHz 3.93 0% 0% 0% 0% 0% 0% 46°C 01:51:54: 912MHz 3.94 0% 0% 0% 0% 0% 0% 46°C 01:51:59: 912MHz 3.94 0% 0% 0% 0% 0% 0% 46°C <snip> 01:54:39: 912MHz 4.08 0% 0% 0% 0% 0% 0% 49°C At least the heatsink works, I used thermally conductive epoxy to attach a fair-sized heatsink to the CPU, that thermal pad they give is not very good. It appeared to level off at around 52 C 15 minutes in.
  4. Like
    billybangleballs reacted to Igor in \var\log & \var\log.hdd   
    Important data are at download page, more general in docs.armbian.com, the rest you can find by using search engine or Google powered site search. 
  5. Like
    billybangleballs reacted to tkaiser in armbianmonitor -m & OPi0   
    Don't know, running mainline kernel on all H3/H2+ devices here and there it works:
    root@orangepiplus2e:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU 10:17:28: 1296MHz 0.89 15% 13% 1% 0% 0% 0% 45.3°C 10:17:33: 1008MHz 0.98 15% 13% 1% 0% 0% 0% 41.8°C 10:17:38: 1104MHz 0.98 18% 14% 1% 0% 1% 0% 43.7°C 10:17:43: 816MHz 0.98 18% 16% 1% 0% 0% 0% 41.1°C 10:17:48: 816MHz 0.98 18% 16% 1% 0% 0% 0% 41.2°C 10:17:53: 816MHz 0.98 18% 16% 1% 0% 0% 0% 40.1°C 10:17:58: 960MHz 0.99 22% 16% 4% 0% 0% 0% 40.7°C 10:18:03: 1008MHz 0.99 22% 16% 4% 0% 0% 0% 39.6°C 10:18:08: 960MHz 0.99 20% 15% 1% 0% 1% 0% 39.6°C 10:18:14: 480MHz 0.99 18% 15% 1% 0% 0% 0% 39.2°C 10:18:19: 1008MHz 0.99 18% 15% 1% 0% 0% 0% 40.3°C 10:18:24: 480MHz 1.07 19% 16% 1% 0% 0% 0% 39.5°C 10:18:29: 648MHz 1.07 19% 16% 1% 0% 0% 0% 39.0°C^C root@orangepiplus2e:~# uname -a Linux orangepiplus2e 4.10.1-sun8i #2 SMP Thu Mar 2 18:38:29 CET 2017 armv7l armv7l armv7l GNU/Linux The armbianmonitor script in this scenario either tries to interpret /proc/stat directly or in case it detects a running rpimonitorhelper daemon running (as part of Armbian's RPi-Monitor installation) then it uses /tmp/cpustat instead to save some CPU cycles. Maybe there's something wrong. Very low priority to fix since we implemented this only for a single reason: Giving users a simple monitoring solution to help us identifying their problems (eg. high %iowait values is an indication for 'storage too slow' and not 'CPU overloaded'). Unfortunately this almost never happened.
     
    Simple workaround: Use 'iostat $samplerate' eg 'sudo iostat 5' in another shell. Will then print statistics every 5 seconds that look like this:
    avg-cpu: %user %nice %system %iowait %steal %idle 6.48 0.00 16.01 13.16 0.00 64.35  
  6. Like
    billybangleballs reacted to tkaiser in Orange Pi Zero went to the market   
    OMFG, just tested with Xunlong's own Lubuntu 14.04 release relying on their default settings:
    avg-cpu: %user %nice %system %iowait %steal %idle 0.00 0.07 0.13 0.07 0.00 99.73 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mmcblk0 0.40 0.00 7.20 0 36 sda 0.00 0.00 0.00 0 0 ^C root@orangepi:~# cat /sys/devices/virtual/thermal/thermal_zone1/temp 61 root@orangepi:~# grep -c processor /proc/cpuinfo 3 The board is absolutely idle (see %idle above: 99.73 percent), idle consumption is 1860 mW (yeah, close to 2W!!!), SoC temperature is around 60°C and one CPU core already has been killed. Reason is simple: This OS image relys on crappy Allwinner defaults, the dvfs settings are completely wrong and settings ignore everything community has done around H3 within the last 12 months.
     
    The settings used with this image are broken, the CPU is always fed with 1.3V, killing CPU cores is preferred over sane throttling (that's why only 3 CPU cores are active) and even if max cpufreq with this image is limited to 1008 MHz CPU cores are killed. And I did not even do anything heavy, it was only installation of RPi Monitor that lead to 'overheating' and killing the 4th CPU core. So by using Armbian (using linux-sunxi community settings!) you get both more performance and better thermal behaviour.
     
    Xunlong, please stop doing software or at least look what community did in the last 12 months! Now folks like Michael Larabel will take an OPi Zero, will take your crappy Lubuntu image, run Phoronix test suite and OPi Zero will get horribly low benchmark scores. And the whole world again laughs about Xunlong devices but in reality it's just dumb Allwinner default settings that you (again) use in your OS images.
     
    Why the hell did you do that? Please stop providing OS images with your broken settings, it's easy to adopt good settings instead: https://github.com/igorpecovnik/lib/blob/master/config/fex/orangepizero.fex (cooler_table, ths and dvfs settings need to be adopted). Please immediately remove this Lubuntu crap or at least fix script.bin and include a link to Armbian download page. Or do you really want that users/testers again start to spread the word your hardware would be crap?
     
    Edit: Today Xunlong released 3 new OS images for OPi Zero, I looked at something called 'Debian_server_For_OrangePiZero'. Settings still 100 percent wrong and board overheating like hell especially due to incorrect dvfs settings (it has to be 'pmuic_type = 1' and there need to be at least one dvfs operating point defined that makes use of 1.1V at a reasonable cpufreq):
     
     
     
     
    Apart from that this image is still based on an unpatched 3.4.39 kernel (why on earth?) but at least a script called /etc/init.d/firstrun resized the rootfs automagically. With the Lubuntu image from two days ago not even an 'apt-get upgrade' worked sinze rootfs was filles with 95%. So there's at least one person active at Xunlong trying to re-invent the wheel providing OS images that suck so people are able to claim Xunlong boards are a fail. Great.
  7. Like
    billybangleballs got a reaction from Igor in Orange Pi Zero, Python GPIO Library   
    My Opi0 arrived yesterday, and I immediately installed the "debian_server_For_OrangePizero_v0_9_2.img", default OS.
    But after it overheated and crashed during the night, I installed "Armbian_5.25_Orangepizero_Debian_jessie_default_3.4.113.img", instead.
     
    After setting up the networking etc. I thought I'd have a go at flashing an led or two and clicking a couple of relays. So I installed the "https://github.com/nvl1109/orangepi_PC_gpio_pyH3", mentioned by m12lrpv.
     
    The only problem I encountered was, "fatal error: Python.h: No such file or directory", but "sudo apt-get install python-dev" cured that and it appears to have worked.
     
    Running "python orangepi_PC_gpio_pyH3/examples/blink_led.py" makes a little red led on the Opi0 board start flashing, which I assume was the general idea. I've not tried anything more exciting yet, I thought I'd share the good news first
  8. Like
    billybangleballs reacted to m12lrpv in Orange Pi Zero, Python GPIO Library   
    For the orange pi zero use this fork
     
    https://github.com/nvl1109/orangepi_PC_gpio_pyH3
     
    The original won't work.
     
    That fork has the correct mappings for all of the pins. For a quick test try setting pins PA16 or PA15 and see if it works.
     
    if you get
    AttributeError: 'module' object has no attribute 'PA16'
    then you've picked up the wrong module.
     
  9. Like
    billybangleballs reacted to tkaiser in Random SBC discussion (moved from OPi Zero thread)   
    Well, I would prefer to leave this thread here open as 'playground' for one specific user who can then write his confusing stuff here where it can be easily ignored. The same user IMO needs a warning that as soon as he starts again to destroy 'real threads' somewhere else by flooding them with false claims, assumptions and asking the same questions again and again that his posts get deleted and his account banned.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines