-
Notifications
You must be signed in to change notification settings - Fork 34
missing definitions for zero #140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I assume this is related to an unsupported architecture (or more accurately, one that I haven't yet defined in the default config). What's in your |
Thanks for the quick feedback! According to the default definitions for release 0.3.0 the zero board should be defined, but maybe I'm missing something. The following config works like a charm compile:
libraries: ~
platforms:
- uno
- due
- mega2560
- leonardo
# - zero
unittest:
libraries: ~
platforms:
- uno
- due
- mega2560
- leonardo
# - zero but adding zero board all the errors come up compile:
libraries: ~
platforms:
- uno
- due
- mega2560
- leonardo
- zero
unittest:
libraries: ~
platforms:
- uno
- due
- mega2560
- leonardo
- zero |
I think I see the problem, but I'm not sure how to fix it. Somewhere in I'm having trouble getting any good google results for that, which is frustrating to say the least. I assume that SAMD boards are incompatible with any of the list of |
Hi @ianfixes, thanks for your interest. Can this stackoverflow question help with the issue? |
The problem is that I would have to find a way to dump the preprocessor defines from within the Arduino IDE, to test what happens when you select the zero. I guess I could brute-force it by just making a dummy sketch that prints out all the constants I find in |
I'll look for a way too. |
Dealing with another issue (not related to this project) I ran into the following line printed in the IDE console
the intresting part of that is
@ianfixes can you see something useful in the definitions above for this issue? |
Sure, reformatting that:
My current platform definition for the Arduino zero looks like this: zero:
board: arduino:samd:arduino_zero_native
package: arduino:samd
gcc:
features:
defines:
- __SAMD21G18A__
- ARDUINO_SAMD_ZERO
warnings:
flags: So it looks like we can test out these settings, by adding this to your own platforms:
zero:
board: arduino:samd:arduino_zero_native
package: arduino:samd
gcc:
features:
defines:
- ARDUINO_ARCH_SAMD
- ARDUINO_SAMD_MKRWIFI1010
- ARDUINO=10813
- __SAMD21G18A__
- ARDUINO_SAMD_ZERO
- USE_ARDUINO_MKR_PIN_LAYOUT
- USB_VID=0x2341
- USB_PID=0x8054
- USBCON
- USE_BQ24195L_PMIC
warnings:
flags: (This will override the defaults for the But this is very interesting. |
For now, I'll assume that all of this is the interesting part and reformat it for future reference
|
The SPI library contains some code to read the SPCR register to determine the byte order of 16-bit transfers, presumably because there is no official Arduino API to set it, so sketches had to rely on setting this register directly. By reading it, the SPI unittest implementation can detect how to emulate multibyte transfers. However, this register is only defined by avr/io.h when the unittest emulates an AVR platform, so this code would fail to compile on other platforms. This adds a preprocessor guard around this code, defaulting to the lsb-first, which is also the hardware and Arduino default. This fixes Arduino-CI#140.
The SPI library contains some code to read the SPCR register to determine the byte order of 16-bit transfers, presumably because there is no official Arduino API to set it, so sketches had to rely on setting this register directly. By reading it, the SPI unittest implementation can detect how to emulate multibyte transfers. However, this register is only defined by avr/io.h when the unittest emulates an AVR platform, so this code would fail to compile on other platforms. This adds a preprocessor guard around this code, defaulting to the lsb-first, which is also the hardware and Arduino default. This fixes Arduino-CI#140.
The SPI library contains some code to read the SPCR register to determine the byte order of 16-bit transfers, presumably because there is no official Arduino API to set it, so sketches had to rely on setting this register directly. By reading it, the SPI unittest implementation can detect how to emulate multibyte transfers. However, this register is only defined by avr/io.h when the unittest emulates an AVR platform, so this code would fail to compile on other platforms. This adds a preprocessor guard around this code, defaulting to the lsb-first, which is also the hardware and Arduino default. This fixes Arduino-CI#140.
The SPI library contains some code to read the SPCR register to determine the byte order of 16-bit transfers, presumably because there is no official Arduino API to set it, so sketches had to rely on setting this register directly. By reading it, the SPI unittest implementation can detect how to emulate multibyte transfers. However, this register is only defined by avr/io.h when the unittest emulates an AVR platform, so this code would fail to compile on other platforms. This adds a preprocessor guard around this code, defaulting to the lsb-first, which is also the hardware and Arduino default. This fixes Arduino-CI#140.
The SPI library contains some code to read the SPCR register to determine the byte order of 16-bit transfers, presumably because there is no official Arduino API to set it, so sketches had to rely on setting this register directly. By reading it, the SPI unittest implementation can detect how to emulate multibyte transfers. However, this register is only defined by avr/io.h when the unittest emulates an AVR platform, so this code would fail to compile on other platforms. This adds a preprocessor guard around this code, defaulting to the lsb-first, which is also the hardware and Arduino default. This fixes Arduino-CI#140.
Hi there,
thanks for this work!
System
ruby -v
: ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux-gnu]bundle -v
: Bundler version 2.1.4bundle info arduino_ci
: arduino_ci (0.3.0)g++ -v
: gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)java -version
: openjdk version "1.8.0_252"Issue Summary
I'm testing a code that on arduino (physical board) mkr 1010 compiles with no issues, however with arduino-ci is failing with the following errors
Works on the following platforms:
Arduino or Unit Test Code, Illustrating the Problem
The issue seem to be related to the import of
WString.h
. My code uses nothing strictly related to the SAMD processor, indeed here is the hole import listWorking
.arduino-ci.yaml
broken
.arduino-ci.yaml
Arduino Architecture(s) Affected
zero, as far as i know.
Thanks!
The text was updated successfully, but these errors were encountered: