Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CircuitPython: Programming Hardware in Python

github.com

Post reply on HN
Print view View original

41–50 of 87 posts

Re: CircuitPython: Programming Hardware in Python

#41

Post by gorgoiler »

xrd wrote: post #37
gorgoiler wrote: post #34

Earlier quoted context omitted.

Circuit Playground is the hardware product that goes hand in hand with CircuitPython , but you’ll probably want to program it using makecode instead. Version 2 called “Circuit Playground Express” is currently very popular. V1 is obsolete, and there’s a version 3 with Bluetooth. All of them are pre-built with sensors, RGB LEDs, and buttons. This removes a huge hurdle: no soldering required. (Soldering is a fun skill b…

This is a fantastic write-up. Thank you. Are the details of your classes online anywhere?

Thanks. I don’t, but you don’t need the structure of a class. My Circuit Playground stuff all happens as an after school club.

I let the kids riff, then review their project before showing them a new idea. It’s like they are learning a modern era computer game where there are no manuals, only self discovered game mechanics.

(CS classes have much more structure but are more niche and for the older pupils.)

Re: CircuitPython: Programming Hardware in Python

#42

Post by pkolaczk »

jscholes wrote: 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.

Re: CircuitPython: Programming Hardware in Python

#43

Post by hulitu »

senux wrote: post #28
dialamac wrote: post #15

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 don't think there's any merit to your argument here. If the headline had said "designing hardware circuits", that would be another story entirely. > “Programming Hardware” the way it’s used here is pretty much the same as vanilla python One can only hope so, since the project is a fork of MicroPython. Neither CPython or MicroPython are meant to be a long departure from Python itself.

> I don't think there's any merit to your argument here. If the headline had said "designing hardware circuits", that would be another story entirely.

One does not "program hardware" except maybe in a CPLD. You cannot write code for a resistor or a tranzistor. You program maybe the microcontroller which is present on the board.

Re: CircuitPython: Programming Hardware in Python

#44

Post by pansa2 »

pkolaczk wrote: post #42
jscholes wrote: 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.

Presumably the parent is comparing Python to C. There’s no way anyone is more productive in C than in Python.

Re: CircuitPython: Programming Hardware in Python

#45

Post by pkolaczk »

pansa2 wrote: post #44
pkolaczk wrote: post #42

Earlier quoted context omitted.

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

Presumably the parent is comparing Python to C. There’s no way anyone is more productive in C than in Python.

If you are forced to write pure C (or a very low level subset of C++) , then that is often because:

- you need every tiny bit of performance,

- you optimize for low executable size or low memory footprint (e.g ATTiny13)

- you have an exotic architecture that offers only a C compiler or ancient C++ compiler from 90s,

- you need to use C for other reasons like safety certification, e.g. MISRA C.

In all of these cases Python wouldn't work at all.

And in the others your can use modern C++ which can be just as productive as Python (in my case it is more productive, but I have probably spent more time with it than with Python, so I'm biased).

Re: CircuitPython: Programming Hardware in Python

#46

Post by stinos »

animal_spirits wrote: post #3
Ecco wrote: post #2

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

It has 7,000 more commits than MicroPython, to say it is a rebrand is unfair.

You probably looked at the 'xxx ahead, yyy commits behind miscropython' bit here and subtracted them to get that number? Even though I agree CP is definitely more than just a rebrand (in fact it's fairly interesting what they did), relating number of commits to the rebranding statement is not entirely correct. Because you're measuring features and/or amount of work done in number of commits, and that is not a simple fixed relationship. Just browse the first couple of commit pages [1] to see what I mean (just 2 examples: a commit with message 'pre-commit' which deletes 4 newlines, a commit with message 'alphabetical' which moves 2 statements around). Could also take a look at the MicroPython commits [2] in turn to see what a, in my opinion, very sane git tree looks like)

[1] https://github.com/adafruit/circuitpython/commits/main [2] https://github.com/micropython/micropython/commits/master

Re: CircuitPython: Programming Hardware in Python

#47

Post by unishark »

senux wrote: post #28
dialamac wrote: post #15

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 don't think there's any merit to your argument here. If the headline had said "designing hardware circuits", that would be another story entirely. > “Programming Hardware” the way it’s used here is pretty much the same as vanilla python One can only hope so, since the project is a fork of MicroPython. Neither CPython or MicroPython are meant to be a long departure from Python itself.

> If the headline had said "designing hardware circuits", that would be another story entirely.

It almost does though. The name of the project has "circuit" in it (I guess because of Arduino applications or something?), and if you are confused why we're talking about circuits, well you can read on where the title goes on to double down on being about "programming hardware".

Re: CircuitPython: Programming Hardware in Python

#48

Post by duggan »

craftinator wrote: post #25
jscholes wrote: 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…

Surprised you didn't use at least MicroPython. I think Python on embedded in general is not great in a production setting, but at least MicroPython has widespread usage; CircuitPython is aimed at being a toy language for beginners.

CircuitPython describes itself a fork of MicroPython, with the major difference being its deployment workflow. What makes it a “toy” by comparison in your book?

Re: CircuitPython: Programming Hardware in Python

#49

Post by aweb »

jonwest wrote: post #8

I know there’s some half decent support for ESP boards with MicroPython, is that also the case for Circuit? Getting Adafruit gear in Canada is prohibitively expensive in comparison unfortunately, as much as I’d like to support the creator.

I looked at it in depth, they unfortunately don't seem to support anything else than ESP32-S2. To be honest, MicroPython is pretty good and you can use it without missing CircuitPython
Post reply on HN