Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Remove forceful "using namespace arduino" from headers#144

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
facchinm merged 2 commits intoarduino:masterfromfacchinm:no_forced_namespace
Apr 6, 2021

Conversation

@facchinm
Copy link
Member

Copy link

@bxparksbxparks left a comment
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Hi, This is great news. The explicitusing statements seem to provide backwards compatibility with existing forward declarations. As noted above, I had to add theusing arduino::String statement to make the fix more complete.

I validated your 2 PRs,

by switching my git repos to your branches (so basically, I get a samd 1.8.11, plus your changes). I then compiled and uploaded about 70 of my unit tests, across most of my libraries, to an actual MKR1000 that I recently purchased. I had a few hiccups, but eventually got everything working.

There were 3 classes of problems:

  1. String forward declarations, fixed by above.
  2. More stringent compiler errors and warnings from the SAMD21 compiler. (Every compiler seems to complain about slightly different things...)
  3. The breaking change to::digitalWrite(uint8_t, uint8_t) which is now::digitalWrite(uint8_t, PinStatus) in the new API.
    • I have to use an explicitly scoped::digitalWrite() because I have an overloadeddigitalWrite() in that class. But::digitalWrite() does not match yourarduino::digitalWrite()) overload. So I had to insert a handful of#if defined(ARDUINO_API_VERSION) statements.

With regards to the 2 PR on my libraries:

I will check in a version that removes that#error for the SAMD21 core. But I want to retain the blacklist for megaAVR platform until I personally verify thatarduino/ArduinoCore-megaavr#62 is fixed on actual hardware. I currently don't have any megaAVR boards, but it's on my shopping list.

I have a question onbxparks/AceTime#57 that you sent: You replaced the#include <Arduino.h> with an#include <arvr/pgmspace.h>. Unfortunately, that breaks the ESP32 platform, where it needs to be#include <pgmspace.h>. I can add some conditional code onARDUINO_API_VERSION in there, or just keep using#include <Arduino.h> in that.cpp file.

I will update this comment when I have submitted the fixes on my end that adds support for arduino:samd >= 1.8.10.

@bxparks
Copy link

I have prepared a series of PRs, which replace the PRs sent to me by@facchinm:

These are designed to reenable arduino:samd when a new version (1.8.12?) is released. The version number of the arduino:samd Core doesn't matter. Instead, I assume that theARDUINO_API_VERSION number will beincremented for the next release.

I will wait until the new arduino:samd core is pushed out. Then I will re-validate my libraries, and if everything looks right, I will submit my PRs listed above, and everything should be stable again. We can undo the version-pinning of my libraries (arduino/ArduinoCore-samd#607) in the arduino:samd CI workflow if desired.

per1234 and facchinm reacted with thumbs up emoji

@facchinmfacchinm merged commit4baf42c intoarduino:masterApr 6, 2021
umaplehurst pushed a commit to umaplehurst/ArduinoCore-samd that referenced this pull requestJul 14, 2021
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

1 more reviewer

@bxparksbxparksbxparks left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

AceTime example compilation is breaking checks

2 participants

@facchinm@bxparks

[8]ページ先頭

©2009-2025 Movatter.jp