Skip to content

Latest commit

 

History

History
50 lines (41 loc) · 4.19 KB

0002-2019-12-02.md

File metadata and controls

50 lines (41 loc) · 4.19 KB
Raw

2 Dec 2019

  • Sample programs for Digispark.

  • Arduino programs are called "Sketches", have file extension .ino, are recognised as C++ but typically don't need most headers, use setup() and loop() instead of main(), and must be placed in a folder that is the name of the Sketch in order for the Arduino IDE to accept them -- it asks to do this step for you, if necessary.

  • Arduino 1.8.5 can't build AVR code on macOS 10.15: It's a 32-bit executable, and macOS 10.15 now only runs 64-bit.

  • Downloaded Arduino 1.8.10 IDE for macOS from here. Extracting gives Arduino.app, which I copied to /Applications. Launching is annoying, as macOS reports:

    “Arduino” can’t be opened because Apple cannot check it for malicious software.

    This software needs to be updated. Contact the developer for more information.

    Chrome downloaded this file today at 2:33 pm from www.arduino.cc.

    After this: Apple menu => System Preferences... => Security & Privacy => General, then:

    "Arduino" was blocked from use because it is not from an identified developer.

    Click Open Anyway. It still reports the error, but at least it launches now.

  • There's more... the Digispark version of avr-gcc is still too old. There are two possible solutions here. I used the 2nd.

  • Verifying (compiling) 01-blinky yields:

    Sketch uses 712 bytes (11%) of program storage space. Maximum is 6012 bytes.
Global variables use 9 bytes of dynamic memory.

    NOTE: On my Windows 8.1 machine, running the older avr-gcc (Digispark's default) makes a program that uses 700 bytes instead of 712.

  • I went to program it on my Windows 8.1 MS Surface 1 machine. "Upload" button in Arduino IDE got to the waiting-for-plugin stage. When I plugged in the Digispark, though, it took about 10 seconds before Windows seemed to wake up and recognise it as a USB device. It should've been recognised pretty quickly, but instead the "device plugged in" sound was delayed by quite a bit, and then a window popped up in the background, probably saying that Windows was checking for device drivers, etc. Hence, it wasn't properly detected by micronucleus. The next time I plugged it in, it seemed to work fine, though, and was programmed. Sometimes, though, it just doesn't work, giving a "USB device not recognized" error (after the bootloader's 5-second timeout).

  • In 02-blinky2 I tried toggling the LED pin with:

    digitalWrite(LED, ~digitalRead(LED));

    ...i.e. writing the complement of a read from the LED pin, back to that LED pin. This doesn't work though, I think because digitalRead() and digitalWrite() work on simple boolean values, where a read might return 0b00000001 and its complement is 0b11111110, hence getting permanently stuck on. The solution is to do this instead:

    digitalWrite(LED, !digitalRead(LED));

  • C++ operator precedence says that multiplication, division, and remainder should be equivalent, and just work in left-to-right order, but I was finding possible differences in how these two lines would compile (from 05-blinky5):

    unsigned long slot = ((millis()-start)/(PERIOD/SLOTS)) % SLOTS;
unsigned long slot = ((millis()-start)/PERIOD*SLOTS) % SLOTS;

    They should be equivalent (given removal of parentheses around PERIOD/SLOTS), but only the first line works. With the second line it just looks like the LED is on all the time. Maybe the problem is actually to do with integer overflows or something, or because there is no pre-calculation on the part of the compiler, meaning that precision is being lost first in /PERIOD and not regained in *SLOTS.

  • Note to read about millis(): https://forum.arduino.cc/index.php?topic=503368.0