Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 7 of 7

Thread: Teensy 3.1 does not see the TWBR emulation

  1. #1
    Senior Member
    Join Date
    Nov 2012
    Location
    Boston, MA, USA
    Posts
    1,108

    Teensy 3.1 does not see the TWBR emulation

    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 on Github. 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:
    Code:
    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.
    Code:
    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\build7744858441146534684.tmp\midi2cv_01.cpp -o C:\Users\Chris\AppData\Local\Temp\build7744858441146534684.tmp\midi2cv_01.cpp.o 
    
      Using previously compiled: C:\Users\Chris\AppData\Local\Temp\build7744858441146534684.tmp\Wire\Wire.cpp.o
    
      Using previously compiled: C:\Users\Chris\AppData\Local\Temp\build7744858441146534684.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\utility F:\Arduino\sketches\libraries\Adafruit_MCP4725\Adafruit_MCP4725.cpp -o C:\Users\Chris\AppData\Local\Temp\build7744858441146534684.tmp\Adafruit_MCP4725\Adafruit_MCP4725.cpp.o 
    
    F:\Arduino\sketches\libraries\Adafruit_MCP4725\Adafruit_MCP4725.cpp: In member function 'void Adafruit_MCP4725::setVoltage(uint16_t, bool)':
    F:\Arduino\sketches\libraries\Adafruit_MCP4725\Adafruit_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. This thread indicates that Paul was looking at adding it, and of course something must ghave been done since it works with Teensy 3.0 ...

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,297
    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.
    Attached Files Attached Files

  3. #3
    Senior Member
    Join Date
    Nov 2012
    Location
    Boston, MA, USA
    Posts
    1,108
    I am seeing this in libraries/Wire/Wire.cpp
    Code:
    #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).

  4. #4
    Senior Member
    Join Date
    Nov 2012
    Location
    Boston, MA, USA
    Posts
    1,108
    Your post and mine crossed. Confirming the fixed Wire.cpp and Wire.h allow sucessful compilation.

  5. #5
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,297
    Quote Originally Posted by Nantonos View Post
    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.

  6. #6
    Senior Member
    Join Date
    Nov 2012
    Location
    Boston, MA, USA
    Posts
    1,108
    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?

  7. #7
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    21,297
    Quote Originally Posted by Nantonos View Post
    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •