Ideas for next evolution of pyboard

The official pyboard running MicroPython.
This is the reference design and main target board for MicroPython.
You can buy one at the store.
Target audience: Users with a pyboard.
User avatar
bmarkus
Posts: 111
Joined: Tue Oct 21, 2014 5:58 am

Re: Ideas for next evolution of pyboard

Post by bmarkus » Thu Jan 14, 2016 7:49 pm

32k flash far below the minimum required I guess.
Tiny Core Linux (piCore) developer
HAM radio call: HA5DI (Béla)

Nelsyv
Posts: 4
Joined: Wed Jan 27, 2016 2:26 am

Re: Ideas for next evolution of pyboard

Post by Nelsyv » Wed Jan 27, 2016 5:00 am

A version with more RAM and onboard Bluetooth 4.1 (BLE) would be fantastic. It seems to me that all the best embedded/microcontroller projects are wireless and/or portable these days, and BLE seems like the way to go since it's relatively powerful but has low power draw.

_jg_
Posts: 12
Joined: Sat Mar 19, 2016 3:47 am

Re: Ideas for next evolution of pyboard

Post by _jg_ » Sun Apr 24, 2016 1:43 am

i want to upvote for JimTal001's suggestion:
" A way to deploy protected pyboard code..".
i think this is almost mandatory if we want to see the pyboard being used in commercial or industrial applications and not just hobby projects and such. :ugeek:

User avatar
pythoncoder
Posts: 3659
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Ideas for next evolution of pyboard

Post by pythoncoder » Sun Apr 24, 2016 7:07 am

Persistent bytecode goes some way towards addressing these concerns.
Peter Hinch

_jg_
Posts: 12
Joined: Sat Mar 19, 2016 3:47 am

Re: Ideas for next evolution of pyboard

Post by _jg_ » Mon Apr 25, 2016 2:53 am

hi.
persistent bytecode?
i dont remember to have read about that in the docs..
i'll search here in the forum..

User avatar
pythoncoder
Posts: 3659
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Ideas for next evolution of pyboard

Post by pythoncoder » Mon Apr 25, 2016 7:22 am

Peter Hinch

syrekron
Posts: 8
Joined: Thu Mar 03, 2016 5:04 pm
Location: Iowa, USA

Re: Ideas for next evolution of pyboard

Post by syrekron » Fri Apr 29, 2016 8:59 pm

I just found this post. Hopefully I'm not too late to chime in.

Let me provide my input by means of a story.

First, my background. I have been an embedded developer for the past 15+ years using about a half-dozen different architectures at the C, assembly, and HDL level. My passion is to make things work and to control and interface to the real world without sucking. I discovered MicroPython during the ESP8266 kickstarter. I was instantly intrigued as I have been using Python to solve problems on the PC side of things for many years. When the opportunity presented itself I purchased a half-dozen pyboards for a rapid development project at work. I estimate the pyboard cut my development time to a tenth of what I would have expended with a traditional microcontroller development; nevermind the fact that I had never used it before (Hats off to the pyboard and MicroPython!).

Shortly after this experience I was talking with one of my employer’s most senior engineers. He is an idea man. He would like to build controllers for his home solar hot water system. He would like to automate his PV hybrid battery charging system. These are just the start of his ideas. He has the knowledge and the desire but he doesn’t have the time for the boring and painful parts of embedded development. He certainly doesn’t have time to read the datasheet to see how to setup the ADC, SPI or the PWM modules--nor should he have to.

I told him what I had discovered with the pyboard--and how it had made microcontrollers more fun and not tedious as they so often are. The highlights are that the common microcontroller peripherals (and everything on the board) are fully supported, built-in, and easy. Plug-Import-Play, so to speak.

After I had pitched the merits of the pyboard and MicroPython he asked the simple question:
How do I hook it up to the world?
That, I realized is what the pyboard lacks. There are no relays. There are no thermistor/thermocouple inputs. There is no high-endurance FRAM or EEPROM. There are no analog buffers on the ADC inputs that can handle outdoor/industrial voltages. There is no 16x2 LCD interface. The only button is TINY. There are no stepper motor controllers. If you want real-world interface for the pyboard you have to design your own board or deal with a rat's nest of proto boards stitched together--which moves the project back to tedious, un-fun, and impractical for those of us with lots of ideas and very little time.

At first I thought the answer was a micropython board with the ability to use Arduino sheilds. The problem with this approach is that there are so many options for shields that the support complexity increases quickly. It would be near impossible to support more than a small combination of shields from a few vendors (and, as others have noted, certainly not economical).

My current wishful thinking is for a board or an expansion board with real-world (industrial/scientific) interfaces that are fully supported by MicroPython so that the plug-import-play ease of the pyboard remains. I asked my senior engineer friend about what he would like to see and this is the summary of our brainstorming for an outdoor, data logging and controller application board:
  • First, keep the basic pyboard features!
    • MicroSD
      USB UART and mass storage
    I/O with screw-type terminals and transient protection
    • Buffered analog inputs to support wider input voltage ranges (+/- 10V or 0-28V)
      “Open collector” digital outputs
      “Ground-open” or “volt-open” digital inputs
      2 or 3 relays suitable for AC/DC circuit switching
    Solar/interruptible power aids
    • Battery or supercap backed, temperature stable RTC
      Lithium battery charger/fuel gauge
      High write endurance NVM
    Rugged communications interfaces, again with transient protection in mind
    • 10/100 (wired) Ethernet
      RS422 or RS485 serial port(s)
    More “appliance” friendly user interfaces
    • 16x2 character LCD module
      Small key matrix (either on-board or external)
To support these more “real time” operations I would be interested in C implementation of python modules that could support tunable digital filtering of the analog inputs and debouncing of digital inputs. I’d love to see C implementations of tunable PID modules that can drive DAC or PWM modules. The idea being that once initialized, and connected these modules would operate “in the background” with higher and more deterministic performance while leveraging the ease of MicroPython to stitch the system together.

Yes, wishful thinking I know. My take is that MicroPython could be today's Basic or Forth once we can easily hook it up to the world around us.

-syrekron

User avatar
pythoncoder
Posts: 3659
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Ideas for next evolution of pyboard

Post by pythoncoder » Sat Apr 30, 2016 8:45 am

@syrekron Software drivers already exist for many of the things you want. An industrial control board with a Pyboard daughterboard could be designed today.
Peter Hinch

SpotlightKid
Posts: 380
Joined: Wed Apr 08, 2015 5:19 am

Re: Ideas for next evolution of pyboard

Post by SpotlightKid » Sat Apr 30, 2016 12:38 pm

Also note that several STM NUCLEO boards are supported, which include Arduino pin-compatible headers and make it possible to use many Arduino shields - if not out-of-the-box, at least with very small effort, since the principal drivers (e.g. LCD, motors, etc.) already exist (as pythoncoder already pointed out) and just need to be configured for the pin layout.

syrekron
Posts: 8
Joined: Thu Mar 03, 2016 5:04 pm
Location: Iowa, USA

Re: Ideas for next evolution of pyboard

Post by syrekron » Thu May 05, 2016 1:19 am

SpotlightKid wrote:Also note that several STM NUCLEO boards are supported, which include Arduino pin-compatible headers and make it possible to use many Arduino shields
Correct.

I could purchase STM32 boards and Arduino shields and make things work.
Though my purchases wouldn't contribute to MicroPython's continued development.

My point was to suggest a variant of the pyboard rich in industrial/scientific interfaces and peripherals.

Post Reply