For details, see: https://github.com/tinygo-org/tinygo/pull/3927
This change just means we need to be more careful to use the right type,
now that types like C.uint32_t don't match to the Go equivalent (like
uint32).
See https://github.com/tinygo-org/drivers/pull/401 for details.
I haven't converted it to autogenerated assembly because AVR is
different from many other architectures (8-bit, among others) and it
didn't seem worth the effort as many chips run at 16MHz anyway.
I ran the two AVR smoke tests for the ws2812 driver and the resulting
binary is exactly the same.
This is better for various reasons:
* I don't like the inline assembly implementation in TinyGo. It kinda
works, but it's hard to use correctly.
* The Go version had a subtle bug: the i and value variables weren't
marked as modified. The compiler produced correct code by chance. In
GCC-style inline assembly, it's possible to correctly mark it as an
input+output operand.
* LLVM 14 has some changes to inline assembly that change how memory
operands can be created. Instead of supporting that, I'd like to get
rid of memory operands entirely (and possibly inline assembly in
general).
I did some light testing: the ARM assembly changed a bit but not in any
way that should have a practical effect, and the RISC-V assembly didn't
change at all.
The possible branch distance is a lot shorter on ARMv6M (Cortex-M and
Cortex-M0+) for conditional branches. Therefore, convert this long
conditional branch into an unconditional branch.
This probably makes the code a little bit slower but because it is in
the low period of the WS2812 signal it shouldn't matter for the
protocol. And it avoids difficult workarounds specifically for the
RP2040.
The WS2811 has a slightly slower data rate, but it is close enough that
a single library can support both LEDs at the same time. In my testing,
this package was already compatible with WS2811 LEDs before this change
when running at 4-5V, but when the voltage dropped to 3V or so the LEDs
started misbehaving. With these improved timings, the LEDs remained of
the correct color even at very low voltages (although blue was starting
to fade due to lack of voltage - that's not a software/protocol issue).
Previously, a new implementation had to be written for each processor
speed. This is tedious and error-prone, therefore I've rewritten all of
the assembly code using a tool that will calculate exactly how many NOP
instructions are required.
I've also switched from build tags to a switch statement over all
processor speeds.
All in all, this means that:
- Chips with a supported CPU performance will automatically be
supported (no build tags necessary).
- Adding a new chip is as easy as adding the MHz count to the
generator script and to the switch statement.
Right now this is only for the Cortex-M, but it's certainly feasible to
extend this to other architectures such as the AVR.
* Merge AVR support for Digispark and non-Digispark
* Fix the error "inline assembly requires more registers than available"
* Use a single file for all AVR targets, in a similar style as the
Xtensa support.
This patch adds support for the ESP8266 chip by adding support for 80MHz
operation. This should also work when the ESP32 is changed to 80MHz, but
I didn't test it (as there is not currently a way to do that).
Verified on a NodeMCU dev board with an ESP8266.
This allows WS2812 LEDs to be controlled by an ESP32. Right now it only
supports 160MHz operation, which is the default with current ESP32
support in TinyGo.
Named local labels shouldn't be used in LLVM because they might get
duplicated resulting in multiple symbol definitions and a compiler
error. Instead, use numeric labels.
This adjusts the timing for 120MHz as seen on atsamd51 boards. The
timing was kept as close as possible to the Cortex-M4 64MHz logic in
ws2812_m4_64m.go.
Tested: This works on ItsyBitsy-M4
This has cost me _hours_ to find. There are many clones of the ws2812
and they have slightly different timing characteristics. Some don't work
so well when you get close to the minimum T1H time: a 1-bit may be
interpreted as a 0-bit.
This commit adds support for the nrf52, which is a Cortex-M4 running at
64MHz.
While implementing this, I discovered that the timings for AVR/16MHz and
Cortex-M0 at 16MHz weren't quite right. They do work, but were slightly
out of spec. So I fixed this as well.
Ayke van Laethem
Leon Matthews
SoftTacos
deadprogram
Olaf Flebbe
BCG
sago35
Daniel Bridges
Alan Wang
Jonathan Basseri
Brad Erickson