Search results

The other change made is the value of R2. 100K ohms is a very large value for a pull down resistor and will make the circuit susceptible to noise pickup. Again the pulldown resistor value is too large.

>>any thoughts as to what might be causing it? My guess it has something to do with Wire chunking the data into 32 byte buffer sizes, yet on each request your slave sends 100 bytes. Do you get the correct data after 32 reads or does it start over again with 0 to 32? Does it work without...

Your description seems inconsistent to me, if measuring with a meter shows its at 3.3 volts then it should read high.

I did a project along those lines although it is not a port of existing code but a complete Teensy Audio Library implementation. https://github.com/roncarr880/uSDX_Teensy

/**************************************************************************/ /*! @brief Read one character from the GPS device. Call very frequently and multiple times per opportunity or the buffer may overflow if there are frequent NMEA sentences. An 82 character NMEA sentence...

Touching pins adds capacitance. Is that the BCLK you are touching? You can try adding a small series resistor, 22 to 50 ohms. Or try adding a small capacitor to ground, 22 to 100 pf. Or a resistor in parallel to ground may be needed to load the signal, try 1k to 5k to ground.

Without looking through all the SPI code to make sure that I am looking at the Teensy 4.1 code, the behavior of sending with a reference ( pointer ) rather than by value is to put the receive data in the transmit array. inline static void transfer(void *buf, size_t count) { if (count == 0)...

If the circuit is as this description reads, you should remove the 10k emitter resistor and connect the emitter to ground.

Another idea for you: how is controlling dimmers not unlike hobby servos? They both have a 50 hz repeat rate for you in the UK. You may be able to control your lights with 4us resolution by adapting the PWMservo library. The only sticky issue would be syncing the PWM library to your 50hz...

What kind of Timer interrupt are you using? Usually a timer interrupt is started in your setup code and started only once. You are calling begin on every interrupt which would only be needed if the Timer works as a one-shot. And if using a one-shot, you wouldn't want to start it running...

At first glance this project suggests one would use the C bitwise operators, &-AND, |-OR, ^-XOR but the way you have stored your data prevents this. But if all your inputs were kept in the BIT 0 position you could write functions like: uint8_t fAND( uint8_t A, uint8_t B ){ return A & B...

You should be fine with using just one serial port keeping in mind that the SBUS uses inverted serial, although just to confuse things some flight controllers provide both an inverted input and non-inverted input. Teensy can be set up to invert the data although I have never tried it...

The Q and D solution is to put a voltage dropping diode in line with the power supply, then you have 5.4 volts, or add two and you have 4.8 volts.

Are you expecting data back and maybe used one of the blocking serial read commands. https://www.arduino.cc/reference/en/language/functions/communication/serial/settimeout/

I calculate that 32 bytes at 115k baud would take 2.7 ms even if there were no buffering at all for the transmit bytes, nowhere near 400 ms. And 32 bytes at 19.2k baud would take 16.6 ms, nowhere near the increase of 300 ms ( 400 ms to 700 ms ). So I would look elsewhere such as did you set up...

You could put a FET like a BS170 between the Teensy and your device under control. The FET when off will have a very high resistance. This will reverse the logic in your program as the FET will invert the signal. Wire the Drain pin of the FET to your device, wire the Source pin of the FET to...

I suggest you look in ......hardware/Teensy/avr/cores/Teensy3/Serial1.c to see if it was hacked to support the pin numbers 98,99. Otherwise calling Serial1.begin seems to set up the baud rate but not any pins. My 'completely just a guess' is this code snippet is something to allow your JTAG...

Do you really have 1X probes? What is the loading? Are they 50 ohm?

My only other idea is to follow the setting of the bits in the SPI command register with the pinMode setting as KurtE suggested. SPI0_C2 |= ( 1<<SPI_C2_SPC0 | 1<<SPI_C2_BIDIROE ); pinMode(12, INPUT_PULLUP);

Sorry, (and there is still a chance I am looking at the incorrect reference doc) but it seems those bits are not defined for the user ( and it is SPC0 zero not O as I previously wrote ) but the register is defined. You can try SPI0_C2 |= 1 + 8; Edit: It seems those bits are defined like...

The reference manual ( hopefully I am reading the correct one, KL26 sub-family ) seems to indicate you could regain use of the MISO pin by setting some bits in control register 2. SPI0_C2 |= 1<<SPCO + 1<<BIDIROE;

uint8_t readI2C() { switch(syncCom) { case 0: byteToread = Wire.available(); if (byteToread >= requestBytes) { Serial.println(requestBytes); for (uint8_t k = 0; k < byteToread; k++) { shtpDataRead[k] = Wire.read(); }...

I would see this working like this: you set the RV-3028 to generate a 1 second interrupt. In servicing the interrupt you read the time via I2C and reset your elapsed micros variable to zero. You now have your timestamp information locally to the Teensy and will not need to read the real time...

You could use an elapsed micros variable. You would reset the variable to zero on each change of the second on your external clock. https://www.pjrc.com/teensy/td_timing_elaspedMillis.html

PWM is built in with the analogWrite function so I am not sure you would need a library. You also have full control of the resolution and frequency as this page explains: https://www.pjrc.com/teensy/td_pulse.html

The part is the orange LED connected to pin 13. Your Teensy is probably fine but you won't be able to run a blink sketch unless you hook up an external LED and resistor to an I/O pin.

Let me fix my post just for you Mcu32. Mcu32 has the right idea here. The OP said: Yes you are being silly. digitalWriteFast will be as fast or faster than anything you write yourself. ( Unless you want to just toggle a pin where you can be faster by writing directly to the toggle...

I also once wanted to be as fast as possible with the I/O and wrote a speed test program for the Teensy 3.6 ( it may not run on Teensy 4 ). It proved to me that you won't invent anything faster than digitalWriteFast. /* LED Blink, Teensyduino Tutorial #1...

Yes you are being silly. digitalWriteFast will be as fast or faster than anything you write yourself. ( Unless you want to just toggle a pin where you can be faster by writing directly to the toggle register ). Just define your pins with names and change the defines to 'rewire' your board...

Leaving unpowered Teensys's connected to powered routers could be detrimental in two ways. Serial lines idle high, so the Teensy was likely powered via the RX I/O pin when not connected to your laptop. Then powering up the Teensy with voltage already present on an I/O pin could result in CMOS...

Call flush() before exists() ?

I think your approach is fine but it may fail in 50 days. https://www.norwegiancreations.com/2018/10/arduino-tutorial-avoiding-the-overflow-issue-when-using-millis-and-micros/ Interval timers are great but do add the complexity of running in interrupt context...

You may be able to make use of the play queue object. It allows external data to be injected into an audio stream. A process that takes more than 3ms to calculate 768 values must be either very complicated or very inefficient. Could that be improved? I would be looking at implementing a...

You can use resistors of approximate ratio of 2k to 3k to level shift but I would think two of those level shifting boards would be easier to wire than 16 resistors. If you are designing etch then maybe the resistors are better and cheaper but from your description I think you have a one-off (...

You should post your program so people can see what you are trying to do. But I think I understand and I think your best bet would be to connect another change interrupt capable pin to pin 2 ( pin 2 and pin x are both connected together and to the encoder ) and use that for your sleep interrupt.

Yes, I see I was missing the factor of 60 for RPM. Another thought I had was you could call my median routine twice or more, like: val = median( 0, val ); val = median( 1, val ); Whether that would be the same as the median of 6 values or if it would be some other convolution of the...

https://www.pjrc.com/teensy/td_libs_FreqMeasure.html The docs for FreqMeasure indicate that FreqCount would be a better fit for your application, and interestingly you have issues at low speed where the FreqMeasure library is supposed to be better. Perhaps that does indicate some issue with...

Unsigned arithmetic is tricky, subtraction may give a modulo largest number effect, and I am not completely sure, but when the rpm is slowing you could see very large spikes. I would suggest changing all the variables to int32_t and see if that fixes anything.

I have seen those types of errors before. My solution was to change the library to use digitalWriteFast statements. It is just as fast or faster than the direct port manipulation macros. LCD5110::LCD5110(int SCK, int MOSI, int DC, int RST, int CS) { /* P_SCK =...

I think one way you could send AM with your hardware was to have two versions of your AM modulator, one for the I channel and one for the Q channel. The waveform generators would be 90 degrees difference in phase. The I and Q will go through your transmitter the same as a SSB signal. If...

Glad to hear it. Yeah, all variables that are shared between interrupt service routines and your regular code should be declared as volatile, otherwise the compiler will optimize your code away if it knows the value of the variable ( declared as false and still false in setup() as far as the...

I thought I had done something like this, but I used the sqrt( I^2 + Q^2) methods in this paper. The first part of the paper is just square roots using iterative method and square root as an IIR filter. http://www-labs.iro.umontreal.ca/~mignotte/IFT2425/Documents/ARootOfLessEvil.pdf

measured should be declared as a volatile variable, that may or may not make a difference in your case.

In general I would think of the differences between the T3.2 and T3.5. The T3.5 is faster so there will be less time between writing the columns and reading the rows. The library is using the internal pullups, there may be some difference in how strong they are between the two processors...

I don't know what gps hardware works this way, but this does seem to be a thing... https://novatel.com/support/known-solutions/almanac-injection-procedure

And assuming you are using a DS1307 wired to the Teensy, the datasheet says this: "If a backup supply is not required, VBAT must be grounded. "

pinMode( x, INPUT ) connects the pin to digital input circuitry inside the Teensy. This does load the pin slightly as you have found. My opinion is that for a microcontroller you want your programming language to do exactly what you say and nothing more or less. As an example of a language...

My thoughts from looking at the mixer object: void Panner::update(void){ for(int och = 0; och < num_channels; ++och){ audio_block_t *block = receiveReadOnly(0); You need receiveReadOnly( och ) BUT if (block) { transmit(block, och); You can't successfully transmit...

With all those motors hooked to the Teensy you may be drawing too much current, scope your Vin pin to see if the voltage is sagging. I would guess you must have the motors wired in parallel instead of series but anyway if your driver looks like this... You would wire the VCC pin with 3.3...

My code is written for a Pic 16F690, is not a complete program, and has nothing to do with Teensy or Arduino. I offered it as an example of how the algorithms work in using a UART with a One-Wire device. What you can glean from the code example: To initialize the one wire device, set baud...