Run TeensyLC at 16mhz - with USB libraries

Status
Not open for further replies.
D

drobinson

Member
Hi,

I found an old thread talking about running the TeensyLC at 16mhz and 8mhz.

Problem is, when I do this, it seems to drop the USB HID libraries. Is this intentional? I have some mhz-sensitive code that I want to run, & requires the USB libs.

Code: 
In file included from C:\Users\david\OneDrive\Documents\Arduino\libraries\ArduinoJoystickLibrary-master\src/Joystick.h:24:0,
                 from D:\Software\Arduino\NUS-005USB\NUS-005USB\NUS-005USB.ino:1:
C:\Users\david\OneDrive\Documents\Arduino\libraries\ArduinoJoystickLibrary-master\src/DynamicHID/DynamicHID.h:37:28: fatal error: PluggableUSB.h: No such file or directory
compilation terminated.
Error compiling for board Teensy LC.

From the above guidance, I removed the lines regarding optimisation and build flags to see if they were forcing this behaviour, but no luck.
 
Thanks for the confirmation.

How come? Other boards run USB fine at lower mhz (I have a sparkfun pro micro with USB support running at 8mhz).
 
'Other' boards may include those using an off chip USB chip just fed from a UART Serial port.

On Teensy LC, 3.x and 4.x the USB comes from Native processor USB Hardware and it requires that faster clock speed to run at USB speeds.

On Teensy Serial is USB with that native hardware and UARTS provide independent Serial1, Serial2, Serial3 ...
 
drobinson said:
Thanks for the confirmation.

How come? Other boards run USB fine at lower mhz (I have a sparkfun pro micro with USB support running at 8mhz).
Click to expand...

Depends on the chip - the ATmega32U4 in the Pro Micro derives its 48MHz USB clock from a PLL, and can generate it
internally when the main clock is 8MHz, but the MKL26Z64VFT4 in the TeensyLC says the clock needs to be 20MHz or
more to run the USB interface. To know why is a question for the chip designers, as its a consequence of the clocking/PLL
architectures in the two very different microcontrollers.
 
Thanks for that. Makes sense. This is my first adventure into hardware and I've clearly chosen a very hardware/timing-specific project so I'm learning a lot about it. I can see why there are so many different methods now - and choosing the right hardware is pretty crucial!
 
And 8MHz is pretty slow for a microcontroller - the old process used in ATmega's can't run the
processor at 16MHz at 3.3V (the USB section gets USB 5V so isn't slowed down I think). A more
modern microcontroller uses a faster CMOS process with a lower internal core voltage.

The basic power consumption rule for clocked CMOS chips is that power consumption goes with
fCV^2 where f is the clock frequency, C is the capacitance of all the internal signals and V is the
core voltage. This is why modern chips with low internal core voltages can have much higher
clock speeds and still have low power operation. And more modern processes have lower
capacitances too, so a modern 100MHz chip can easily out-perform an old 5V architecture at
8MHz for power consumption. Thus now there's little need for a slow microcontroller unless
its to run at 32kHz for ultra-low power.
 
MarkT said:
And 8MHz is pretty slow for a microcontroller - the old process used in ATmega's can't run the
processor at 16MHz at 3.3V (the USB section gets USB 5V so isn't slowed down I think). A more
modern microcontroller uses a faster CMOS process with a lower internal core voltage.

The basic power consumption rule for clocked CMOS chips is that power consumption goes with
fCV^2 where f is the clock frequency, C is the capacitance of all the internal signals and V is the
core voltage. This is why modern chips with low internal core voltages can have much higher
clock speeds and still have low power operation. And more modern processes have lower
capacitances too, so a modern 100MHz chip can easily out-perform an old 5V architecture at
8MHz for power consumption. Thus now there's little need for a slow microcontroller unless
its to run at 32kHz for ultra-low power.
Click to expand...

This is the issue I ran into - or found out the hard way - that the code I'm trying to run is designed specifically for 16mhz. Seems to be tied very closely with the cycles. I'm sure there would be a way to rewrite it but I'm very far from that point. Maybe one day. But for now I'll just get a board to match the software, rather than the other way around :)
 
Status
Not open for further replies.
Back
Top