Adding new target for pca10056: s140v6-uf2 #3764
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: deadprogram <ron@hybridgroup.com>
Signed-off-by: deadprogram <ron@hybridgroup.com>
This allows archive/tar to build and pass.
This allows archive/tar to build (but not yet pass).
Signed-off-by: deadprogram <ron@hybridgroup.com>
Signed-off-by: deadprogram <ron@hybridgroup.com>
Signed-off-by: deadprogram <ron@hybridgroup.com>
This test only applies when using the built-in LLVM version. This way, we have a stable LLVM version to test against. Distribution versions of LLVM (especially Debian) tend to be patched in a way that affect the results.
Without this, pointers wouldn't be set to nil. Add some tests.
This makes reviewing PRs a lot easier because I don't have to run this myself :) This only uses the drivers repo so far, which is a good starting point but doesn't include binary size changes for WebAssembly for example. A future change could add some real-world programs to get a better idea of the real-world impact. To be clear: the intention is not to just look at the number at the bottom. It is important to look at the actual size difference to see the overall pattern (like, the difference may be due to a few outlier).
It could be expensive to call Size() three times, and it is unnecessary. Instead, do it only once. This results in a very small reduction of binary size if Zero() is used.
…ble to add comments Signed-off-by: deadprogram <ron@hybridgroup.com>
This reverts tinygo-org#3525, because that change didn't seem to stop the CI failures we have been seeing. Instead, I've added thread support in tinygo-org#3130 which IIRC fixed most of the CI crashes. Re-enabling parallelism should improve the performance of TinyGo a bit on Windows.
This basically reverts tinygo-org#3357 and replaces it with a different mechanism to get to the same goal. I do not think filtering tags like this is a good idea: it's the wrong part of the compiler to be concerned with such tags (that part sets tags, but doesn't modify existing tags). Instead, I've written the //go:build lines in such a way that it has the same effect: WASI defaults to leveldb, everything else defaults to fnv, and it's possible to override the default using build tags.
Signed-off-by: deadprogram <ron@hybridgroup.com>
This is a small change that's not really important in itself, but it avoids duplicate errors in a future commit that adds error messages to //go:wasmimport.
The test is currently empty, but will be used in the next commit.
This is for compatibility with upstream Go. See golang/go#59149 for more context.
Signed-off-by: deadprogram <ron@hybridgroup.com>
Signed-off-by: Rajat Jindal <rajatjindal83@gmail.com>
This only affects chips that aren't supported by TinyGo yet, so this should be a safe change. Importantly, it fixes interrupts on the ATtiny1616.
This refactors gen-device-avr to output two different formats: one for all the existing AVR chips (that don't really have the concept of a peripheral, just a bunch of registers), and one for all the new chips like the ATtiny1616 (tinyAVR 1-series and 2-series) that have peripherals like the Cortex-M chips with type structs and instances. I checked the generated code for all the AVR chips we have support for (atmega1280, atmega1284p, atmega2560, atmega328p, atmega32u4, attiny85) and while the generated Go code did change, it looks safe to me.
This is just support for the chip, no boards are currently supported.
However, you can use this target on a custom board.
Notes:
- This required a new runtime and machine implementation, because the
hardware is actually very different (and much nicer than older
AVRs!).
- I had to update gen-device-avr to support this chip. This also
affects the generated output of other AVRs, but I checked all chips
we support and there shouldn't be any backwards incompatible
changes.
- I did not implement peripherals like UART, I2C, SPI, etc because I
don't need them. That is left to do in the future.
You can flash these chips with only a UART and a 1kOhm resistor, which
is really nice (no special hardware needed). Here is the program I've
used for this purpose: https://pypi.org/project/pymcuprog/
If a pointer value was xor'ed with a value other than 0, it would not have been run at runtime but instead would fall through to the generic integer operations. This would likely result in a "cannot convert pointer to integer" panic. This commit fixes this subtle case.
This is necessary to get tinygo-org#3691 working.
I didn't add this method in the initial PR. Also, I found that a few of my assumptions were incorrect. I've changed the code that configures the pin to make input (floating and pullup) actually work. These chips really are quite different from all the older AVRs.
Signed-off-by: deadprogram <ron@hybridgroup.com>
The regular port access is around 4 cycles, instead of the usual 2 cycles for a store instruction on Cortex-M0+. The IOBUS however is faster, I didn't measure exactly but I guess it's 2 cycles as expected. This fixes a bug in the WS2812 driver that only happens on samd21 chips: tinygo-org/drivers#540
Signed-off-by: deadprogram <ron@hybridgroup.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Tested on actual hardware with blink1 and blink2 examples.
Unlike flashing with the "vanilla" pca10056 target, this new target uses the secondary USB port (not the JLINK one) to flash and keeps the bootloader and softdevice on the device.