Difference between revisions of "Arduino"

From Steak Wiki
Jump to navigationJump to search
(Created page with "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 soft...")
 
 
(7 intermediate revisions by one other user not shown)
Line 1: Line 1:
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.
+
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.  
  
 +
 +
[[File:GasSensor.JPG|300px|thumb|right|Arduino Nano as flammable gas sensor.]]
 
===Convert Uno code to ASM===
 
===Convert Uno code to ASM===
 
<code>apt-get install binutils-avr</code>
 
<code>apt-get install binutils-avr</code>
Line 8: Line 10:
 
window)
 
window)
  
<code>avr-objdump -S code.ino.elf > output</code>
+
<code>avr-objdump -S code.ino.elf > output.asm </code>
  
 
See gas sensor, or ph sensor in 2019 projects for more details
 
See gas sensor, or ph sensor in 2019 projects for more details
  
 
Ref: https://forum.arduino.cc/index.php?topic=50169.0
 
Ref: https://forum.arduino.cc/index.php?topic=50169.0
 +
 +
Here's a script:
 +
<pre>
 +
#!/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
 +
</pre>
 +
 +
 +
===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.

Latest revision as of 02:07, 20 May 2024

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.


Arduino Nano as flammable gas sensor.

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.