Problems debugging and a proposal.

[DazWilkin]

Problem

I don't understand why this simple example does not work correctly:
https://gist.github.com/DazWilkin/7c6daa9c6048d8b5761831a7420f603c

enumerate correctly enumerates each LED in turn so I know I'm deploying code and that all the LEDs work. However, display incorrectly repeatedly flashes (every second, OK) the LED that corresponds to machine.setLEDMatric(4,4); I intend display to render the provided number using the LEDs as its binary digits.

I tried replacing the binary operators (&1 and >>1) with their equivalents (%2 and /2) but it makes no difference. So, then feeling crazy, I repro'd the code in The Go Playground and it works as expected: https://play.golang.org/p/jBSgaIlNK1R

Debugging

Is there an obvious way to debug tinygo code? There's no local debugger (see below) and a limited set of outputs on a device for logging. Are there obvious best practices for this that elude me?

Proposal

Has any thought been given to a virtual device and possible an emulator that would run on the host machine? Simplistically, if I could replace --target=microbit with --target=vdevice and then run the resulting code locally -- like with The Go Playground 'equivalent` -- I could better test code before deploying it.

I appreciate implementing the machine package using fmt.PrintX commands is likely entirely insufficient but it's better than nothing. A possibly (!?) reasonably simple but more compelling solution would be to implement the vdevice as an HTTP server that would render a basic (exemplar) device, could provide a more elegant manifestation of LEDs and could implement buttons.

[DazWilkin]

I just discovered:

tinygo/src/machine/board_microbit.go

Line 113 in 5569cd1

// Currently limited to a single LED at a time, it will clear the matrix before setting it.

Explaining why my code isn't working as intended.

[aykevl]

So these are really two issues:

• As you discovered, the LED matrix is only partially supported: it can only display one pixel at a time right now. Perhaps it would be interesting to write a fully featured LED display as a driver, following the design in Define common display interface drivers#31? It could use one of the TIMER peripherals for continuous updates (PWM), like in the official micro:bit firmware.
• I have been thinking about providing a virtual device for easy testing/debugging. That would make application development much easier (fast compile + run cycles without flashing). It would be useful to provide a generic device with virtual screen etc. that can for example be shown in a web browser or perhaps directly in a new window. One of the many things that would be useful for TinyGo but cost a significant amount of work...

[DazWilkin]

Thanks the reply!

The issues are correlated because when my code didn't work, I was at a loss as to how to debug.

• I don't understand the issue with the LED matrix. I learned that there are 9 columns and 3 rows (link) but evidently there are other turtles below that too. Is there an explanation as to why SetLEDMatrix doesn't work as expected? That may help me understand what's needed.
• Got it! Yes, it's a non-trivial amount of work. It seems to be the most fruitful solution to the debugging challenge.

[conejoninja]

The led matrix in the micro:bit is multiplexed, that means that the leds can not be set on/off permanently, they need to be switched on/off continuously (and let POV do their magic). In a multiplexed array, you are not enabling an individual led, you are enabling the whole row or column and the led where they cross will light up. This will led to undesired results if you try to light up two or more leds. Here are some more information on the topic : https://en.wikipedia.org/wiki/Charlieplexing

For the micro:bit matrix, I have this example : https://github.com/conejoninja/tinygoexamples/tree/master/microbit/scrolltext that will enable several leds at a time. I had plans to make a driver out of it, but didn't find the time yet to do it.

[DazWilkin]

This is very helpful, thank you. I rewrote my sample app in C using the mbed tooling and was going to try to better understand that implementation. I'll have a look at your code.

[deadprogram]

The core of the TinyGo machine package has changed, and so now more closely resembles some of the architectural features discussed in this issue. See #426 for more on this.

As such, I am going to close this, please re-open, or open new issues, as needed.

Thank you everyone!