Development boards with a USB Type-C port for power and programming are becoming more common, most in most cases with a female USB-C port.
Designed by arturo182, Serpente R2 CircuitPython prototyping board based on Microchip SAMD21 Arm Cortex-M0+ microcontroller offers three USB power & programming option with USB type-A male, USB type-C female, or USB type-C male, with the latter option allowing you to plug into directly into your host computer.
Serpente R2 board specifications:
- MCU – Microchip ATSAMD21E18A 32-bit Cortex-M0+ running at 48MHz, with 256KB flash, and 32KB RAM
- Storage – 4MB SPI Flash for storing files and CircuitPython code
- Expansion – 10x I/Os with castellated holes including 6x customizable GPIOs, and 4x power signals (3V, GND, VUSB, and VIN)
- USB
- R2 – Female USB Type-C port
- R2 Plug – Male USB Type-A port
- R2 Plug C – Male USB Type-C port
- Misc – User RGB LED, reset button
- Power Supply – 5V via USB port or VIN; 250mA LDO; 3.3V logic and power
- Dimensions
- R2 – 24.75 x 22mm
- R2 Plug – 29.55 x 22mm
- R2 Plug C – 25.35 x 22mm
The board is open source hardware (See KiCAD files on Github) and is meant to run Adafruit CircuitPython, and you’ll find pretty-looking documentation here.
Serpente R2 board is sold on Tindie for $15, but you can get a 25% discount with “@arturo182” code.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Amazing how many low-cost SAMD21 breakout/eval boards.. however, they all capable of compatible to run CircuitPython ? Or is there some pinout/layout of the Serpente R2 that makes it better?
How do they compare to blue pills, though? Those are pretty darn cheap as well and are well supported by Arduino IDE at least.
https://www.cnx-software.com/2019/07/05/samd21-mini-wemos-d1-samd21-m0-mini-development-board/
You can get 10 bluepills for 1 Serpente 🙂
New 2 bluepills come with STM32F4 series, and max out to 512KB flash, 128KB ram, 36 I/O, integrated FPU.
Price point just around $4.
https://www.aliexpress.com/item/4000103610226.html
I doubt there is any *magic* involved but the I/O layout/configuration may have been hard coded into the language interpreter. I think the interpreter is open source so this could be changed with enough effort.
I’m no expert on CircuitPython but from what I’ve gathered from the web, code is stored right on the device in text format. This makes things simple and easy but is highly inefficient for a real world app— not to mention highly insecure as well. It should take minimal know how to extract code or reprogram the device.
>I’m no expert on CircuitPython but from what I’ve gathered from the web,
>code is stored right on the device in text format.
MicroPython (and therefore CircuitPython) support pre-compiled/processed byte code. This is how the built in modules are shipped in most cases.
>This makes things simple and easy but is highly inefficient for a real world app
It really depends. Python code is no good for bit banging or doing any sort of data processing but if you have that stuff in prepackaged modules written in C then you can very much make a “real world app” by plumbing the C functions with Python. Look at OpenMV for a good example of this.. doing any image processing in Python directly is insanely slow but wiring together the functions written in C from the OpenMV modules lets you wire together some pretty complicated apps that perform well enough to be usable.
>— not to mention highly insecure as well.
>It should take minimal know how to extract code or reprogram the device.
If I can pull your python code I can just as well pull your thumb binary code and chuck it into hopper or IDA. The reverse engineering process might be a bit harder but unless you think “security by obscurity” is going to help then it’s not any more secure. If your thumb code or python code are stored in flash you can’t easily read out (i.e. inside the mcu package) or you have external flash encrypted with keys inside the mcu the level of code security is the same whatever the code running looks like.
*Anything* can be reverse engineered — it’s all a question of the time, effort and skill required.
On a scale of 1 to 10, plugging a device into a USB port to access the source code in text format has to rank about 0.
If I can plug it in and get your python code and the built in modulles etc I would need to reverse engineer it I can also go in and get your thumb code. You said plain text is a security issue.
Most microprocessors provide fuse locks to make it hard to just read the binary code.
Once you get past these and obtain the code, you still have to reverse engineer it which typically provides assembly code without much syntax.
All of which can be done — but requires significantly more time, effort and know how than a simple USB plug operation. — which is essentially no security at all.
>Most microprocessors provide fuse locks
>to make it hard to just read the binary code.
If your python scripts are in the internal flash it’s just as well protected as the thumb code and your data that’s also in the flash. The format the code is in makes no difference to the security of the data.
MCUs designed for secure applications usually provide a way to disable flash readout along side OTP keys to encrypt external storage.
>Once you get past these and obtain the code,
>you still have to reverse engineer it which typically
>provides assembly code without much syntax.
Probably not as hard as you think. All of the common libraries people plumb together can make it very easy to find out where interesting stuff is.
And in the micropython case you might have the python top level code but you might also need to reverse engineer the thumb code for micropython and any modules that are written in C to make any sense of it.
>All of which can be done — but requires significantly more time, effort and >know how than a simple USB plug operation.
I think you’re talking out of your arse to be honest.
Are there really that few GPIO on that chips such that they have to share them with the LED? That makes them almost useless as inputs.
That was my mistake when doing a copy-paste, the LED uses separate GPIOs.
Thanks for the clarification!
I’ve been given an updated pinout diagram and edit the post accordingly.