In addition to that it would also require same pinout for stuff connected microcontroller. If pinout differs then most of work will have to be redone anyway and it doesn't matter nearly as much whether it's Attin48, any other AVR microcontroller or maybe even completely different microcontroller as long as toolchain is reasonably available and easy to use.
Well, the ground work has been laid out for you, so feel free to gross out your friends/family/coworkers/foes :P
For maximum creepiness, I recommend adding a small speaker. And a covert way to have it act perfectly normal, so you can say "it never does that for me" followed by a quick demonstration (most simple: have it misbehave with some chance, and then have it behave normally until a number of requests have been made or a timeout hit).
AVRs are still pretty popular, and I think that predates the Arduino frenzy (starting about 2005). If you disassemble a bunch of devices in your house, you might find a few of these.
E.g. when I went to replace a faulty switch on my Logitech Perfomance MX mouse, I found an ATMEGA324PA. Debug pins seem to be exposed as well: https://steelcityelectronics.files.wordpress.com/2015/05/img... (not my site).
But since I still use that mouse, I'd hesitate to flash the Arduino firmware on it ;-)
Another ICs for shenanigans of this kind: In smaller, bluetooth-enabled devices I usually expect to find a nrf5x these days (and FCC docs often allows pre-purchase clarification). I think both nrf51 and nrf52 are supported by Arduino and ZephyrOS. Bonus points, though I not yet tried that: Their firmware dumping protection seems to be faulty (though the nrf52 requires power fault injection), so reverting/modding could also be an option.
I write firmware for nrf52 series chips. They are an absolute joy to work with. The sdks are well supported and there’s ample documentation/forums if you run into an issue.
11 comments
[ 2.7 ms ] story [ 38.5 ms ] threadFor maximum creepiness, I recommend adding a small speaker. And a covert way to have it act perfectly normal, so you can say "it never does that for me" followed by a quick demonstration (most simple: have it misbehave with some chance, and then have it behave normally until a number of requests have been made or a timeout hit).
E.g. when I went to replace a faulty switch on my Logitech Perfomance MX mouse, I found an ATMEGA324PA. Debug pins seem to be exposed as well: https://steelcityelectronics.files.wordpress.com/2015/05/img... (not my site). But since I still use that mouse, I'd hesitate to flash the Arduino firmware on it ;-)
Another ICs for shenanigans of this kind: In smaller, bluetooth-enabled devices I usually expect to find a nrf5x these days (and FCC docs often allows pre-purchase clarification). I think both nrf51 and nrf52 are supported by Arduino and ZephyrOS. Bonus points, though I not yet tried that: Their firmware dumping protection seems to be faulty (though the nrf52 requires power fault injection), so reverting/modding could also be an option.
From my experience and he newer nrf52 chips are vastly more supported by software than the nrf51 ones.