Teensy 3.1 does not see the TWBR emulation

[Nantonos]

I have a sketch which works on Teensy 3.0 and fails to compile on Teensy 3.1. The culprit appears to be the Adafruit library for the MCP4725 DAC, which is . I downloaded a fresh copy from github today, the error persists. Its uses TWBR which, it seems, is defined for Teensy 3.0 but not for 3.1.

Here is the relevant bit of the Adafruit library:

void Adafruit_MCP4725::setVoltage( uint16_t output, bool writeEEPROM )
{
uint8_t twbrback = TWBR;
TWBR = 12; // 400 khz
Wire.beginTransmission(_i2caddr);
if (writeEEPROM)
{
Wire.write(MCP4726_CMD_WRITEDACEEPROM);
}
else
{
Wire.write(MCP4726_CMD_WRITEDAC);
}
Wire.write(output / 16); // Upper data bits (D11.D10.D9.D8.D7.D6.D5.D4)
Wire.write((output % 16) << 4); // Lower data bits (D3.D2.D1.D0.x.x.x.x)
Wire.endTransmission();
TWBR = twbrback;
}

Here is the error in full.

Arduino: 1.0.5 (Windows 7), Board: "Teensy 3.1"
F:\Arduino\arduino-105-td117\hardware\tools\arm-none-eabi\bin\arm-none-eabi-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mcpu=cortex-m4 -DF_CPU=96000000 -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -mthumb -nostdlib -D__MK20DX256__ -DTEENSYDUINO=117 -fno-rtti -felide-constructors -std=gnu++0x -DUSB_MIDI -DLAYOUT_CANADIAN_FRENCH -IF:\Arduino\arduino-105-td117\hardware\teensy\cores\teensy3 -IF:\Arduino\arduino-105-td117\libraries\Wire -IF:\Arduino\sketches\libraries\Adafruit_MCP4725 C:\Users\Chris\AppData\Local\Temp\build77448584411 46534684.tmp\midi2cv_01.cpp -o C:\Users\Chris\AppData\Local\Temp\build77448584411 46534684.tmp\midi2cv_01.cpp.o

Using previously compiled: C:\Users\Chris\AppData\Local\Temp\build77448584411 46534684.tmp\Wire\Wire.cpp.o

Using previously compiled: C:\Users\Chris\AppData\Local\Temp\build77448584411 46534684.tmp\Wire\utility\twi.c.o

F:\Arduino\arduino-105-td117\hardware\tools\arm-none-eabi\bin\arm-none-eabi-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mcpu=cortex-m4 -DF_CPU=96000000 -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=105 -mthumb -nostdlib -D__MK20DX256__ -DTEENSYDUINO=117 -fno-rtti -felide-constructors -std=gnu++0x -DUSB_MIDI -DLAYOUT_CANADIAN_FRENCH -IF:\Arduino\arduino-105-td117\hardware\teensy\cores\teensy3 -IF:\Arduino\arduino-105-td117\libraries\Wire -IF:\Arduino\sketches\libraries\Adafruit_MCP4725 -IF:\Arduino\sketches\libraries\Adafruit_MCP4725\ut ility F:\Arduino\sketches\libraries\Adafruit_MCP4725\Ada fruit_MCP4725.cpp -o C:\Users\Chris\AppData\Local\Temp\build77448584411 46534684.tmp\Adafruit_MCP4725\Adafruit_MCP4725.cpp .o

F:\Arduino\sketches\libraries\Adafruit_MCP4725\Ada fruit_MCP4725.cpp: In member function 'void Adafruit_MCP4725::setVoltage(uint16_t, bool)':
F:\Arduino\sketches\libraries\Adafruit_MCP4725\Ada fruit_MCP4725.cpp:67:22: error: 'TWBR' was not declared in this scope

I had a look in hardware/teensy/cores/teensy3/avr_emulation.h but didn't see TWBR in there. [url=http://forum.pjrc.com/threads/21512-Teensyduino-1-13-Released?p=27601&viewfull=1#post27601]This thread (]on Github[/url) indicates that Paul was looking at adding it, and of course something must ghave been done since it works with Teensy 3.0 ...

[PaulStoffregen]

Yup, this is one of the many places missing a #define for Teensy 3.1.

I'm sorry I missed so many of these. I'm going to publish 1.18 soon with lots of little fixes. In the meantime, here's the updated files.

[Nantonos]

I am seeing this in libraries/Wire/Wire.cpp

#if defined(__MK20DX128__)

#include "mk20dx128.h"
#include <string.h> // for memcpy
#include "core_pins.h"
//#include "HardwareSerial.h"
#include "Wire.h"
// and much else besides, including
#if F_BUS == 48000000
I2C0_F = 0x27; // 100 kHz
// I2C0_F = 0x1A; // 400 kHz
// I2C0_F = 0x0D; // 1 MHz
I2C0_FLT = 4;
#elif F_BUS == 24000000
I2C0_F = 0x1F; // 100 kHz
// I2C0_F = 0x45; // 400 kHz
// I2C0_F = 0x02; // 1 MHz
I2C0_FLT = 2;
#else
#error "F_BUS must be 48 MHz or 24 MHz"
#endif
// more stuff
#endif

May need an update for 72MHz? As well as a more inclusive #ifdef (I recall CORE_TEENSY and ARM were the suggested defines).

[Nantonos]

Your post and mine crossed. Confirming the fixed Wire.cpp and Wire.h allow sucessful compilation.

[PaulStoffregen]

May need an update for 72MHz?


I'm planning to support 72 MHz in about a month. For now, it's not in the Tools > CPU Speed menu. Updates are needed in MANY places, and a lot of them aren't simple because the bus clock will not be a multiple of 2 from the values currently supported.

[Nantonos]

No worries; as it can't be selected accidentally it won't be a problem.
I'm unsure if there are any downsides to running Teensy 3.0/3.1 at 96MHz rather than at their rated 48 or 72 respectively? Overclock sounds scary and fragile, but they seem rock solid at that speed. Why do people run them slower?

[PaulStoffregen]

Why do people run them slower?

Product differentiation for Freescale.

All the Kinetis K-series chips are fabricated on the same 90 nm silicon process. The ARM Cortex-M4 CPU core is identical in all of them. The K-series peripherals are all the same too (just more of them with more FIFOs in the bigger chips). The main difference is the 50 MHz rated parts have only a 32 bit wide flash, whereas the 72 and 100 MHz rated parts have 64 bit wide flash. The extra flash bandwidth does help prevent wait states when running faster.

Normally I would be wary of overclocking. But in this case, it really is the same circuitry with the same transistors.

Rumor has it the chips within the same speed rating with less memory are really the exact same silicon, with some factory-programmed non-volatile bits that simply configure the memory controller to return bus faults if you try to access the memory you didn't pay for. I've even heard rumors some of the cheaper chips might actually be the same silicon as chips with more peripherals, again where factory programmed nonvolatile bits simply disable access to some stuff.

It's pretty much the modern reality that IC design, even at a fairly high level with synthesis tools, it expensive. Manufacturing different silicon is even more expensive. It's far less costly to make a small number of actual silicon dies that cover the hundreds of different IC part numbers, where the exact same silicon is used in lots of similar chips with soft configuration to disable things in the cheaper models.