Recommended Posts

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.   :lol: 

 

Next up is to actually use it to read something/write something, and make a PR or two.

Link to post
Share on other sites
Armbian is a community driven open source project. Do you like to contribute your code?

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.

Link to post
Share on other sites

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?  :lol:) 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.

Link to post
Share on other sites

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.

 

Link to post
Share on other sites
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?

643090607_UntitledDiagram.png.cc37af80c0e74b8767fa50ed025eaf05.png

 

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:

312926041_UntitledDiagram.png.024b8301aa9b1b68ecb434e8f57f8804.png

 

 

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...

 

 

Link to post
Share on other sites

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

Link to post
Share on other sites

@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.

Link to post
Share on other sites
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.  

:lol:

https://www.draw.io/

it was actually easier than explaining stuff.. :lol:

 

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.. :lol: 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.. :D 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.. :ph34r::lol:

 

Link to post
Share on other sites
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.

Link to post
Share on other sites

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 :)

Link to post
Share on other sites
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...

Link to post
Share on other sites
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?

Link to post
Share on other sites
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.

Link to post
Share on other sites

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.

Link to post
Share on other sites
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... 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...