Search results

I haven't tested this with 1.43 yet, but it appears that teensy 3.2 hardware with the teensyduino 1.42 and arduino 1.8.5 has a USB buffering issue. void setup() { Serial.begin(9600); } void loop() { static uint8_t buf[4096]; for(unsigned i = 0 ; i < sizeof(buf) ; i++) { while(1) {...

Yes, the example is quite simplified -- I'm using the PWM output to drive a stepper motor and controlling the velocity with the frequency. The occasional short pulses were causing the stepper to skip steps at certain speeds. I'll copy the code out of analogWriteFrequency() into my own routine...

The offending code appears to be in pins_teensy.c: } else if (pin == 5 || pin == 6 || pin == 9 || pin == 10 || (pin >= 20 && pin <= 23)) { FTM0_SC = 0; FTM0_CNT = 0; FTM0_MOD = mod; FTM0_SC = FTM_SC_CLKS(1) |...

Is there a way to avoid glitches caused by changing the output frequency with analogWriteFrequency()? It appears to force a reset of the counter when it is called, which causes a transition earlier than it should. In this example the same frequency value is written (when trace 2 goes high), so...

I saw it always with the BeagleBone Black, Xbuntu on my toughbook for /dev/ttyACM1-4 (but not ACM0?), and also Mountain Lion on my Macbook. With the termios fix everything is better now and our giant 7m tall pyramid of LEDs will be 12.5% more blinky with strip #4 re-enabled.

This is an easy fix and a frustrating bug. The low intensity bit pattern that messes things up included 0xA, also known as a newline character. Disabling OPOST in the termios prevents the tty from adding a carriage return, which adds one extra byte to the output stream, causing the bit stream...

I'm having problems with OctoWS2811 with specific low-intensity bit patterns when we have multiple Teensy3's connected to the same machine. The conditions seem somewhat specific and hard to pinpoint: with only one teensy on my laptop it is ok, but fails when there are multiple teensys, and on...