Skip to content
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

Make Dxx port literals less disappoiting #1529

Open
brusherru opened this issue Nov 6, 2018 · 6 comments
Open

Make Dxx port literals less disappoiting #1529

brusherru opened this issue Nov 6, 2018 · 6 comments
Labels

Comments

@brusherru
Copy link
Contributor

@brusherru brusherru commented Nov 6, 2018

Some boards, like Wemos, use Dxx port labels on their boards but it is not equal to plain numbers of ports (D7 on the board equals to 13, which equals to D13 in XOD IDE).

Reported on the forum: https://forum.xod.io/t/led-test-in-wemos-mini-clone-no-works/1303

So that on first glance seems we have to check is Dxx port is defined either as macro or static const, and if defined — use them instead of converting it into a plain number.

But there are few things to think about:

  1. Wemos D1 mini has only D1-D8 ports, so D13 is not defined and will be converted into 13, so it will be equal to hardware D7. That may cause conflicts if the user also uses D7 port somewhere in the program.
  2. An experienced user may want to upload the same program as he uploaded onto Arduino Uno, but change the wiring. In this case, D4 will not mean 4 anymore and mean real hardware D4. But probably it's a minor, because "Guy, now you are uploading on Wemos with Dxx ports, so it will be really Dxx ports".
  3. But if Dxx ports could mean different things depends on the target board, probably XOD IDE should have a "universal" port literal that always be equal to a plain number of the port?
@nkrkv

This comment has been minimized.

Copy link
Member

@nkrkv nkrkv commented Nov 7, 2018

I have no idea how the points mentioned can hurt actually. I think it is 💯 OK to just use D4 if it is defined and 4 otherwise. All the other problems sound unnatural.

@Cesar-S

This comment has been minimized.

Copy link

@Cesar-S Cesar-S commented Nov 9, 2018

hello, Wemos has A0 and D0-D8, D0 (D0 or Arduino PIN16 ) is between A0 and D5.

pins_arduino.h (Wemos D1 Mini)`

#ifndef Pins_Arduino_h
#define Pins_Arduino_h

#define PIN_WIRE_SDA (4)
#define PIN_WIRE_SCL (5)

static const uint8_t SDA = PIN_WIRE_SDA;
static const uint8_t SCL = PIN_WIRE_SCL;

#define LED_BUILTIN 2

static const uint8_t D0   = 16;
static const uint8_t D1   = 5;
static const uint8_t D2   = 4;
static const uint8_t D3   = 0;
static const uint8_t D4   = 2;
static const uint8_t D5   = 14;
static const uint8_t D6   = 12;
static const uint8_t D7   = 13;
static const uint8_t D8   = 15;
static const uint8_t RX   = 3;
static const uint8_t TX   = 1;

#include "../generic/common.h"

#endif /* Pins_Arduino_h */

@Cesar-S

This comment has been minimized.

Copy link

@Cesar-S Cesar-S commented Nov 9, 2018

Suggestion

If in the port inspector had a pin selector according to board, that would complicate something?
For example:

  • Arduino UNO
    A0-A5 and D0-D13

  • Wemos D1 mini
    TX-RX, A0 and D0-D8

I would not give another value option :)

@nkrkv

This comment has been minimized.

Copy link
Member

@nkrkv nkrkv commented Nov 12, 2018

@Cesar-S

The problem is not in Inspector, the problem is in transpiler. It acts on a stage where the board model is not yet known (Deploy → Show code has no parameters and that’s great). So, how should the value D4 be translated to C++?

An obvious reply is “As is, as D4 of course!” However, it is not even defined for the AVR platform (Arduino Uno, Nano, Mini and friends). For this reason, we decided to strip the D prefix. And, as you can see it was neither a wise decision because on some boards (e.g., Wemos) D4 and 4 mean the different things.

Thus, a correct solution involves some smart C++ construct which will unroll to D4 if it is defined for the board and fallback to 4 otherwise.

@DaleSchultz

This comment has been minimized.

Copy link

@DaleSchultz DaleSchultz commented Jan 14, 2019

Thus, a correct solution involves some smart C++ construct which will unroll to D4 if it is defined for the board and fallback to 4 otherwise.

But it is more than that. D5 may be defined but has the value of 1. What the user wants and expects is that D5 addresses the pin labeled D5 on their hardware. On a NodeMCU the pin marked D5 is not GPIO 1, it is GPIO 14 so using the logical and intuitive port of D5 leads to frustration and failure on the most simplest of patches. Even worse, we have no way to debug or display what D5 is equal to as there is no port-to-number node, so we also lose the opportunity to teach how to debug the issue.

@Cesar-S

This comment has been minimized.

Copy link

@Cesar-S Cesar-S commented May 15, 2019

According to what is stated here, D255 is the solution I was looking for. But in the help of the pin there is no reference, that's why I was looking for a NONE to deactivate the pin.

Input terminal node. Adds a new port input pin to the patch node which contains this node. Terminal label and description are propagated to the pin. Horizontal position relative to other terminals defines the pin order. A value bound to the terminal node pin becomes the default for the created input pin.

ps: I think D255 can confuse, I would like an NN or NA 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.