…ropriately

… writing firmware

…v8-M main profile

…adability in the USB configuration setup code

…per use of atomics, resulting in smaller and more correct code

… and track

…roper use of atomics, resulting in smaller and more correct code

…change notifications so it's a little more responsive without being overwhelming for traffic

…correctly and the pins are driven suitably hard

…ead machinary

…the on-board Flash

… function that requires `target` to be a valid non-NULL pointer

…rd response when the argument decoder fails

…d understand

…K blocks as found on the Lattice Versa boards

…nk v2 firmware to make things fit again

…and stubs for manipulating it

…ulation to implement Flash functions

…ut of programming mode

… ispCLOCK

…lock_flash_erase`

…ommand

This was found by looking at the JTAG traffic the lattice diamond programmer generated when programming the ispCLOCK device, and the name was extracted from a JED for the ispCLOCK being converted to an svf file, as the name for this command was included in a comment in the resulting file.

…_done`

These now properly handle the setup and exit for programming ispCLOCK devices

…e attached ispCLOCK device.

After much mucking about and trying to figure out what the lattice programmer was doing and how much of it is required, the method for properly programming the ispCLOCK devices was figured out, which does include wiggling TCK, for some reason....

This is used so we can verify the contents of the the ispCLOCK device and ensure that the correct configuration for it was written

* Extract the memory write into a dedicated helper function
* Wrap it into TRY-CATCH macros
* Drop the extraneous 10ms delay introduced back in PR2072