Title is inaccurate, it's really designed to be about the size of a USB-C receptacle , the plug is the other side (in this case the part of the cable that plugs in to this board)
Lwrless 2 hours ago [-]
I recently got my hands on an M5Stack NanoC6 (https://docs.m5stack.com/en/core/M5NanoC6), it's also quite small and I'm pretty happy with it. It has onboard IR and a Grove connector, good enough for IoT projects at home.
d0able 53 minutes ago [-]
Very cool, but what about the $ to manufacture? Things get exponentially(?) harder the smaller it is, especially for custom boards.
gucci-on-fleek 30 minutes ago [-]
Looks like it only has 6 discrete components [0], and the pinout on the MCU looks like a standard QFP [1] (and everything else is on larger pads), so I think that you should be able to manufacture this using standard production techniques/manufacturers. But I know hardly anything about hardware, so I may be completely wrong here.
I dream of an open board like the yubikey nano. This is very nice!
antoinealb 51 minutes ago [-]
If you are talking about USB-A Nanos, there is https://tomu.im/, which is very nice and interesting.
tl2do 7 hours ago [-]
I'm interested in this too. I've been using STM32 NUCLEO boards, which are cheap and capable, but even the smallest ones are noticeably larger than this. I'd love to see an STM32 version of this project.
That's it, I'm going back to parallel port cables for everything now.
jasongill 6 hours ago [-]
The parallel port (at least in it's later implementations) actually supports DMA - I'm sure that data exfiltration via the parallel port is hard, but probably not impossible...
Nothing is safe, unfortunately!
toast0 5 hours ago [-]
The parallel port controller can DMA, that lets the driver tell the port hey, send this buffer out to the port and let me know or read this many bytes into this buffer and let me know. It's not peripheral controlled DMA like with firewire or PCI.
You can absolutely exfiltrate data via the parallel port... that's why you attach printers or zip disks... it's just that it needs host participation.
throwup238 3 hours ago [-]
It’s almost certainly impossible on modern systems. The southbridge which allowed DMA to parallel port was absorbed into PCH and slowly stripped of legacy LCP support by chipset and motherboard manufacturers.
chrisallick 7 hours ago [-]
This looks awesome, I'd love to get one. Question, what's the advantage over something like the ESP32C3 and the like? Just even smaller?
rkagerer 7 hours ago [-]
If it helps, I've used earlier Atmel AVR chips, as well as the ESP32-S3.
8-bit AVR is an extremely clean, relatively simple instruction set that can be viably hand-coded. It's fairly straightforward to calculate the exact number of cycles your code will use, which is handy for applications requiring deterministic timing and for knowing worst-case execution time of interrupt handlers.
If the C3 instruction set is anything like the S3, I'm willing to bet it's not as straightforward.
Atmel also tends to do a better job of their documentation. I've lost count of how many confirmed errata I've reported to Espressif, and the time (and steam) I lost troubleshooting them in the first place.
I like the S3, and it's heaps powerful, but for small projects that don't need advanced peripherals like Wifi, DMA, etc. I can envision that AVR as being a fine choice.
girvo 6 hours ago [-]
> If the C3 instruction set is anything like the S3, I'm willing to bet it's not as straightforward.
Its not, not really anyway. The Xtensa LX7 in the S3 is very weird, though also quite fun to play with. The C3 is RISC-V
rkagerer 6 hours ago [-]
Thanks for correcting me. Are there any good, small "Hello World" examples of RISC-V programming with the C3 you can point me to? I'd love to get a sense of how it compares in practice.
claytongulick 2 hours ago [-]
I'll second this.
Doing asm on the AVR is beautiful, you can count clock cycles easily and then observe them on the scope.
I wrote a bit banging serial interface for an AVR once and had a mystery when I was testing it from a PC just with a basic echo. Every Nth character would be wrong. Was able to figure out a timing problem by counting clock cycles and found the bug in my code.
Was cool to see it align with what I was seeing on my oscilloscope.
It's a much less fancy cpu that's very small. No wireless. Lower powered I would expect. But it's an MCU with something like 16KB of flash and 2KB of ram if I remember right. The analog stuff on it is supposed to be pretty good. The Anduril flashlight firmware (toykeeper.net/anduril) is a somewhat popular application that can run on it.
tgsovlerkhgsel 7 hours ago [-]
> Lower powered I would expect
With the right software, ESP32 can be incredibly low power. Like "months on 3xAA batteries" for watching a pin with the ultra low power subsystem and then occasionally waking up and making a HTTPS call over WiFi.
pcdoodle 7 hours ago [-]
[dead]
vdcjhhhcfdd 4 hours ago [-]
That's not a plug. To be precise, that's the opposite of a plug xD
[0]: https://github.com/user-attachments/assets/0f7962d5-38e1-4bd...
[1]: https://en.wikipedia.org/wiki/Quad_flat_package
This is an stm32l432kc in the form of a yubikey nano.
https://shop.hak5.org/products/omg-cable
https://phreakboutique.com/blogs/tutorials/using-your-new-ev...
thats how the grift starts...
Nothing is safe, unfortunately!
You can absolutely exfiltrate data via the parallel port... that's why you attach printers or zip disks... it's just that it needs host participation.
8-bit AVR is an extremely clean, relatively simple instruction set that can be viably hand-coded. It's fairly straightforward to calculate the exact number of cycles your code will use, which is handy for applications requiring deterministic timing and for knowing worst-case execution time of interrupt handlers.
If the C3 instruction set is anything like the S3, I'm willing to bet it's not as straightforward.
Atmel also tends to do a better job of their documentation. I've lost count of how many confirmed errata I've reported to Espressif, and the time (and steam) I lost troubleshooting them in the first place.
I like the S3, and it's heaps powerful, but for small projects that don't need advanced peripherals like Wifi, DMA, etc. I can envision that AVR as being a fine choice.
Its not, not really anyway. The Xtensa LX7 in the S3 is very weird, though also quite fun to play with. The C3 is RISC-V
Doing asm on the AVR is beautiful, you can count clock cycles easily and then observe them on the scope.
I wrote a bit banging serial interface for an AVR once and had a mystery when I was testing it from a PC just with a basic echo. Every Nth character would be wrong. Was able to figure out a timing problem by counting clock cycles and found the bug in my code.
Was cool to see it align with what I was seeing on my oscilloscope.
With the right software, ESP32 can be incredibly low power. Like "months on 3xAA batteries" for watching a pin with the ultra low power subsystem and then occasionally waking up and making a HTTPS call over WiFi.