Jump to content

brian hewart

Members
  • Posts

    6
  • Joined

  • Last visited

  1. Humble apologies to Martin and Tido. I ask for advice and don't take it. There is a reason, age, if I patch things and it works, sure as hell in a few weeks when I want to make a change I'll have forgotten or lost the links to the changes. I have wired in the PCF8574, it works with no changes to the system. Crazy, when all those pins are sticking out of the Rock64, defeatist maybe but it is working, I understand what is going on and I can tidy things up now. If Armbian ever fixes the GPIO I would pull out the 8574 and go direct. It's tidier.
  2. Thank you Martin. Since my brainwave of using an expander board on the i2c that is working perfectly I'll give that a try and then it's all working in a manner I'm comfortable with.
  3. I must admit to enjoying freecell. Everything is looking like a fudge. I've looked at all the links and all basically say "this does not work properly". I returned a Tinker Board soon after they came out, I assumed that with the name ASUS on it that it might work, but no. The Rock64 tried the same job, screwed on the back of a TV for watching bike racing via Eurosport. That failed too, not reliable. A bog standard second hand Dell running Mint works faultlessly. Eurosport seems to lack enough servers for race day internet and the little boards ( inc RPi ) can't buffer it sufficiently. I do have an LCD running on the i2c bus, as a last desperate move I could add an PCF8574 expander board and use that to pulse the start SIM900 signal. In fact this is probably the best idea, it's using a service that is properly implemented. Watch this space. Just as a matter of interest, this is what is running perfectly right now: mosquitto - brokering many ESP8266 boards 20x4 LCD on i2c - status display so monitor can be turned off. SIM900 - send/receive text messages with no changing ip address problems Android phones/tables works well with mosquitto.
  4. Not quite for the moment but it's looking hopeful. It's very frustrating but I'm retired and this keeps my brain going. Everything has been developed on a Mint PC ( apart from this one control signal ). Move it to an RPi and it drops incoming serial chars. Move it to the Rock64 and it works like the PC then I hit this GPIO problem. Do your libraries still hit the sudo GPIO problem ?
  5. Thanks for a quick reply Martin. You have replied to someone who has spent half a lifetime programming embedded systems since before MSDOS. Linux is new to me, I jumped to Mint when W10 got totally intolerable. ( before MSDOS - that would be 6809 FLEX ) I have many pythons in bin/ I'm using idle-3.5 so do I copy from python python3.5 or python3.5m ? where <same_group_as_user> is the same group as the user you wish to grant gpios: user is me "brian" and there is a group "brian" So - chown root:brian /usr/bin/python-suid ?? Then I'd call "python3-suid MQTTsms2.py" sort of thing. Will this work in idle3 ? Sorry for all the questions, it's working so well I don't want to screw it up at this stage. Rock64 is hard work, I've had so many failures.
  6. Rock64. Running mosquitto. Running my python script for home automation, measures temps, does a bit of control and uses an SIM900 for SMS outside access with no IP address issues. I've run this for ages with an Rpi doing mosquitto and an ESP8266 doing the SMS part. I tried using the RPi for everything but it can't keep up with the 19200b SIM900. The Rock64 does it beautifully. So, all works beautifully but for pulsing the SIM900 to power it up. I have R64.GPIO which works only if I sudo into idle or python. Otherwise I get the dreaded "cannot export GPIO". So close, so far. My eyes and the lcd are dim from searching for an answer. Trying to add me to gpio results in no gpio found. Surely there's a one line answer to this ?
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines