TonyMac32 Posted December 5, 2018 Posted December 5, 2018 This falls somewhere between "how-to", "research", and "development", so I stuck it here. @adafruit is working to target CircuitPython to Armbian devices, something that will be a bit of a task. I've been playing with the code to get it working on my Tritium H3, finally did (some extra sudo-ing was needed), so I'll probably toss in a couple board definitions/help here and there if I can. it had hijacked a C2 thread (not completely, it was at least about using it on the C2), and I thought it best to continue discussion here. @chwe, @sgjava, and @Larry Bank all have various experience with various GPIO tools, their interest may vary. My current observations, doing some hacking to make it run on my board: superuser is necessary to get to the gpio I had to install wheel before blinka or setup failed spectacularly board detection is crazy (I noticed in the PR that it is planned to get worked on) I had to inject my board name into seemingly 30000000000000 files. Next up is to actually use it to read something/write something, and make a PR or two. 1
sgjava Posted December 5, 2018 Posted December 5, 2018 https://github.com/sgjava/userspaceio supports C, C++, Python and JVM (Java, Scala, Koltin, etc.). Do we really need another Python lib besides WiringPi and RPi.GPIO? Also, I have non-root access working for pretty much everything. Another thing, from looking at the CircuitPython site it appears to only support micro controllers at this point, not a full blown SBC. For this type of stuff I'm using NodeMCU with Lua which is mature and is hard to beat from a price/performance/usability perspective. 2
TonyMac32 Posted December 5, 2018 Author Posted December 5, 2018 Honestly I don't know if we need another of a lot of things, but I can't think of anything I would have to do for this on the Armbian side that wouldn't be useful to your or any other library/user, so I don't see any harm in it. It does have the (perhaps ominous old-school Windows IE integration? ) advantage on it's side that Adafruit ships all of their devices with this micropython derivative, so it is inevitable that people moving from an adafruit micro to an orange pi will come on this forum asking questions/support "as seen on" Adafruit's site. And they've generated a lot of code for gadgets, I'm sure some of it can be useful outside the context of their specific library. I know I personally wipe out Python and go straight to C on micros, but I'm also sitting here with 20 years of programming experience. If the people I bought gadgets from had a library and I was new I'd use it. @sgjava I need to check out your JVM bindings, I never tried doing anything hardware with Java.
sgjava Posted December 5, 2018 Posted December 5, 2018 Yea, I understand trying to consolidate behind a single library, but I prefer using a single API and wrapping that with whatever language I want. It's a matter of perspective I guess. For beginners it may make sense to make it easy to use. @TonyMac32 The Java code performs pretty well using JNA instead of JNI.
adafruit Posted December 6, 2018 Posted December 6, 2018 hiya - yes circuitpython is originally designed to run on small microcontrollers. as we've ported over 100 drivers, libraries and helpers, the light-but-complete API can also be really great for Python 3 computers. that way people can start a project on smaller chips, then 'upgrade' to a SBC when they want video, mp3, full tcpip stack. or they can just take advantage of all the drivers to make IoT SBC with sensors we sorted out the API about 2 years ago when we started circuitpython, and have been hacking on adding the Py3 support layer over the last few months. the translation layer repository is here https://github.com/adafruit/Adafruit_Blinka the new platform detection repo is here https://github.com/adafruit/Adafruit_Python_PlatformDetect - it will be replacing the current platform detection.
chwe Posted December 11, 2018 Posted December 11, 2018 On 12/6/2018 at 10:47 PM, adafruit said: the new platform detection repo is here https://github.com/adafruit/Adafruit_Python_PlatformDetect - it will be replacing the current platform detection. from a quick overview, your PlatformDetect looks... a bit messy.. from what I understand it looks like the following? let's face it.. the majority of your users which use this lib on linux will be RPi users.. the boards are well known, 'cheap' and everywhere available. There are only a few beagles so it makes sense to look at them first before you start with the armbian boards (we support roughly 50 boards).. and if everything fails let the user manually decide which board he has.. https://github.com/adafruit/Adafruit_Python_PlatformDetect/blob/672713699e6d21854d65ec8f0d765c8fb125d03b/adafruit_platformdetect/board.py#L85-L87 looks like not that easy to add new boards.. a more general way would be something like: if self.armbian: etc... for all those RPi thingies something like talking to the threadX would easily tell you that it is a RPi.. no board else will ever talk ThreadX commands. https://github.com/adafruit/Adafruit_Python_PlatformDetect/blob/672713699e6d21854d65ec8f0d765c8fb125d03b/adafruit_platformdetect/board.py#L58-L68 no ESP32 in the future? I don't even buy esp8266 anymore.. The 32 is in a similar price-class and especially for python/micropython a way more powerful.. IMO your board detection mechanism should look more like this: proc/cpuinfo should give you all you need to distinguish between RPi/BB and 'everything else' and from there you can start a proper way of detecting supported boards on armbian.. your code gets messy as soon as you add more boards on armbian... 1
adafruit Posted December 11, 2018 Posted December 11, 2018 sounds good, yeah we're still working out the platform detection stuff, your structure looks good! we also will be adding 96boards support so that's a whole 'nother collection of mysteries for ESP32, blinka will probably work, we just haven't tested it. we'll probably go back to that after getting linux sorted out
TonyMac32 Posted December 12, 2018 Author Posted December 12, 2018 @chwe it's not in UML???? To be honest I think my head would explode if I ever saw anyone actually publish open source code with modelling and flowcharting. My coding experience is x86 and ARMv4t assembly language, C, and Java. Python never interested me in the least, which is why I hadn't been as helpful with these libraries before. Well, on the 3rd/4th one I guess I need to learn the language so I can teach my little ones. For these libraries I'm primarily looking at/commenting on structure and use, so I am an educated "noob" as far as the tool is concerned. @chwe is a bit more knowledgeable, and loves flow charts.
adafruit Posted December 12, 2018 Posted December 12, 2018 we've updated the library structure, @chwe wanna take another look?
chwe Posted December 12, 2018 Posted December 12, 2018 13 hours ago, TonyMac32 said: To be honest I think my head would explode if I ever saw anyone actually publish open source code with modelling and flowcharting. https://www.draw.io/ it was actually easier than explaining stuff.. 13 hours ago, TonyMac32 said: For these libraries I'm primarily looking at/commenting on structure and use, so I am an educated "noob" as far as the tool is concerned. @chwe is a bit more knowledgeable, and loves flow charts. I just maintained pyGPIO by accident.. collecting some bits here and there and bring it together, decide to brush it a bit up and there it is.. https://github.com/adafruit/Adafruit_Python_PlatformDetect/blob/0d7e823fd317f4c4dae9e984d8446ee0c46e6aa3/adafruit_platformdetect/board.py#L150-L151 elif chip_id == ap_chip.SUN8I: return self._armbian_id() why not armbian at the bottom and use something like: else: return self._armbian_id() armbian supports not only sun8i well my interest is somehow limited in the GPIO stuff.. I've a few examples where I need it and for the rest it's highly specific stuff, the average user doesn't need.. If @adafruit decides to design a bench-top NMR for an reasonable prize, I'm in.. or a 700/800nm fluorescence detector.. 13 hours ago, TonyMac32 said: My coding experience is x86 and ARMv4t assembly language, C, and Java. Python never interested me in the least, which is why I hadn't been as helpful with these libraries before. I'm still a chemist not engineer.. So hopefully you folks are better in it..
Tido Posted January 5, 2019 Posted January 5, 2019 35C3 - MicroPython – Python for Microcontrollers https://www.youtube.com/watch?v=xCPnOxWxHIc at min 5:30 you see also Adafruit, haven't seen it completely, but stumbled across it 1
sfx2000 Posted January 11, 2019 Posted January 11, 2019 @adafruit - are you looking to run circuitpython on armbian boards, or are you looking at armbian boards hosting circuitpython that are hosting attached MCU's? I'm a bit puzzled here - as most boards capable of running Armbian can run python3/python directly from both a development and runtime perspective.
TonyMac32 Posted January 11, 2019 Author Posted January 11, 2019 56 minutes ago, sfx2000 said: I'm a bit puzzled here - as most boards capable of running Armbian can run python3/python directly from both a development and runtime perspective. If you look at their code, they are more or less bridging python and their pile of I/O libraries/routines. The result should be ready to go support for the adafruit-supported hardwares.
manuti Posted January 11, 2019 Posted January 11, 2019 7 hours ago, TonyMac32 said: adafruit-supported hardwares. ► Speculation ahead! I think Raspberry Pi sales are stagnant, so... if you want to sell more hardware related to IoT and GPIO, you need to expand your customer base: Pi Orange, NanoPi,...
adafruit Posted January 11, 2019 Posted January 11, 2019 hiya - we wanted an easy and extensible way to support the large # of various linux boards - and doing it this way means very little effort for a big outcome! we've got 125 libraries and drivers, having them all work on any computer would avoid duplication of effort and MORE COOL HARDWARE being built
sfx2000 Posted January 11, 2019 Posted January 11, 2019 18 hours ago, TonyMac32 said: If you look at their code, they are more or less bridging python and their pile of I/O libraries/routines. The result should be ready to go support for the adafruit-supported hardwares. I think it's pretty cool in any event, and like you mentioned, they do have quite a few boards that their circuitpython supports directly - and saw earlier today a good mention about their Android APK.. https://hackaday.com/2019/01/10/code-on-your-phone-with-circuitpython-editor/ The feather product line is pretty nifty - bit higher pricewise, but at the same time, everything has been tested and validated to work within the feather ecosystem...
sfx2000 Posted January 11, 2019 Posted January 11, 2019 4 hours ago, adafruit said: hiya - we wanted an easy and extensible way to support the large # of various linux boards - and doing it this way means very little effort for a big outcome! we've got 125 libraries and drivers, having them all work on any computer would avoid duplication of effort and MORE COOL HARDWARE being built No doubt - I see even ESP8266 is supported, which is no small amount of effort considering the limitations and small memory footprint... Any word on when/if ESP32 is going to be supported?
adafruit Posted January 12, 2019 Posted January 12, 2019 we will be supporting ESP8266 and ESP32 as co-processors - https://learn.adafruit.com/adding-a-wifi-co-processor-to-circuitpython-esp8266-esp32
chwe Posted February 19, 2019 Posted February 19, 2019 On 1/11/2019 at 6:25 PM, adafruit said: we wanted an easy and extensible way to support the large # of various linux boards well then I hope you start to clean your board detection mess here: https://github.com/adafruit/Adafruit_Python_PlatformDetect/blob/master/adafruit_platformdetect/board.py it looks like you start to add more boards (e.g. C2 is there). But it looks even more bloated as the last time I looked at it.
adafruit Posted February 19, 2019 Posted February 19, 2019 @chwe hiya restructuring PR's that don't break all the tests are welcome, we aren't experts at structuring code like you are if there's some other cross-platform detection suite, we'd use that instead please let us know if you can help us with code restructuring!
adafruit Posted January 18, 2020 Posted January 18, 2020 hi @chwe we never got a restructing PR from you, can you let us know when you would be submitting it?
TonyMac32 Posted January 20, 2020 Author Posted January 20, 2020 Hi @adafruit! It's been 11 months, and @chwe never committed to providing said PR, he provided a critique. I would say it's a safe guess a PR isn't coming. For my part I still really like the concept, but yes, the need to put board detection logic in every sub-function library was a bit rough. I myself haven't looked at this code in quite some time, I spent the summer helping my wife with her recovery from a spinal tumor removal, I'm only now catching up on other things. Somewhat related, I should be getting a Giant Board whenever UPS decides it isn't too snowy to provide service. I'm interested in how that performs, I know it is running Blinka, it should give me something to compare to if I pursue it. (I'm still catching up on BSP issues at the moment for our next release window) An interesting benchmark would be Blinka on Linux SBC vs these new NXP iMXRT boards.
adafruit Posted January 20, 2020 Posted January 20, 2020 hi @TonyMac32 please take care of your fam.... @chwe when ya can, please submit a PR that fixes the "bloated" "mess" of code to best help the community.
chwe Posted January 20, 2020 Posted January 20, 2020 13 hours ago, adafruit said: @chwe when ya can, please submit a PR that fixes the "bloated" "mess" of code to best help the community. back then the boarddetection was roughly 200 lines of code, now ~72 commits affecting this file later. we have 600 lines of code. I didn't even look at it fully to see if something in the logic changed and I won't do it. GPIO handling is of minor interest to me. The reason I maintained pyGPIO for a while (credits for writing it goes mostly Olimex - I just added a few other boards and a detection mechanism for those using armbian) was cause there was a community demand for it - there was never much attention to it so pyGPIO is more or less dead. From the boards you list on your lib I probably own 4-5 and most of them either run productive and I don't touch them anymore (except updating the OS from time to time) or they sit in their boxes and do nothing. So I couldn't even test if it works as it should. If the code is still maintainable for you keep going, if it isn't don't expect others to fix it for you and rewrite it on your own once you've the time for it. The same counts for armbian as well - I don't expect someone to rewrite NandSataInstall one of our scripts which is boated to hell and should've been rewritten a long time ago but being aware that this should be done once - it's just a question when someone has the time for it. As @TonyMac32 mentions we've soon a new armbian release and I've some plans to get some (for me interesting) features working unfortunately for you, none of them is GPIO nor python related...
Recommended Posts