Search results

I'm looking for suggests on how to proceed here: A few seconds after boot I may find an I2C device connected to the Teensy 4.0 and it would be great if I could add a new device to the USB descriptors. The device is a variant of a HID device - a I2CHID PTP device. I'd like the Teensy 4.0 to be a...

I'm another person looking for some Teensy 3.6 parts. If you have any you'd like to sell PM me. Thanks

Ah, I hate it when I'm not clear. That is a snip from the reference schematic (the demo board). The instructions in the text clearly state to remove the zero ohm jumpers from the hyperflash (not shown) and add the zero ohm jumpers on the QSPI. They also say to add the pull ups. edit: There is...

The NXP reference design shows pull up resistors on the /WP and /RESET and /CE signals on the QSPI flash but the Teensy 4.1 design doesn't have those pull ups. The NXP FAE is saying it needs them for sure (but just during the initial startup for the 30MHz access of flash). Does that sound...

Thanks! Hopefully I'm not being too annoying here. I should know by the end of next week if this fixes the temperature issue.

Well, this traces down to a change in bootcode.c - with a little luck one of you has access to a nice scope and can confirm my findings. With the prior value (3) in the clock field the flash clocks at 120 MHz. With the new setting (8) it clocks at 144 MHz. These don't really match the docs -...

Is uint32_t FlexSPI_NOR_Config[128] in bootdata.c the data that is supposed to control this clock frequency? If I'm interpreting the data correctly it's set to 8 = 133 MHz. If I set it to 7 I get 180 MHz. I am clearly lost on this. How do you set the freq of the flash clock?

To add more info: A Teensy 4.1, fresh out the bag (running blinky) shows a clock of 120 MHz. If I then compile blinky on my system and download it the clock will bump up to 144 MHz. So the main flash clock seems to be set too high in the latest Teensyduino/Teensy 4.1 libraries.

On the Teensy 4.1, at power up, what maximum clock freq on the Winbond chip (U3) should I expect to see? I'm seeing 143.7 MHz and that seems out of spec. Is there something I'm doing wrong here? What clock frequency are you seeing? I'm using Teensyduino 1.57 with the 1.8.19 ide.

Thanks for the reply. For reference, many industry people start with the "NIST standard" - NIST Special Publication 800-193. Lot's of jargon, all centered around the idea of a "root of trust", some part of the system you know is safe. NIST doesn't give a solution, it just has the requirements of...

I'm confused. Is this a Dice (Riot) design? (root-of-trust bootloader, shared secret, double hash, "signs/authorizes the update" sorta thing)? Or is this a "root-of-trust bootloader, symmetric key, hex is encrypted, flash image is stored encrypted and decrypts to ram, executes from ram, only...

I'm wondering, doesn't the processor have four I2C controllers? Why are only 3 available?

So we'll cook up a version (I prefer i2c_t3 so we'll likely use that) and then focus on the core issue: getting those changes rolled into the release version. MorganS - I hear you. It sounds like we are doing something crazy but many I2C devices require a complete report read or they won't...

The I2C buffer length in all versions of the wire library is hard-coded to 32 bytes. I must be the only guy in the world who needs it larger (up to 1.1k at times, but typically more like 53, 350, or 530 bytes). If I cook up a way to make it settable what are the odds I can get that code...

The wire library (Wire.h) hard codes the buffer length to 32. I can edit wire.h but my code is hard for others to use (they have to know to edit it too). Is there some "project specific" way to change the I2C buffer length?

How about a for loop? for (x = 0; x < 32; x++) { sine1.frequency(FREQ[x]); }

The idea with spi driving multiple things is: 1) Each thing has a "slave select" line (ss), it's like a chip select line. 2) When a device's ss is high it means "don't listen/respond", when ss is low it means "listen/respond to the clock and data" 3) All ss lines are usually high, you set a...

If I have: uint16_t write_count; write_count = Serial.write(Buffer, length); I was expecting to have write_count show the number of bytes written. It does not. It's just zero. What should the correct behavior be here? (The reference pages shows it returns a byte [the source seems to show...

I see what is going on. Serial.readBytes gravitates toward reading in 64 byte chunks. That's cool. I just may not get all the data in one grab. My test application is too basic. If I send 80 bytes the Teesny 3.0 gets the first 64, sends them back, then gets the remaining 16 bytes and...

Some random pieces of the puzzle: HID only gets one 64 byte packet per frame (1ms) in each direction. If your PC-side code sends less than 64 bytes then somewhere in the PC is code that pads the buffer up to 64 bytes. On the embedded side all 64 are received. You have to know how many of...

The pc side in and out buffers are set large. I'm new to Teensy and Arduino - If I make changes to the usb stuff how do I recompile it?

Just so I'm clear, you are wanting to communicate from the PC to the Teensy 3.0 with USB but not relay the traffic to a real UART, right? If so what does your Teensy code look like? Have you speed tested the code? What data rate (for a give data transmittion size) are you getting...

So I have Teensy 3.0 code that is a simple serial echo: void loop() { uint16_t length = Serial.available(); if (length > 0) { Serial.readBytes((char *)Buffer, length); Serial.write(Buffer, length); Serial.send_now(); } } On the PC side I: track the time of: loop...

So I'm fairly new to Arduino and the Teensy. I have three Teensy 3.0 that I've written some simple/fun projects. Here is the what I'm after: I have an app that I wrote for and MSP-430 (TI processor) and I'm wondering how hard it would be to port it to the Teensy 3.0. The MSP430 talks to the...