BLOG.txt

1bhpzy.jpg

1bhq25.jpg

1bhq25.txt

2023-11-22: nota bene: bench notes
----------------------------------

- using tinyhands devboard
  - lit rail with regulated 5V
  - still waiting on capacitors to clean line
  - soldered board-to-wire with terminal block on 12V supply
  - need 5V for RTC DS1307
  - soldered board-to-wire PH connector to GPIO 16, 17 (I2C SDA, SCL), (pin 21, 22)
  - breadboard wired module
  - started tinyhands: clocker

1bhq26.txt

2023-11-21: nota bene: bench notes
----------------------------------

- using tinyhands devboard
  - solder board-to-wire female PH 2.0mm cable
  - to be used as neopixel 12 ring
  - pin 29 (GPIO 22), 5V/GND power rail
  - soldered board-to-wire male JST cable
  - to be used for neopixel 20 strip
  - pin 20 (GPIO 15), 3.5V/GND power rail

- anonymous pico on breadboard
  - goal: power with external 12 V power supply
  - have voltage regulator
  - vsys (Pin 39) jumper to ~4.5 power rail
  - waiting on capacitor kit
  - success!
  - neopixel 144 strip JST cable
  - pin 21 (GP 16), 5V regulated power rail
  - success

1bhq2a.jpg

1bhq2c.jpeg

1bhq2l.jpg

1bhq4q.jpg

1bhq4q.txt

2023-10-28
----------

N.B. on Bluetooth stacks for tinygo on BBC micro:bit v2.

Tinygo bluetooh
<https://github.com/tinygo-org/bluetooth?tab=readme-ov-file#version-2> does not
document how to flash a Bluetooth LE stack to my microbit. Herein, I record my
debugging process.

- the device has a nRF52833 chip with CMSIS-DAP interface to program the flash.

- we have to flash a SoftDevice image (which includes the Bluetooth stack) to be
  able to interface with the Bluetooth radio.

- there are a bunch of different versions involved.

- if I read the compatibility matrix correctly, the chip supports SoftDevice
  stacks S113 SD, S122 SD, S140 SD.

- notably, the last one is supported for nRF52832 by tinygo.

- tinygo has a target for microbit-v2-s113v7, which implies to me S113 SD (v7?).

- tinygo-org/bluetooth/s113_nrf52_7.0.1 seems to be code for S113 SD for nrf52
  devices? 🤔

- microbit.org claims S113 SD <https://tech.microbit.org/bluetooth/> the
  compatibility matrix suggests S113 SD version 7.0.1 might work.

- let's try! first, copy the SD hex file: cp
  tinygo-org/bluetooth/s113_nrf52_7.0.1/s113_nrf52_7.0.1_softdevice.hex.

- next, flash the demo: tinygo flash -target microbit-v2-s113v7 -programmer
  cmsis-dap ./bluetooth it seems important to have the hex file on the device
  prior to calling tinygo flash and to include exactly this target and programmer.

I'd really like to figure out how to flash out of band because my development
process often begins on a laptop and ends up flashing the code using a desktop
Raspberry PI. This is a bit weird but gives me the ability to remote flash the
device and makes some things easier for me.

For now, flashing from the Laptop with a serial cable seems okay.

1bhq4u.txt

2023-10-25
----------

N.B. I found this a lot easier than auto-mounting using either systemd-mount or
usbmount on Raspbian:

         $ pmount -wA --umask 000 /dev/disk/by-label/MICROBIT /media/microbit

This will mount the disk with file-system label MICROBIT. The device is writable
with the -w flag and shared for all other users with the --umask flag -- the -A
enables asynchronous writes or a writeback cache. The sync command will wait for
the cache to be flushed.

With this approache, I must remember to unmount the device or, maybe, just run
the sync command a couple times, before pulling the controller's from the host.

         $ pumount /media/microbit

With systemd, I couldn't figure out how to set the permissions and ownership to
the user account; usbmount seemed to work best with devices mount with
synchronous writes. That might be okay in this case; but I still couldn't get it
to work.

1bhq4w.png

1bhq4w.txt

2023-10-22
----------

        It must be your friends, in some sense, who make you famous by quoting
        and citing you, and it pays, so I claim, to be helpful to others as they
        try to do their work. They may in time give you credit for the work,
        which is better than trying to claim it yourself. Cooperation is
        essential in these days of complex projects; the day of the individual
        worker is dying fast. Teamwork is more and more essential, and hence
        learning to work in a team, indeed possibly seeking out places where you
        can help others, is a good idea. In any case the fun of working with
        good people on important problems is more pleasure than the resulting
        fame.

Richard W. Hamming, "The Art of Doing Science and Engineering -- Learning to Learn".

1bhq4w2.jpg

1bhq4x.png

1bhq4x2.go

1bhq4x4.png

1bhq55.txt

1bhq57.txt

go.mod

If I have enraged or delighted you with something here, you can do any of three things:

• ignore the feeling and move on with the rest of your life; (recommended)

• email me; (I'd like that)

• or, leave a comment on this Gist with a reference to the post to which you are responding. Something like:

  Regarding https://gist.github.com/smoynes/756cbbefba909ffbf9bc7278ae04aced#file-1bhq56-main-go,
  what do?

  Or,

  Re: 1bhq56-main.text, this is outrageous and unacceptable to Gentlemen of Property and Ladies of
  Good Taste. I bid you adieu! 🎩

The is not a user-friendly method of publicly commenting on content; that is the point: marginal utility in intentional obscurity. One gets the rewards of the effort one puts in.