ron69 Posted March 6, 2017 Posted March 6, 2017 hi there, i'm quite new on arm, so apologize for my stupid questions. i'm trying to compile example in wiringOP lib. but i got error: zero@orangepizero:~/WiringOP/examples$ gcc -o blink blink.c -lwiringPi //usr/local/lib/libwiringPi.so: undefined reference to `pthread_join' //usr/local/lib/libwiringPi.so: undefined reference to `pthread_create' //usr/local/lib/libwiringPi.so: undefined reference to `pthread_cancel' collect2: error: ld returned 1 exit status i'm running Xenial legacy on orange Zero. can someone help me please?
XTL Posted March 14, 2017 Posted March 14, 2017 local sounds bad in that path. Where did you get the lib? What's the output to: ldd /usr/local/lib/libwiringPi.so
MikeA Posted June 7, 2017 Posted June 7, 2017 Add a -lpthread to the gcc line and it'll work fine: gcc -o blink blink.c -lwiringPi -lpthread The wiringPi library includes headers from the pthread library. Also note that there are at least TWO versions of the wiringOP/wiringPi libraries for the Orange Pi's, one for the 26 pin OP-Zero ( https://github.com/xpertsavenue/WiringOP-Zero ) and one for the 40-pin OP's ( https://github.com/zhaolei/WiringOP ) and they ARE different. I made the mistake of installing the 40-pin version on an OP-Zero and then was wondering why it wasn't working (I'd accidentally connected a MAX6755 the wrong way and had wires almost melted before I pulled it back off. Then I'd also reformatted the SD card and reloaded things. So I figured at first I'd fried some of the GPIO pins when I couldn't get things to working again til I realized it was just due to the wrong library. I'd hooked up LED's to all the GPIO pins and was cycling them to see which had gotten fried and they all worked but NOT as expected. I.e. I'd set pin 3 high and maybe pin 10's LED came on. Once I swapped the libraries, it worked fine.
chwe Posted June 7, 2017 Posted June 7, 2017 14 minutes ago, MikeA said: Add a -lpthread to the gcc line and it'll work fine: gcc -o blink blink.c -lwiringPi -lpthread The wiringPi library includes headers from the pthread library. Also note that there are at least TWO versions of the wiringOP/wiringPi libraries for the Orange Pi's, one for the 26 pin OP-Zero ( https://github.com/xpertsavenue/WiringOP-Zero ) and one for the 40-pin OP's ( https://github.com/zhaolei/WiringOP ) and they ARE different. I made the mistake of installing the 40-pin version on an OP-Zero and then was wondering why it wasn't working (I'd accidentally connected a MAX6755 the wrong way and had wires almost melted before I pulled it back off. Then I'd also reformatted the SD card and reloaded things. So I figured at first I'd fried some of the GPIO pins when I couldn't get things to working again til I realized it was just due to the wrong library. I'd hooked up LED's to all the GPIO pins and was cycling them to see which had gotten fried and they all worked but NOT as expected. I.e. I'd set pin 3 high and maybe pin 10's LED came on. Once I swapped the libraries, it worked fine. As you can see in the readme for the second lib you mentioned it is tested for the OrangePi PC not OrangePi zero.
MikeA Posted June 7, 2017 Posted June 7, 2017 13 minutes ago, chwe said: As you can see in the readme for the second lib you mentioned it is tested for the OrangePi PC not OrangePi zero. Yeah, I know that (NOW, anyways *sigh*) I coulda SWORN it was zhaolei's library that I'd installed the first time (and was wondering why gpio readall was showing 40 pins this time. Thought maybe it was a misconfiguration somewhere or such.) I've got an OP One and a Zero and had been playing the whole "install...play...wipe SD...re-install different image...poke around...wipe...rinse...repeat..." game and..............well, I'll just say both the Zero AND the MAX6755 were more durable than I'd expected. Oh, and also cheap when they DO get fried (hopefully I won't totally destroy either one.)
chwe Posted June 7, 2017 Posted June 7, 2017 Mostly its not a problem of price. Delivery time for getting the next one is more a problem.. (I should have one or two around, just to be shure when I burn one. ) Did you test test i2c or spi with the lib?
MikeA Posted June 7, 2017 Posted June 7, 2017 4 minutes ago, chwe said: Did you test test i2c or spi with the lib? A bit of both. Using a home-grown SPI bit-banging to read the MAX6755 (only needs to read 2 bytes and send nothing. Couldn't get the kernel module to work and put it aside for now.) Using a library by Lewis Loflin www.bristolwatch.com lewis@bvu.net to drive a 1602 LCD with an I2C backpack on it. Working on a device to use a thermocouple to check a coffee pot's temp and sound an alarm if it gets too hot too fast (keep it from burning dry.) It'll also be a timer for when the coffee's too old. I'll run it off a cheap Arduino Nano knock-off but need to do data collection to see "was that rise in temp due to the coffee pot being removed and put back in place?" etc. So using the OP to store data for a day or two that can then be analyzed.
chwe Posted June 8, 2017 Posted June 8, 2017 In case you just use the opi only as a dataloger. Why you don't use node-red (it hase some nice features for save data and graphs packages to show the stuff.. Have a cheap esp8266 and a mqtt broker on it makes it easy to reuse most of your code from the arduino... or if it just had to work use an arduino with firmata on it over serial. Firmata & node-red
MikeA Posted June 16, 2017 Posted June 16, 2017 The Pi is simply a temporary data logger for this. I wanted something to hook up and pull the temp every second (using a thermo-couple wire laid on the heat plate under the coffee pot) and store it and the time in a CSV file for 24 hours or so. Then I can look at it and say things like "that rise in temp from 180f to 451f in 3 seconds was due to the pot being removed. Ignore it unless the temp stays high. If it stays high for more than 2-3 mins, sound the alarm as someone left the burner on." and "OH-EM-GEE! The temp went slowly from the 180f to 451f over about 2 mins. Raise the alarm! The pot is dry and about to burn up!!!!" The coffee pot should keep the temp of the heat plate down to around the 200f area right up to the point of pot starting to run dry. In fact, next time ya hit the great outdoors, take a PAPER cup (not foam), fill with water and drop an egg in it and set it right IN the camp fire for breakfast. The cup will burn down to the water line and then stop. The water, being liquid, can't go over 212 so it keeps the cup too cool to burn. The coffee pot should have much the same effect (but I just don't yet know what temp it "idles at", how fast it climbs when the pot's removed vs how fast when it slowly runs dry, how fast it recovers when the pot's replaced, etc. So once I have an idea of what fast climb in temp is OK and what slower climb is bad (I'll deliberately let a pot of plain water run dry for logging) I can then put it all over onto an Arduino as by now I just need current readings and a running average for the past 5 mins or so and no more need for any storage place. The finished project will run off an Arduino Nano clone (or even possibly a Digispark if I can squeeze the code enough) and run a few ws2812's as a timer display for "is the coffee too old, even if fairly full?" I COULD have hooked up an SD card to the Arduino and data-logged off it but this has been a fun learning experience with the Orange Pi and seeing what works (kernel-based i2c seems fine for running a 2x16 LCD display) and what doesn't (SPI does not seem to work out of the box. I might get it to working later but simply am bit-banging the MAX 6675 and that's actually taught me more, programming-wize.) Final BOM would be: Two push buttons (one to (re)start the timer and one to silence the alarm), piezo buzzer, Arduino/Atmel chip/board of some sort, MAX 6675 thermo-couple board & thermo-couple K wire, maybe 4-5 ws2812's (or even just one that goes from bright green to dim red before going out completely after about 90 mins of the one button's press), power adapter to fit the Arduino and a nice little case.
MikeA Posted June 16, 2017 Posted June 16, 2017 BTW, I AM looking at Node-Red some as well for interfacing all these SoC's and µcontrollers but that's a bit further down the line.
chwe Posted June 17, 2017 Posted June 17, 2017 The thread is a little bit hijacked but of course interessting for others. On 16.6.2017 at 5:27 AM, MikeA said: Then I can look at it and say things like "that rise in temp from 180f to 451f in 3 seconds was due to the pot being removed. Ignore it unless the temp stays high. If it stays high for more than 2-3 mins, sound the alarm as someone left the burner on." and "OH-EM-GEE! The temp went slowly from the 180f to 451f over about 2 mins. Assume that your coffee contains mostly water (the fact that you wrote everything in °f instead of °C tells me, that you're US-citizen right? so your coffee should contain much more water than mine ) heat capatizity and enthalpy of vaporization should be similar to water. So I would assume that all the testing could be done with water (I think this is the first time that I think about thermodynamic issues outside an exame - I never expected, that this would help me or others somehow). What I learned from real life expirence: as soon as you have automated processes, people trust that everything works. Redundance on software- & on hardware-side is a must! E.g. analog readings for the thermocouple can be false, software can hang in a loop cause something wasn't programmed properly etc.. On 16.6.2017 at 6:15 AM, MikeA said: BTW, I AM looking at Node-Red some as well for interfacing all these SoC's and µcontrollers but that's a bit further down the line. If you're interessted in Node-Red on armbian maybe my thread can give you some inspiration. Sending data from arduino via cheap NRF24l01 or RFM69 trasmitters to mqtt-broker on OPi Zero should also be possibe.
Recommended Posts