bozden

Members
  • Content Count

    72
  • Joined

  • Last visited


Reputation Activity

  1. Like
    bozden reacted to Tido in Powering through micro USB   
    I have just watched the documentation of this swiss guy, he not only explains in detail, he also puts massive load on the cable and film it with a infrared camera.
     
    As a rule of thumb, 50cm maximum length and at least AWG 22 copper leads are the bare minimum
     
    but hey, watch it yourself and see with your eyes
    https://www.youtube.com/watch?v=n70N_sBYepQ
     
  2. Like
    bozden reacted to konsgn in New OPi Zero - Yet another high temperature issue...   
    I managed to test the 1.4 version with the set up in the image attached.
     
    I admit the ti sensor tag thermopile sensor is not at all a good way to test it.
     
    The test I ran:
    I let the device cool down completely between tests, then set the power supply to a selected voltage (for powering AVCC/RTC) and logged in. Then I waited for about 3 minutes while looking at the output of the armbianmonitor -m for the temperature to stabilize. Then I ran the following command:
    sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=$(grep -c '^processor' /proc/cpuinfo) while watching the remote sensing temperature output from the sensor tag.
     
    here is what I got:
     
     
    and :
     
     
    ....According to the results, it runs faster and hotter at the expected temp of 3.3V.
     
    I only tested a few times, but I am now of the opinion that these chips will run hot one way or another.
     
    For my application, I will be giving it a 3.3V regulator and a nice heatsink.
     
    Further testing would probably benefit from a more directly attached temperature sensor/ more accurate thermopile & logging.
     

  3. Like
    bozden reacted to konsgn in New OPi Zero - Yet another high temperature issue...   
    Just a heads up, I think the bigger issue between the revision 1.1 and 1.4 is that they removed the "U5" buck AVCC/RTC 3.3V converter, Instead in its place they put a "R9" 0 ohm resistor from the GPIO 3.3v regulator "u55". As such it makes sense that they removed the "Q11" gpio voltage enable switch, since now that switch must always be on.
    In testing the voltages, the Rev 1.1 GPIO VCC is 3.37v, whereas the AVCC/RTC Vcc is 3.27v.
    For Rev1.4 though, the GPIO/AVCC/RTC Vcc is actually 3.4v.
    I am currently removing "R9" from rev 1.4 and installing a diode to drop some voltage. It may help to keep the device from overheating. If that doesn't help, perhaps adding a secondary 3.3v buck regulator can fix the issue.
     
    Update: With the diode to drop voltage, the resulting voltage on AVCC/RTC is 2.91V.
    This results in the following temp readings stable/finger tested:
    19:02:53: 1200MHz  0.71  19%  11%   6%   0%   1%   0%   -2°C
    19:02:58: 1008MHz  0.73  19%  11%   6%   0%   1%   0%   -4°C
    19:03:03:  240MHz  0.67  19%  11%   6%   0%   1%   0%   -9°C
    19:03:08:  240MHz  0.62  19%  11%   6%   0%   1%   0%  -10°C
    19:03:13:  240MHz  0.57  18%  10%   5%   0%   1%   0%  -11°C
    19:03:18:  240MHz  0.52  18%  10%   5%   0%   1%   0%  -17°C
    19:03:24:  240MHz  0.48  17%  10%   5%   0%   1%   0%  -20°C
    19:03:29:  240MHz  0.44  17%  10%   5%   0%   1%   0%  -21°C
    This leads me to believe that the temperature may not be significantly if at all different between v1.1 and v1.4. It would make sense for the slight voltage difference of voltage on the AVCC pins would change the internal temperature readings. They probably don't have any sort of voltage reference internally, and that would lead to any sort of internal reading based on analog voltages to be affected by voltage changes of the AVCC power.
    I will test this with a power supply on the seperated AVCC/RTC to see if it does indeed result in different internal readouts.
     
     
    Alright, here's what I found:

    All of these results are running the armbianmonitor right after start up and each show a "finger test" draw represents draw on the Avcc/rtc  from the power supply, and is quite stable.
     
    Orangepi v1.4 test: r9 removed, AVCC&RTC=3.27 about 50mA draw during test:
    Orangepi v1.4 test: r9 removed, AVCC&RTC=3.4V about 50mA draw during test:

    Orangepi v1.4 test: r9 removed, AVCC&RTC=2.90V about 40-50mA draw during test
     
    Results: The internal temperature sensing cannot be trusted, especially since there is no voltage reference.
    Tomorrow I will try to place a 150mA 3.3V LDO regulator instead of "r9" and see if I can find a way to actually test temperature.

    PS: I would add images if I could figure out how to do so outside of hosting them somewhere else.
     
    Sidenote:
    "R9" is glued down, so to minimize chance of lifting pads when desoldering try this:
    1- apply generous amounts of flux from flux pen.
    2) use solder wick to remove as much solder as possible
    c Once all the solder is gone, rotate the part 90 degrees with flat end needle nose pliers while slightly pushing into the board.
     
    If you managed to get enough solder off, the part should break free without lifting the pads. And if they do lift, you can always solder onto the test points on the board.
  4. Like
    bozden reacted to guidol in orangepi.com.tr suggest armbian as OS :)   
    I did take a look for an overview ( http://orangepi.com.tr/destek.html )  and all I could see was fine
    They also added the R1 which before wasnt there
  5. Like
    bozden reacted to guidol in orangepi.com.tr suggest armbian as OS :)   
    ..and I would also thank @bozden for contacting OrangePi.com.tr in native turkish language ;-)
  6. Like
    bozden reacted to Sersa Teknoloji in orangepi.com.tr suggest armbian as OS :)   
    Hello
     
    We very thank you for your studies on Orange Pi items.
     
    Orange Pi Turkey organisation is managed by “Sersa Teknoloji”. Sersa Teknoloji is a company which serves in technology sector since 1991.
     
    We support personel and institutive studies in Turkey with Orange Pi items. We send items to all European Countries, not onlyTurkey.
     
    The main reason of providing download links from our servers in orangepi.com.tr web page is that the users in Turkey can not download via orangepi.org. There were same problems in Europe side as well.  
     
    We would like to activate another web page for providing the files to solve these problems. But then, since orangepi.org provided the alternatives of  “Google drive and Mega”, we keep only serving “Armbian” ones.
     
    Our aim is to provide accessible download web page for the users, we dont have any other aim.
     
    We support Armbian OS because they provide easier experience for users.
     
    We are very thankfull to Igor and other persons in the Project.
     
    We also very thank you to “Guido Imran Lehwalder”  who contacted with us for needed arrangements.
     
    Regards
    Volkan Bahçeci
  7. Like
    bozden got a reaction from Igor in orangepi.com.tr suggest armbian as OS :)   
    I've got confirmation that the links are corrected, I waited for them to announce it here but anyway. @Igor can you please cross-check it if you have time
  8. Like
    bozden got a reaction from Igor in orangepi.com.tr suggest armbian as OS :)   
    I just received information that both our e-mails reached them. They will be working on it and make it available on Monday...
     
  9. Like
    bozden got a reaction from guidol in orangepi.com.tr suggest armbian as OS :)   
    I just received information that both our e-mails reached them. They will be working on it and make it available on Monday...
     
  10. Like
    bozden reacted to guidol in orangepi.com.tr suggest armbian as OS :)   
    Here in turkey they got a own webpage for/from Orange Pi:
    http://orangepi.com.tr/index.html
     
    On their download-pages for the Orange Pis they have mostly armbian-images linked.
    OK, old 5.25 ones - but they refer for other Operating Systems the normal Orange Pi webpage.
    Download Page is http://orangepi.com.tr/destek.html , but you have to select the model of the OPi.
     
    Orange Pi Türkiye Armbian İşletim Sistemi'ni önerir.
    Orange Pi Turkey Suggests the Armbian Operating System.
     
    The NAS-Expansion for my OPi Zero/R1 did I get from the distributor here in Turkey (Türkiye):
    https://www.robotistan.com/orange-pi
     
    For me the new best way to buy OPis here (1-2 day delivery against more than a month from china)
  11. Like
    bozden got a reaction from tkaiser in orangepi.com.tr suggest armbian as OS :)   
    I just received information that both our e-mails reached them. They will be working on it and make it available on Monday...
     
  12. Like
    bozden got a reaction from tkaiser in orangepi.com.tr suggest armbian as OS :)   
    Well, I'm pretty sure they can understand English. But I'm here to help of course... We are already in contact with @guidol
     
  13. Like
    bozden reacted to tkaiser in orangepi.com.tr suggest armbian as OS :)   
    Maybe @bozden can help here? IMO it's really important that if 3rd parties try to directly link to Armbian images (and not the download pages) that they use those generic links like 'Ubuntu_xenial_default.7z' which will be resolved automagically to most recent OS image in the background. It's sad to see outdated images being spread...
  14. Like
    bozden reacted to makama80 in Mali support announced for mainline (Allwinner SOC's)   
    For what it's worth, and one of the most discussed topics can now hopefully finally closed: Mali in mainline
     
    Did not try it, but the source is trustworthy to my humble knowledge... Still no open source release, but I guess it silences a lot of people questioning for Mali support!
     
    For the real Mali die hards, here is a link to some more background info: Free Electrons
  15. Like
    bozden reacted to chwe in Powering through micro USB   
    Since there are a lot of issiues with underpowered boards, this ‘White Paper’ should explain why it’s recommendet to think about the powering situation of your board (especially if it’s powered throught micro USB).
    Basics:
    It’s all about Ohm’s Law (eq. 1), your SBC needs a defined voltage (U) and current (I). So the only variable that we can influence is the resistance (R)!

    The micro USB cable which powers our board acts as resistor between the output of the power source and the input of our board. For the moment, let’s assume our power source delivers a stable Voltage (what isn’t true, depends on current needed) and our cable has fixed resistance (what’s more or less correct). It’s clear that the more current is needed, the more drops the voltage (fig. 1).

    Figure 1: Voltage droping (cable ressistance was assumed to 0.5 Ohm)
    Depending on your SBC, it’s more or less tolerant to such a voltage drop. But the result is mostly the same à software instability.
    How can we influence the resistance of our cable, this is simple à Use the thickest and shortest cable that you can find. The resistance of a round coper wire is defined by eq. 2.

    Cause ρ is a material constant, only length and thickness could be changed. The length can easily be checked. Whereas for the thickness you have to cut the cable and check it, or trust the vendor that he doesn't cheat you (the more copper inside a cable, the higher the production cost). The American wire gauge (AWG) classifys the thickness of your copper wires inside your cable. Its often written on your cable. Micro USB cables have mostly a AWG number between 30 (d=0.255mm) to 20 (d=0.812mm) for realy good ones (Illustration 1).

    Illustration 1: AWG print on cable
    Example:
    If we assume that there’s no voltage drop from the connector (which is not true) and the power source has an output of 5.1 V @ 2.0 A and our SBC needs >4.8 V to run properly*. How long can a copper-cable with a defined diameter be before the SBC crashes?
    *this numbers are chosen randomly, since I don’t have any validatet numbers when a specific board runs into instability.
     
    Using eq. 2 for cables between EWG 20 and EWG 30 gives us the following results (fig. 2).

    Figure 2: Voltage drop of a copper cable at various thiknesses
    If we only had a voltage drop due to the cable length (no resistance from the USB connectors nor inside the SBC) we could have cable lenghts between 40cm (AWG30) up to 4.8m (AWG 20). But that’s not the reallity! To illustrate this, some measurements on a real issue were done.
     
    Case Study:
    Three different USB-Chargers and four different micro USB cables were used to charge a ‘xtorm’ powerbank (from the powerbank spec, it should be possible to charge it with 2.0A @5V). This powerbank has to possibilities for charging. With the ‘onboard’ USB-cable or with a micro-USB input. With a ‘Keweisi’ USB-Powermeter on one side and a multimeter on the other side current, and voltage drop during charging was measured (Illustration 2).

    Illustration 2: Setup vor measurement
    FYI: These measurements weren't made under laboratory conditions nor with high precision equipment. All chargers are listed in Table 1.
    Table 1: Specification of the tested chargers

    Table 2 displays the tested micro-USB cables, they came mostly from buyed usb devices and were not especially buyed to power a SBC!
    Table 2: Tested micro USB cables

    Results:
    After all this theory, lets have a look how much the voltage drops at delivered current. All resulsts are sumarized in Fig. 3.

    Figure 3: Voltage drop at delivered current of all chargers
    Firstly, we see that the noname USB charger from aliexpress couldn’t deliver the claimed 2A, it seems like that it is more or less a 1A charger sold as 2A charger. The short USB-cable and the one deliverd to power a tablet (cable 1&2) performe well, with only a small voltage drop and the highest current. Even at arround 1A the thin cables (cable 3&4) have a realy hight voltage drop of around 0.5-0.7V! This is similar on the iPhone charger.  If we go to high current, the situation becomes interesting. Even if the charger can deliver such a high current (cable 1&2), thin long cables (cable 3&4) can't deliver it and the voltage drops more than 0.8V! That’s definitely not a recommended setting for a SBC.
    All these chargers are a little bit above the 5.0V at its output so no problem, right? ‘If I use a short cable this small voltage-drop of around 0.3-0.5V wouldn’t be a problem. That’s not true! As soon as the charger must deliver higher current the voltage drops at its output (Fig 4)

    Figure 4: Voltage without load, with load and on output and @powerbank
    .
    Worst in class here to is also the noname cell phone charger. It delivers around 4.1V on the powerbank side.  The iPhone charger doesn’t perfome much better. Even the Trekstore charger, which is able to deliver 2.0A couldn’t do this at 5V. With a short cable, it’s around 4.6V. I wouldn’t recommend one of these chargers to power a SBC with some peripherals attached to it.
    Conclusion:
    What's next? Should we never buy again a micro USB powered SBC?  IMO no! A micro USB powered board is not a no go. But we should keep the powering situation in mind when we have such a device. Long thin cables are definitely not recommended for powering such a device. Even short cables with a bad power source will end in touble. It stands and falls with your setup (e. g. powerconsumption of your SBC, perepherials attachted to it) and the choosing of the right charger. For example, I use a charger (2A @5V) with a fix attached AWG 22 cable (Ill. 2). Doing the same test with it (current and voltage under load at its output could not been mesured since there is no USB for the powermeter) showed 4.84V on the output of the powerbank and 5.20V without load.  Which is about 0.2V more than the Trekstore charger with the best cable attached to it. Spend a little bit more money on your powersource and you eliminate one of the possibilities to frustrate you!

    Illustration 3: Recommended powersource
     
     
  16. Like
    bozden got a reaction from chwe in OT: OrangePi Zero connector case mod   
    I used the case yesterday with a v1.1 PCB OPi zero for testing. It was just running "aplay" looping though some songs (strictly less than %5 CPU load). The test started at 46 C and reached 65 C in 10 minutes (full power limit). And 5 minutes after that I had a full system failure and it did not start again (I'll look into it when I have time). So I threw the case away.
     
    In this current status the box is not usable without active cooling. As the expansion board covers the SOC a fan on the top does nothing and the sides are also not an option. One side is covered by the expansion board's header and I wanted to spare the other side for I/O as you will do - and that would require a ribbon cable which also should prevent airflow. 
     
    I asked for an alternative design in their forums but I think a 3D-printed case designed for you application is the only viable option as @chwe suggests.
     
  17. Like
    bozden got a reaction from Nick Allen in Split Armbian in two branches with different names   
    Well, I'm not a developer from the OS perspective, I'm merely a learner writing in C and providing solutions with arm boards and Armbian.  From the end-user perspective,  something like this would be invaluable for me:
    https://www.w3schools.com/cssref/css3_browsersupport.asp
     
    If I have an idea to implement I look at the board/feature matrix and choose a board/branch combination. IMO that would decrease the noob questions tremendously.  A board manufacturer says "very good for desktop" for a board with 256 MB RAM, but having this matrix would correct it. Just use the red-yellow-green colors in the matrix cells
     
    2c
     
     
     
     
     
     
  18. Like
    bozden got a reaction from TonyMac32 in Split Armbian in two branches with different names   
    Well, I'm not a developer from the OS perspective, I'm merely a learner writing in C and providing solutions with arm boards and Armbian.  From the end-user perspective,  something like this would be invaluable for me:
    https://www.w3schools.com/cssref/css3_browsersupport.asp
     
    If I have an idea to implement I look at the board/feature matrix and choose a board/branch combination. IMO that would decrease the noob questions tremendously.  A board manufacturer says "very good for desktop" for a board with 256 MB RAM, but having this matrix would correct it. Just use the red-yellow-green colors in the matrix cells
     
    2c
     
     
     
     
     
     
  19. Like
    bozden reacted to TonyMac32 in Split Armbian in two branches with different names   
    Well, I am the only poor guy to have the board.  ;-)
     
     
  20. Like
    bozden got a reaction from tkaiser in Cable matters !   
    I just want to share what I examined yesterday...
     
    Background:
    I used OPi one to output HDMI video when a button is pressed. It has an attached fan, a remote shutdown button and a remote switch to turn power off-on (OPi is hidden and operated through these buttons). It worked on breadboard, produced 2 working examples, tested the first two with a 24h test. All fine...
     
    Problem:
    On a third installation after the "circuits" are built, I made a last test. HDMI output had problems  Sound comes and goes with a hick-up...
     
    Debugging:
    Checked wiring, checked with other video, checked with other OPi etc. Nada... The problem persisted.
     
    Lastly I checked the voltages. The output from the 2A power supply is 5.3V, (it goes to the switch and comes back) and the input to OPi is about 4.7-4.8 V !!!!!
     
    What the heck...
    I measured the full two way resistance of the power switch "circuit" as 1.2 Ohms. Well, not much
     
    Ohms law does not say so. Opi amperage is around 0.3-0.55 A in my application depending on video usage.
    Assuming 5 V and 0.5 A, the voltage drop on 1.2 Ohms line is 0.6 volts. Huh, this makes it 4.7 V on OPi... 
    Knowing possible issues beforehand I used quality 23 AWG full copper FTP CAT6 cables for data lines, but just used simple 2x1.5mm2 power cable - a 5.4 mt long two way trip. But it was not the problem either... Measured the switch, measured the 5.4 mt cable... But:
     
    I used some cheap jumper cables (which I ordered from China), and connected the switch to a protoboard with them (easy to solder and plug), and those 2x20 cm cables had a huge resistance... 
     
    I connected the switch with a thick cable and voila, the voltage at OPi is 5.0 V...
    Other installations did not have this issue because the wire lengths were now so high.
     
    Just wanted to share for those having issues... Bad voltage may manifest itself in very different ways.
     
    Actually, the most problematic part while working with *Pi's is usually the USB power cable quality. What happens to your phone (did I hear you complain on slow charging?) also happens here. In my experience a simple SMPS with 2A rating usually works well in those amperage, but cheap power cables suck !
     
    Did we get through all our copper resources on this planet? Damn!
     
  21. Like
    bozden reacted to AnonymousPi in Using 16x2 ('1602') LCD with I2C connector with Orange Pi PC   
    Hi All,
     
    I recently bought a cheap 16 character, 2 row LCD display from aliexpress.com for use with my Orange Pi PC. I got it to work without too much pain, but I thought I would document it here for the benefit of others. Some good instructions are already available on the internet, but there are some tweaks required for the Orange PI.
     
    Armbian I believe already has the I2C module compiled into the kernel directly. So no Linux Kernal insmod work required, unlike what many Raspberry PI guides seem to imply.
     
    Step 1) Buy the things you will need.
     
    1. You obviously need a 1602 LCD module which also comes with the the I2C converter. You can buy a 1602 LCD and wire it directly to the 16 GPIO pins required if you want, but that isn't the point of this guide.
    2. You will need a level shifter. The LCD display works on +5volts. The OrangePI/H3 GPIO pins are 3.3 volts. I have seen guides stating that you don't need a level shifter, but I'm sure you're slowly frying some transistors in your OrangePI over time.
    3. You will need a bunch of jumper cables etc. Like these, female to female only required really.
     
    Step 2) Wire things up accordingly.
    Thanks to this fantastic guide, the instructions on wiring the Orange PI to the Level Shifter LV ('low voltage') pins, and then the Level Shifter HV ('high voltage') pins to the 1602 I2C module is pretty clear: http://www.raspberrypi-spy.co.uk/2015/05/using-an-i2c-enabled-lcd-screen-with-the-raspberry-pi/
     
     
    Level Shifter OrangePI 1602 I2C Backpack LV 3.3V (pin 1) – LV1 SDA (pin 3) – LV2 SCL (pin 5) – GND GND (pin 6) GND HV 5V (pin 2) VCC HV1   SDA HV2   SCL  
    Note, you connect the 1602 I2C module/backpack directly to the 5Volt Pin on the PI (Pin 2 or 4) and Ground (Pin 6) respectively.
     
    Note: For some strange reason the level shifter works if you don't connect the ground pins to either side of it (i.e. Use the LV, LV1, LV2, HV, HV1 and HV2 pins only). No idea why - electrical engineering degree required I think.
     
    If all works well, you should see the LCD module light-up with the top row being a bunch of white bars (you might need to check the contrast setting of the module as well). White bars = uninitialised LCD screen.
     

     
    Step 3) Install the required packages int Armbian
    Reference:  https://www.abelectronics.co.uk/kb/article/1061/i2c--smbus-and-armbian-linux
    sudo apt-get install -y python-smbus i2c-tools Step 4) Check to see what the address of the LCD Screen is:
     
    Reference: http://www.raspberrypi-spy.co.uk/2014/11/enabling-the-i2c-interface-on-the-raspberry-pi/
    user@orangepipc:~/Downloads/i2c$ sudo i2cdetect -y 0 [sudo] password for userpi: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 3f 40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- user@orangepipc:~/Downloads/i2c$ sudo i2cdetect -y 1 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- Looks like it's 0x3f as the address on I2C bus 0 (which is apparently right according to the aliexpress buyer feedback comments)
     
    Step 5) Download Example Script
     
    Reference: http://www.raspberrypi-spy.co.uk/2015/05/using-an-i2c-enabled-lcd-screen-with-the-raspberry-pi/
     
    The example script will allow you to send text to the screen via I2C. It is very similar to my scripts for the normal 16×2 screen. To download the script directly to your Pi you can use :
     
    wget https://bitbucket.org/MattHawkinsUK/rpispy-misc/raw/master/python/lcd_i2c.py  
    Step 6) Adjust the Sample Script
     
    I need to adjust the script to reference a 1602 LCD device with address 0x3f, on Orange Pi PC I2C Bus, 0. The script as it is references a device of 0x27 on Bus 1 - it won't work. You might have a LCD device of address 0x27 (you'll know from the previous step), but it seems many of the cheap LCD modules from aliexpress are 0x3f for some reason.
     
    Adjusted script below:
     
    #!/usr/bin/python #-------------------------------------- # ___ ___ _ ____ # / _ \/ _ \(_) __/__ __ __ # / , _/ ___/ /\ \/ _ \/ // / # /_/|_/_/ /_/___/ .__/\_, / # /_/ /___/ # # lcd_i2c.py # LCD test script using I2C backpack. # Supports 16x2 and 20x4 screens. # # Author : Matt Hawkins # Date : 20/09/2015 # # http://www.raspberrypi-spy.co.uk/ # # Copyright 2015 Matt Hawkins # # This program is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation, either version 3 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program. If not, see <http://www.gnu.org/licenses/>. # #-------------------------------------- import smbus import time # Define some device parameters I2C_ADDR = 0x3f # I2C device address LCD_WIDTH = 16 # Maximum characters per line # Define some device constants LCD_CHR = 1 # Mode - Sending data LCD_CMD = 0 # Mode - Sending command LCD_LINE_1 = 0x80 # LCD RAM address for the 1st line LCD_LINE_2 = 0xC0 # LCD RAM address for the 2nd line LCD_LINE_3 = 0x94 # LCD RAM address for the 3rd line LCD_LINE_4 = 0xD4 # LCD RAM address for the 4th line LCD_BACKLIGHT = 0x08 # On #LCD_BACKLIGHT = 0x00 # Off ENABLE = 0b00000100 # Enable bit # Timing constants E_PULSE = 0.0005 E_DELAY = 0.0005 #Open I2C interface bus = smbus.SMBus(0) # Rev 1 Pi uses 0 (and Orange PI PC, for pins 3 and 5) #bus = smbus.SMBus(1) # Rev 2 Pi uses 1 def lcd_init(): # Initialise display lcd_byte(0x33,LCD_CMD) # 110011 Initialise lcd_byte(0x32,LCD_CMD) # 110010 Initialise lcd_byte(0x06,LCD_CMD) # 000110 Cursor move direction lcd_byte(0x0C,LCD_CMD) # 001100 Display On,Cursor Off, Blink Off lcd_byte(0x28,LCD_CMD) # 101000 Data length, number of lines, font size lcd_byte(0x01,LCD_CMD) # 000001 Clear display time.sleep(E_DELAY) def lcd_byte(bits, mode): # Send byte to data pins # bits = the data # mode = 1 for data # 0 for command bits_high = mode | (bits & 0xF0) | LCD_BACKLIGHT bits_low = mode | ((bits<<4) & 0xF0) | LCD_BACKLIGHT # High bits bus.write_byte(I2C_ADDR, bits_high) lcd_toggle_enable(bits_high) # Low bits bus.write_byte(I2C_ADDR, bits_low) lcd_toggle_enable(bits_low) def lcd_toggle_enable(bits): # Toggle enable time.sleep(E_DELAY) bus.write_byte(I2C_ADDR, (bits | ENABLE)) time.sleep(E_PULSE) bus.write_byte(I2C_ADDR,(bits & ~ENABLE)) time.sleep(E_DELAY) def lcd_string(message,line): # Send string to display message = message.ljust(LCD_WIDTH," ") lcd_byte(line, LCD_CMD) for i in range(LCD_WIDTH): lcd_byte(ord(message[i]),LCD_CHR) def main(): # Main program block # Initialise display lcd_init() while True: # Send some test lcd_string("RPiSpy <",LCD_LINE_1) lcd_string("I2C LCD <",LCD_LINE_2) time.sleep(3) # Send some more text lcd_string("> RPiSpy",LCD_LINE_1) lcd_string("> I2C LCD",LCD_LINE_2) time.sleep(3) if __name__ == '__main__': try: main() except KeyboardInterrupt: pass finally: lcd_byte(0x01, LCD_CMD)  
    Step 7) ADD YOUR USER ACCOUNT TO 'i2c' GROUP
     
    This is a really useful thing to do, otherwise you'll need to run the python script as ROOT (via. sudo etc.) every  time. No good if you want to write a python script that runs using your normal user account and sends messages over I2C to the LCD.
     
    Reference: https://www.abelectronics.co.uk/kb/article/1061/i2c--smbus-and-armbian-linux
    sudo adduser <YOUR_USER_ID> i2c eg: sudo adduser johnsmith i2c  
    Step 8) Run your script!
     
    python lcd_i2c.py Amazing!
     

     
    Please note: You can probably use a more advanced library to output data to the LCD, but for now, it probably isn't required:
    https://gist.github.com/DenisFromHR (you will need to adjust the code in 'RPi_I2C_driver.py' to refer to port=0, not port=1 to get this to work. Also change the address of the LCD device if required)
    http://www.circuitbasics.com/raspberry-pi-i2c-lcd-set-up-and-programming/ 
     
    What a level shifter looks like:
     

  22. Like
    bozden reacted to tkaiser in [Example] Support proposal for ROCK64   
    In my opinion NOT since this thread here contains a lot of confusing discussions that are Armbian internal and only reflect a specific situation now. I'll repost soon in new 'Board Bring Up' subforum, copy&paste the hardware part, the software support part and try to summarize dev thoughts on current situation as neutral as possible.
     
    IMO it's important to keep 'Board Bring Up' threads focused on the board if we want to use this later as 'landing pages' for users (Google is pretty fast: 'armbian banana pi r2' search already lists new thread as hit N° 2)
  23. Like
    bozden reacted to tkaiser in ROCK64   
    This is ROCK64 specific. New board with correctly working USB3 arrived 10 minutes ago. Switched to performance governor and doing the usual 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' with the slowest SSD I have lying around (Intel 540):
    random random kB reclen write rewrite read reread read write 102400 4 10794 14075 18413 14337 12084 13125 102400 16 38316 48250 58929 50123 33636 44383 102400 512 85148 113573 217972 226149 209220 229556 102400 1024 239054 254531 226798 261436 240226 213082 102400 16384 271696 291983 316979 323006 282067 292218 In other words: this is the new single drive NAS board. Forget about overpriced fails or slow A20 boards or their R40/V40 successors currently only available from brain damaged retards.
  24. Like
    bozden reacted to TonyMac32 in [Example] Support proposal for ROCK64   
    To be honest, I didn't need to talk to anyone before contributing/trying to contribute.  The Tinker Board is an excellent example of a board that has some pretty severe vendor-caused support issues in general, ticking off nearly every box from some of the earlier posts.  In this case I had one, I cloned the build system after following the proper documentation to set up a VM on my main computer, and got to work.  I then submitted pull requests on github with my changes.  I don't think a discussion about officially supporting a board is frictional to getting new devs, but I think seeing devs get dogpiled for support requests is.  That was my 100% biggest concern about getting involved, the questions I simply can't answer because I'm a low-level (firmware, micros, assembly, etc) programmer, not necessarily even a well-versed linux kernel guy (learning quickly, but there is a lot there to learn). 
     
     
    I'm afraid that's impossible to stop.  "Joe SBC" will invariably try to make a $8 device do the work of a $50 device.  Managing expectations is most likely more difficult than supporting hardware.  While it will upset the low-information DIY-er, I think you'll find collecting such requests/feedback into dedicated "rubbish threads" that link to the FAQ and disclaimers won't be detrimental to the project.  More moderator work.
     
    For supporting new boards, as long as the user community (those with no intention to develop) understands and respects that the dev users (anyone willing to code/organize/troubleshoot/brainstorm/document have final say over supporting a board (their work, their decision), then all transparent discussion is of course the preferred method.  I do like the headstone method of having an OP of a thread contain the status/updates/issues of a board, then mark it as EOL and maybe lock the thread.  
     
    @tkaiser, I like the OP in this thread, and considering improved moderation that would be a good way to get the information.  It can be done just as easily publicly as privately, getting the weigh-in of the typical dev, I just know that sometimes I have opinions of things that may offend vendors or even users, e.g. "Well if you're stupid enough to do that, I'm not going to be any help" .
     
    I've been dabbling with websites and projects for almost 20 years now (I started young), the biggest problem I see with the free exchange of ideas that is the forum is burying data in clutter.  A 20 page thread will have, literally, 2 pages of useful content.  This is simply due to agreement, question, additional thought, etc.  This is why Forums are terrible archived documentation/reference sources.  It's very easy to blame it on the user when they re-pose questions, since a proper search can find the information, but often it turns into wading through pages of nonsense and unrelated tidbits to get the command, or parameter, or info you wanted.  I believe a more constructive method involves the Forum as an idea development/collaboration platform that said information is then culled from and formalized in some manner.  I would recommend something like below:
     
    For a new Board, exactly as tkaiser opened the discussion, updating as new information becomes available.  Once a decision has been made by the team (I would assume a dev or two would have to more or less "adopt" the board in question for hardware support), close the thread, maybe clean it of extraneous info if mods haven't been doing that actively, and archive it as reference on a wiki, or transfer its information to a wiki and link to an archived PDF/html/whatever of the original, maintaining the conversation, but not allowing it to get buried or cause a huge amount of "pinned" topics you have to drill through to get to "live" discussions.
     
    Upon officially declaring a board to be supported, have a subforum for the board (I know, huge effort organizing), then open a discussion/debugging thread for each release.  Lock that thread upon release and open a bugfixing thread, etc.  Keep the last release or two on the forum as immediate reference, archive the rest as HTML/PDF/Whatever available via a Wiki page for the board.  A "Hardware Support Status" table on a wiki would be ideal, just simple Green/Yellow/Red next to the supported bits per kernel, a simple visual aid goes a long way.  I would include an * or <- or some other mark with a note about special patching if it's needed (WiFi on Tinker Board Kernel 4.4 as an example)
    "Official" Forum threads need to be consistently titled (example/proposal):
     
    [Pre-Release 5.31] Hardware Feature Request
    [Release Candidate 5.31] Bug Reporting
    [Release 5.31] Continuing Support  
     
     
    Now, boards may come about that initially seem like a great idea, check the boxes, but which later turn out to be piles of garbage.  I would recommend having a mandatory "trial period" for a board before committing to support it, no matter how perfect it might seem.  (Call it "Maybe-an"?  )  Again, personal experience here, the Tinker Board BT, SD power supply, and MAC address issues all require hacking up the kernel in a not easily supportable way or writing our own drivers.  Some of that wasn't obvious until the Rockchip/ASUS team released the source for their kernel.  In a situation like this, a discussion needs to happen concerning how to support and if/why to support moving forward.  I would personally wait another cycle for the next release and see if any more mainline work is done on the part of the vendor.  If not, we need to decide if something as ridiculous as making the board capable of rebooting properly is our responsibility/interest.  Other boards, I'm sure, are similar.
     
    My apologies for rambling.
  25. Like
    bozden got a reaction from pfeerick in Nightly images?   
    Thank you for this... This is a quite valuable resource...