Missing declaration for Teensy3 boards

Elmue

Well-known member
Many Arduino boards declare the constant DAC0.
This is missing in Teensy 3 code.

Like the constants SDA and SCL are declared, there should be also the corresponding constants DAC0, DAC1.


For Teensy 3.1:

#define DAC0 A14


For Teensy LC:

#define DAC0 A12


For MK66FX1M0:

#define DAC0 A21
#define DAC1 A22
 
I just compiled for an UNO and cannot reference DAC0 or DAC as I get this error for both:

'DAC0' was not declared in this scope

Can you link to an example included in the IDE that used this nomenclature for some 'Genuino' board? I couldn't find a web example or reference to it on Arduino.cc.

Saying "Many Arduino boards" suggests it is board specific and not a general rule - unlike other pin naming. In the case of Teensy the 'PJRC Card' shows A14 is DAC.

It would also be confusing to use DAC0 when only one DAC exists - versus those that do have two.

It seems like this would be an issue for the Arduino folks to define a standard - if there were a standard, it would be defined for Teensy.
 
I just took a quick look.

Arduino Due defines DAC0 and DAC1.

Arduino Zero defines DAC, but it's not a pin number. It's some sort of special hardware register pointer, not usable for normal Arduino API stuff. Zero does not define DAC0, even though it has one analog output pin.

Arduino 101 doesn't define any of these.
 
I just took a quick look.

Arduino Due defines DAC0 and DAC1.

Arduino Zero defines DAC, but it's not a pin number. It's some sort of special hardware register pointer, not usable for normal Arduino API stuff. Zero does not define DAC0, even though it has one analog output pin.

Arduino 101 doesn't define any of these.

So you're saying that they're nice and consistent about this ;)
 
Of course Due is the platform that decided that the second i2c line should be the primary SDA/SCL on the shield, so you have code like:

Code:
#include <Wire.h>
#ifdef __arm__
#define Wirex Wire1
#else
#define Wirex Wire
#endif

which is great fun when you import i2c sketches into Teensy.
 
defragster:
Obviously Uno does not define these constants because the Uno has no DAC!


Paul:
Arduino 101 also does not have a DAC.

You are right for Zero.
The definition is missing in Arduino Zero, where a lot of other stuff is also missing (very incompatible code).
The Zero does NOT EVEN define SDA and SCL !
I will write some bugreports for these incompatibilities.


DAC is not the same as DAC0 or DAC1.
I don't know where DAC is used for, but in sketches you should use DAC0 and DAC1 as you can see here:

https://www.arduino.cc/en/Tutorial/DueSimpleWaveformGenerator:


Code:
void loop() 
{
  // Read the the potentiometer and map the value  between the maximum and the minimum sample available
  // 1 Hz is the minimum freq for the complete wave
  // 170 Hz is the maximum freq for the complete wave. Measured considering the loop and the analogRead() time
  sample = map(analogRead(A0), 0, 4095, 0, oneHzSample);
  sample = constrain(t_sample, 0, oneHzSample);

  analogWrite([B]DAC0[/B], waveformsTable[wave0][i]);  // write the selected waveform on DAC0
  analogWrite([B]DAC1[/B], waveformsTable[wave1][i]);  // write the selected waveform on DAC1

  i++;
  if(i == maxSamplesNum)  // Reset the counter to repeat the wave
    i = 0;

  delayMicroseconds(sample);  // Hold the sample value for the sample time
}


As you see these constants are officially in use by Arduino folks.

It would make Teensy more compatible if you add them.

By the way:
Also usefull would be what Due defines:

Code:
#define ADC_RESOLUTION		12
 
Last edited:
This would be much more compelling if Arduino defined it for Zero. Maybe someone should open an issue on github asking them to add it.

Definitions which only exist on Arduino Due aren't very persuasive. Arduino LLC has essentially discontinued Due.
 
Hi Paul

It is so frustrating to make suggestions here.
If it is not a big bug, you will reject it.

What does it matter what Zero is doing ?
It is obvious that in Zero code there many things missing.
The board has I2C, but does not declare SDA and SCL.
It is obvious that they forgot to declare it.

In the time you are discussing this you could have already added two lines to your code!

Do the declarations of DAC0 and DAC1 have ANY negative side effect for current or future Teensy users ?
Obviously not.
So why not implement it and close this thread.

I really don't understand your attitude.

All these small things that I suggested in this and in other threads that cost you 5 minutes are not worth a discussion.
When they are usefull and have no negative side effect - just a declaration of a constant - why should this be discussed ?


Why don't you see it the other way around:
When Teensy declares DAC0 and DAC1, all boards that have a DAC will have this declaration - except Zero.
Then the folks who program Zero will be more motivated to add it also.
 
Last edited:
It is so frustrating to make suggestions here.
....
I really don't understand your attitude.

Well,
IMO, Paul did show great will to address your demands.
IMO, the ways you formulate your 'suggestions' sound to me that you are by definition right and all has to be done as you say.
OK, you have spend a lot of time analyzing the situation and come to a conclusion, but this does not mean others find your findings as important, and the way you wrote it, I found a little bit too aggressive (I assume this is not intended but you may put yourself on a reader's side).

For example, I do not care about Arduino, and the first thing I did, is to kick out all the backward compatibility.

Paul, however, stated frequently that he cares about Arduino compatibility and contributed to the other side to make Arduino working better, but as you said, here we care about Teensy and its functionality and if Arduino SW can be ported it will be done by someone.
 
Last edited:
Well,
... the way you wrote it, I found a little bit too aggressive.
+1

Nobody here cares as much about Arduino as Paul - and it is rare that the release notes don't credit him for some element of the release - one of the many hats he wears not only PJRC hardware past/present/future - but ongoing PJRC software support, where one easy change today can be a time sink today and having to support it in the future.

If it is not a big bug, you will reject it.
From what I've seen: If it is a bug it gets appropriate attention, indeed if not a provable 'immediate concern' it is either added to a ToDo list or dismissed, typically as above with due consideration and research. It has something to do with time management - something I've never done well with - but Paul has a system to be productive in an ongoing manner ...

This is the forum not a 'bug/issues' area - threads don't close here. Bugs are best reported in the proper place in the GitHub tree where they are tracked with the code involved - most all is out there. And if you've examined and tested an issue - fork the tree and submit a pull request. If well done and worthy it makes it easier to get addressed.
 
Last edited:
@Elmue - You're convinced this is a bug, but this situation is far from a simple matter of correct vs incorrect code. For someone so experienced in software development, you really ought to understand the risk of defining preprocessor symbols with short names in the widely used header files.

So, to state this clearly, I do not consider lack of defining DAC0 on a non-Due board a software bug.

Even when/if Arduino does eventually define DAC0 for Zero, I'll probably wait a release or two before adopting it into Teensy.
 
Back
Top