Difference between revisions of "Arduino"
Line 44: | Line 44: | ||
===Blink LEDs from user space=== | ===Blink LEDs from user space=== | ||
− | Ok, you want to blink LEDs from GNULinux userspace. How should you do that? Buy a USB to LED adapter? But that's what an Uno is for. Install Python on the uno? No, too small. Get a micro with micropython? No, | + | Ok, you want to blink LEDs from GNULinux userspace. How should you do that? Buy a USB to LED adapter? But that's what an Uno is for. Install Python on the uno? No, too small. Get a micro with micropython? No, we are using an Uno here, not ARM. Build a custom program and have an API running on the Uno? Too difficult. Ain't nobody got time for that. |
How about ulisp.com. It's an interface, about as scary as octave/matlab (i.e. simple), and it handles all the API stuff for you. | How about ulisp.com. It's an interface, about as scary as octave/matlab (i.e. simple), and it handles all the API stuff for you. |
Revision as of 05:08, 19 January 2021
Arduino is a software library for AVR microcontrollers (and others). It is aimed at fast prototyping, sometimes at the cost of performance. It has extensive libraries and software for many popular ICs. Elitists will hate on Arduino, but that's mostly because they don't want you to be successful.
Convert Uno code to ASM
apt-get install binutils-avr
compile program in IDE. find .elf file (was in deb 9 /tmp/arduino-build.#####/) (can look at verbose arduino compile window)
avr-objdump -S code.ino.elf > output.asm
See gas sensor, or ph sensor in 2019 projects for more details
Ref: https://forum.arduino.cc/index.php?topic=50169.0
Here's a script:
#!/bin/bash #run this script from /tmp/arduino_build_#### folder #$0 will be this script. $1 will be the .ino file to parse. #omit the .elf part #e.g. ./gen_debug.sh shiftin_try6_wLED.ino DIR=debug_files mkdir $DIR avr-objdump -S $1.elf | c++filt > ./$DIR/$1.ASM readelf -a $1.elf > ./$DIR/$1.READELF #note: sometimes strings needs to be adjusted when rev engineering. strings $1.elf > ./$DIR/$1.STRINGS file $1.elf > ./$DIR/$1.FILE #nm, could potentially be used for object files in build/libraries folder nm ./sketch/$1.cpp.o | c++filt > ./$DIR/$1.NM # cpp.d has directory paths. might be useful in 10 years when you try to build again. cp ./sketch/$1.cpp.d ./$DIR/. #reference: The IDA Pro Book, by Chris Eagle #and https://forum.arduino.cc/index.php?topic=50169.0 # that's all for now
Blink LEDs from user space
Ok, you want to blink LEDs from GNULinux userspace. How should you do that? Buy a USB to LED adapter? But that's what an Uno is for. Install Python on the uno? No, too small. Get a micro with micropython? No, we are using an Uno here, not ARM. Build a custom program and have an API running on the Uno? Too difficult. Ain't nobody got time for that.
How about ulisp.com. It's an interface, about as scary as octave/matlab (i.e. simple), and it handles all the API stuff for you.
Here's a valid use of ulisp. When I first saw this program I tried it out, but ran out of steam. What's the point of using ulisp on a dedicated Uno at my lab bench when I can just compile C...? But that's the wrong angle. You have to see it from: What if I want to control an Uno from my PC (not my lab bench), without actually touching the Uno, or otherwise putting any serious time into it. ulisp is handy when its used via the serial port as an interpreter to do live uno blinking. It's not really useful when you want to make a hardware device that only needs to be compiled once.
So
lab bench and uno, for a product that will eventually run in the field ---> C pc workstation and uno to blink leds ---> ulisp
And it should be trivial to program Linux to use the IOs via serial port for whatever you desire. This is less a hardware device, and more a way to control LEDs via user space.