Live data from Hacker News

CircuitPython: Programming Hardware in Python

github.com

71–80 of 87 posts

Re: CircuitPython: Programming Hardware in Python

#71
post #2

To be fair, this is really mostly just a rebranded MicroPython...

Support MicroPython. Adafruit has commercial interests - they're building CircuitPython so that people buy their stuff. They're a multi-million dollar corporation, not your mom and pop hobby shop. Instead of doubling down on MicroPython, Adafruit decided to fork it so they can have the right HALs. They should have made a library, contributed to MicroPython and grown the ecosystem. Unrelated, I absolutely despise Adaf…

Out of curiosity which products did you buy and what was different about them?

Also, multi million could mean $2m/year which if you pay your employees well would translate to like 25 employees if you make no profits and only pay salaries.

Lastly, having bought loads of stuff from AliExpress and recently from AdaFruit, the latter absolutely has higher quality items. They are not simply reselling what’s available directly from China but are legitimately designing their own boards which are better thought out than the generic parts you can get for cheaper.

Re: CircuitPython: Programming Hardware in Python

#72
post #16

This certainly feels like magic... until you run out memory. It's probably more useful on microcontrollers with more than 32 kB of RAM.

I built a really fun library to represent I2C modules as a collection of classes to interface with them at various levels that equated to a whole lot of class instances (an instance per register, and an instance per interesting group of registers, and so on)

Really fun in dev...really fun with my small test device. Then I loaded the config for a complicated I2C module and quickly blew out my memory. I was sad that I had to revert to more mundane means of I2C, but whatever.

A newer version of that same board has more memory. Perhaps it could support my mammoth I2C model.

Re: CircuitPython: Programming Hardware in Python

#73
post #16

This certainly feels like magic... until you run out memory. It's probably more useful on microcontrollers with more than 32 kB of RAM.

Adafruit also have a python library called Blinka that enables you to use Circuit Python on devices such as the Raspberry Pi

Re: CircuitPython: Programming Hardware in Python

#74
post #9

I've used CircuitPython for one production hardware project which is in the wild. Safe to say that the increased draw on the included battery and higher memory usage weren't a concern here, but they are both significant. Developer productivity is through the roof though. I'd say the biggest pain points for me (unless I'm missing something/they've added more stuff recently) were created by the lack of support for what…

"Developer productivity is through the roof though." I learned Python after I learned C, C++, Java, Scala, Rust and a few others. I fail to see my productivity going through the roof with Python. It's quite the opposite. Writing initial code is fast, but making it work well - not so much.

This is for embedded programming which is totally different to the sort of programming your thinking of.

Re: CircuitPython: Programming Hardware in Python

#75
post #36

CircuitPython is a toy language made for running on Adafruit's halloween/cosplaying gadgets. It doesn't even support interrupts. Better use Micropython.

What I don’t understand is: what features of Python encourage its use in embedded systems in the first place? Why not F# or Elixir?

For pyboard, it's STM32F4 with about 200Kb of RAM. AFAIK, F# and Elixir target VMs (CLR and BEAM) and it seems unlikely that those VMs plus your code will fit on such a chip.

Re: CircuitPython: Programming Hardware in Python

#76

Earlier quoted context omitted.

any add-ons that you’d recommend? or other stuff for kids playing with Python? maybe an arduino board plus a raspberry pi?

Depends on the level of abstraction you and your kid are willing to get into. Arduino's are lower-level C/C++ which may be a little more complex than CP, but have much broader library support (better intro to EE/embedded). RPis are much higher level which could be programmed in any language (better intro to CS/Linux).

for kids, so ideally not as low as C++

Re: CircuitPython: Programming Hardware in Python

#77
post #14
post #9

I've used CircuitPython for one production hardware project which is in the wild. Safe to say that the increased draw on the included battery and higher memory usage weren't a concern here, but they are both significant. Developer productivity is through the roof though. I'd say the biggest pain points for me (unless I'm missing something/they've added more stuff recently) were created by the lack of support for what…

Out of curiosity, what about this particular project made you opt for CircuitPython? Was it something targeting hobbyists and wanting to allow them to tinker with it? I'm not trying to put it down because I like CircuitPython, but I would not even consider it for a general production device.

> Out of curiosity, what about this particular project made you opt for CircuitPython?

It was a nonprofit-style project without much wiggle room. We wanted to prove that an idea would or would not work in a small amount of time, which happily overlapped with the fact that the target environment for the device wouldn't require long periods of battery life. I'm happy to say that the project was a success so who knows, maybe one day we'll have someone port it to C and continue from there.

Sorry I can't be more specific.

Re: CircuitPython: Programming Hardware in Python

#78

That’s a very misleading headline. I got the impression this was something akin to VHDL or Verilog or SystemC in python. “Programming Hardware” the way it’s used here is pretty much the same as vanilla python, though I suppose a lot in this industry constantly need reminding of that.

I wrote a toy digital circuit simulator[1] as part of a personal "NAND to Tetris" style project. It has none of the bells and whistles of a full simulator but does illustrate how you could write you own in only a few dozen lines of Python. It also has a kind of neat "declarative" syntax inspired by VHDL/Verilog where components (i.e., Verilog modules, VHDL entities) are defined as regular Python classes and describe their contents. For example, here's a half-adder component, which is comprised of a XOR gate and an AND gate:

    class HalfAdder(Component):
        def __init__(self, a, b, out=None, c=None):
            super().__init__()
            self.a = self.input(a)
            self.b = self.input(b)
            self.out = self.output(out)
            self.c = self.output(c)

            XOR(a=self.a, b=self.b, out=self.out)
            AND(a=self.a, b=self.b, out=self.c)
having to declare each pin as input or output adds a lot of boilerplate; I was hoping to add a feature where input/output information could be declared using type annotations in the function signature itself. That would look something like:

    class HalfAdder(Component):
        def __init__(self, 
                     a: input, 
                     b: input,
                     out:output = None, 
                     c:output = None):
            super().__init__()

            XOR(a=self.a, b=self.b, out=self.out)
            AND(a=self.a, b=self.b, out=self.c)
which I think is starting to look pretty Verilog-ish, while still staying Pythonic.

[1]: https://github.com/olooney/circuit

Re: CircuitPython: Programming Hardware in Python

#79
post #9

I've used CircuitPython for one production hardware project which is in the wild. Safe to say that the increased draw on the included battery and higher memory usage weren't a concern here, but they are both significant. Developer productivity is through the roof though. I'd say the biggest pain points for me (unless I'm missing something/they've added more stuff recently) were created by the lack of support for what…

"Developer productivity is through the roof though." I learned Python after I learned C, C++, Java, Scala, Rust and a few others. I fail to see my productivity going through the roof with Python. It's quite the opposite. Writing initial code is fast, but making it work well - not so much.

I know a lot of people for whom both are much more productive in python than in any other language, including myself. If that's not true for you, you must have different preferences.

Let's just find our own language each one and not bash others' choices, maybe?

Post reply on HN