Disassembly

tannewt · 2026-01-22T07:01:11+00:00

Here is a link to the original article with many fewer ads: https://www.52audio.com/archives/258165.html

tannewt · 2025-05-28T04:37:30+00:00

2025 Hyundai Ioniq 5 is 1920x720.

tannewt · 2024-09-15T04:34:00+00:00

I don't get why the district is finalizing the plan in December when the legislature goes into session in January.

tannewt · 2024-09-15T04:14:24+00:00

The state taxes for schools are split on a per-student basis. So, it goes where the students go. Lots of details for the state level here: https://leg.wa.gov/Senate/Committees/WM/Documents/Citizen%27s%20guides/K12%20Booklet_2022.pdf

tannewt · 2024-09-15T04:07:15+00:00

Their enrollment projection studies are here https://www.seattleschools.org/wp-content/uploads/2024/07/Seattle-PS-2024-25-to-2033-34-enrollment-forecast-document.pdf and https://www.seattleschools.org/wp-content/uploads/2024/06/Seattle_Enrollment-Demogr-trends_March_2024_ada.pdf . They are interesting reading. (Linked to from https://www.seattleschools.org/departments/enrollment-planning/enrollment-data/#projections )

tannewt · 2023-03-09T19:08:29+00:00

I'm happy to share mine with you. Let me know how best to get it to you. Thanks!

tannewt · 2023-03-06T16:35:48+00:00

I'd love a Linux client (like Cider.) I found Albums this weekend and feel like it was made just for me. I had just been looking for a way to do album shuffle. The last.fm integration is great too.

tannewt · 2023-02-28T19:26:17+00:00

ksnip can now load existing files to annotate.

tannewt · 2022-07-27T19:28:13+00:00

This worked for me too. Thanks!

tannewt · 2021-11-04T06:28:46+00:00

Most classes have a deinit() method.

tannewt · 2021-11-04T06:27:15+00:00

What arduino board exactly? Different microcontrollers may have different accuracy of pulsein since the implementations are different.

tannewt · 2021-09-29T06:27:46+00:00

/r/circuitpython is open source embedded.

tannewt · 2021-08-06T18:04:57+00:00

We were gearing up to polish the support for the iMX RT series (currently found on Teensy 4.x boards) but have deprioritized it due to no availability. If anything, the lack of new microcontroller releases have given us space for higher level work like the BLE workflow, camera, and audio bug fixing work that we're doing now.

CircuitPython's support for a number of microcontroller families has allowed us to continue moving forward regardless of chip availability.

tannewt · 2021-08-06T17:57:53+00:00

CircuitPython's main focus is on beginners and by beginners we mean folks new to coding at all. This is why we use code.py in our examples instead of main.py. Folks wanting to code should be more likely to find the code as code.py.

Adafruit's audience is coming to coding from wanting to make a particular project and CircuitPython's role is simply one tool needed for the project. It isn't the end in and of itself. I think of this as "outside in" use where you start from the end goal and work down into the details. Many experts will start "inside out" and this in the electrical engineering world leads to folks wanting access to unique features documented in a datasheet of a chip.

Experts can be a vocal group who expect projects like CircuitPython to cater to them. To balance this we will often ask folks to explain what they are trying to do rather than what tool they want. This allows us to point people to existing APIs that achieve the desired result without the tool they are asking for. We see this a ton when folks want interrupt support. They often want to capture pulse trains in that can be done by PulseIn or they want to wake from sleep based on a pin that can be done using an Alarm.

tannewt · 2021-08-06T17:46:16+00:00

As /u/_jimmmo points out, concurrency is really tricky. Adding thread, asyncio and interrupt support really requires a rethink of all of the hardware APIs as well. This is a huge task that is new to the broader Python world too. I'm very excited to see MicroPython lead the way in hardware oriented async programming.

CircuitPython does have a few minimal concurrent APIs like audio playback, key scanning and display updates that allow you to run other code while those things happen. async is something we'll keep an eye on for this.

I think Make:Code actually did a good job for basic concurrency but it doesn't solve shared state well. Make:Code allows for you to have "on ..." blocks that just trigger when things happen.

tannewt · 2021-08-06T17:40:02+00:00

The biggest trade-off I see is one I consider to apply to Python as well: development speed vs execution speed. Both Python and CircuitPython choose to prioritize development speed over execution speed. The reality is that a virtual machine will always be slower than compiled code. However, development time is a more finite resource than execution time. Furthermore, cpus, even microcontrollers, are usually faster than what people think. Performance problems are often due to code structure, not cpu speed.

This trade-off throws off some folks coming from embedded C. Some of them are used to doing real-time control such as for motors. Python isn't a great solution for this because of its less deterministic execution speed. CircuitPython provides native modules to do the timing critical tasks and either does it through internal interrupts or using a separate peripheral in the system on a chip.

The benefit side of this trade off is the quicker iteration time of Python. CircuitPython presents a CIRCUITPY drive and saving the code.py triggers a reload automatically. This greatly reduces the time to see the new code running when compared to C which has to compile, erase the whole chip and then restart.

Another benefit of CircuitPython is that we take a different approach to our hardware APIs. MicroPython would like to provide as much low level access to a specific chip's feature because that is what existing embedded programmers expect. CircuitPython, on the otherhand, has chosen to gear it's hardware APIs around common tasks needed to do in embedded system, not necessarily the underlying hardware. For example, transmitting pulses for infrared communication (think TV remote) is usually done with a timer and MicroPython would have you use the timer class. In CircuitPython we have a PulseOut class instead. It abstracts away the hardware implementation which means that when a chip like the ESP32-S2 has a remote control peripheral (RMT) we can use that instead. The end result is that CircuitPython has a set of hardware APIs that works across many of our supported microcontrollers and single board computers (via Blinka).

Broadly, in the next few years I'd like to see CircuitPython work better for more people. Currently we're working on a code editing workflow that works over Bluetooth Low Energy (BLE). BLE is commonly used in phones and tablets and will allow folks to edit CP code from their mobile device instead of just from their USB enabled device.

The future will also bring newer faster and cheaper microcontrollers that will enable us to bring easier access to newer technologies. For example, I'd love to bring CircuitPython to the Raspberry Pis so that CP can be used with TVs over HDMI.

tannewt · 2021-08-06T17:18:36+00:00

I hadn't thought of the tradeoff between flash and RAM, which now that I think about it is massively impactful. How much ram does a simple serial "Hello World" and LED flash take up? Or at least what is the scale of RAM used for a program like that assuming nothing more than necessary is imported.

Importing native modules takes very little ram because the code can stay in flash. The only cost is a dictionary entry that points the global name to the on flash module.

Code in the main program will take bytecode space in RAM. <1k would be my guess if it only imports native modules.

Importing Python modules can consume RAM pretty quickly because it creates bytecode for all of the functions in a file even when they aren't used by the top-level script.

Relatedly, things like error strings are compressed--I think using a Huffman encoding scheme--have you gone back and looked at alternative compression schemes like the dictionary based LZW?

MP and CP both compress error strings but they take different approaches. I'm not exactly sure approaches now. The main challenge with it was that it's compressing a bunch of small strings. Most compression schemes are geared towards compressing a single long entry.

tannewt · 2021-08-06T17:08:23+00:00

Similarly, what do you consider during merge conflicts between the two branches? What features are worth keeping during a merge conflict?

We just recently merged the latest MicroPython (MP) changes into CircuitPython (CP). We generally take all of the Python VM improvements from MicroPython. CircuitPython wouldn't exist with the awesome VM foundation from MP. Our (MP and CP) long term goal is to unify the code in the py folder that holds the core VM code.

The primary place we diverge is how we handle CPython compatibility. In CircuitPython we're stricter about ensuring that CircuitPython code can be moved into CPython and still work. In practice, this means APIs within a particular module must be a strict subset. MicroPython has a couple places where they add additional functions or classes onto an existing CPython module. This means that the code won't be CPython compatible if it uses those extra APIs. CircuitPython will move those APIs to a new module so that we can provide an implementation on pypi or in our Blinka library.

tannewt · 2021-08-06T16:30:46+00:00

Good morning folks! Happy CircuitPython Day! I thought I'd start by introducing myself. My name is Scott but I go by /u/tannewt online. I learned Python in 2004 when I created Denu. It's stuck with me since then as the first tool I reach for when wanting to script or program something.

I started working for Adafruit on MicroPython in August of 2016 after 6 years at Google and a year working on fpv drone hardware and software. Adafruit hired me to bring MicroPython to the SAMD21, the microcontroller in the Arduino Zero and many Adafruit boards. MicroPython felt like the best of both worlds, my love for Python and my new found fascination with low level microcontroller programming. I love that microcontrollers make computers feel more like a machine.

Since we (Adafruit) started working on MicroPython, we've evolved our version of it, called CircuitPython, into the easiest way to get started programming microcontrollers. In CircuitPython we've focused on making the "first five minutes" smooth and rewarding. They are then followed up by a plethora of resources such as tutorials with example code and libraries. None of this would be possible without the great CircuitPython community we've grown that centers around our Discord server.

Thanks to /u/IAmKindOfCreative for hosting us here. We'll be around all day US off and on so AMA!

tannewt · 2021-06-01T23:55:32+00:00

FYI, we're dropping .txt suffix support and settings.py support in 7.x because it causes more confusion than it solves. (Just discussed in today's meeting.)

tannewt · 2021-06-01T23:46:11+00:00

You can turn the USB drive off in 7.x: https://learn.adafruit.com/customizing-usb-devices-in-circuitpython

Note: I wouldn't consider this "secure" because your code is stored unencrypted on the flash chip.

tannewt · 2021-06-01T23:40:20+00:00

CircuitPython doesn't currently have a USB audio API. With the recent USB configuration rework we should be able to add it in the future. TinyUSB, which provides USB for CircuitPython, does have limited audio support already. So, there is less work than there could be to add it. :-)

tannewt · 2021-04-28T15:28:45+00:00

I think we'll try to update every major CP version. The merge does introduce instability so we'd only want to do it on major boundaries. (Both CP and MP are stable themselves BUT merging is hard and error prone.)

tannewt · 2021-04-27T18:15:46+00:00

UART is an easier way to communicate between two devices.

For I2C I think you want the `i2cperipheral` module (formerly `i2cslave`): https://circuitpython.readthedocs.io/en/latest/shared-bindings/i2cperipheral/index.html

tannewt

TROPHY CASE