jmarsh

Unless I've missed something I don't think you need to do anything special for this - module outputs can be routed into xbars without affecting their regular pin outputs.

About the AOI modules: There's 2 of them (AOI1 and AOI2) which map to the XBARB modules (XBAR2 and XBAR3). Each AOI module has 4 outputs, each output has 4 inputs so 16 inputs total. These come from the corresponding XBAR modules, explaining why...

Since copy constructors aren't disallowed I assume there's no harm in using them: void calc_PTK(const uint8_t* mac1, const uint8_t* mac2, const uint8_t* nonce1, const uint8_t* nonce2) { decept::hmac::HMAC ihmac(decept::Hash::kSHA1); const...

Trying to use this as a library within Arduino IDE doesn't work due to main.cpp duplicating setup() and loop().

I've personally never had to worry about bounce on the T4 when using the hardware decoders, they have built-in filtering.

Minimum unallocated memory = any allocation smaller than or equal to that size will succeed, anything larger may fail (but can possibly succeed).

Note that __brkval/_sbrk() isn't an accurate indicator of "free" memory - it's an indicator of the minimum unallocated memory, there may be more that is not currently in use but the allocator hasn't returned it to sbrk.

Yes, UGREEN and Tenda are listed in the driver source code. I'd say that device does support bluetooth but it just isn't enabled in the windows drivers (it has a very minor quirk that makes it non-standard).

Wifi work is progressing... I can scan 2.4GHz and 5GHz channels and probe access points: Device<0x20207300> activate configuration 1(-1) Device<0x20207300> activate interface 00 altSetting 00 New Endpoint<0x20207900> type 3 New...

Each bank can be allocated in 4 ways: unallocated, ITCM (code memory), DTCM (data memory) or OCRAM (extra RAM2). Four possible values requires two bits of storage. The way this is handled in the hardware is by dividing a single 32-bit register...

A while ago I bought a $5 USB wifi/bluetooth adapter from aliexpress. They seem to be very plentiful, advertised under a few different brands but usually including a mention of AX900, Wifi6 and Bluetooth 5.3 or 5.4. I thought it would be a...

The short answer is no, because a class may be masquerading as another class due to inheritance (and all sorts of other tricky situations). (The long answer is g++ has __PRETTY_FUNCTION__ which gives the entire current function signature and you...

One day someone should probably try to figure out why DMA_SDIO mode is so horribly slow... I feel like it would help a lot with audio tasks.

That's all wrong because OP is already using the built-in SD card slot.

I hate this error because it's so vague. Here's example code that triggers it: #include <Arduino.h> static const char g_abc[] PROGMEM = "ab"; class foo { public: static const char& alpha(int x) { static const char g_alpha[2] PROGMEM = {3...

The SCB AIRCR register for example; if the top 16 bits aren't written as 0x05FA the register write is ignored. So attempting to set SCB_AIRCR_SYSRESETREQ to 1 won't work, you have to set the whole register which makes most of the template stuff...

How do you set more than one register field with a single access? I'm thinking of a case where you can only update part of a register if a separate bit is also set at the same time.

Either case is possible, the compiler can omit any statement it thinks doesn't have any effect unless it's marked as volatile.

It's possible that since the original code used an __asm__ statement with no apparent side-effects (no registers or memory marked as outputs) and no volatile specifier, the new compiler simply decided to omit it.

I don't really understand what the output is meant to be showing, that's very obviously a process related to VS code rather than Arduino.

It's easy enough to do as long as you use different specifiers for initialized data vs uninitialized data, similar to how FLASHMEM and FASTRUN work. This separates data into separate sections so the uninitialized variables can be tagged with...

Doesn't really narrow it down - they're both shades of red/orange.

It should get automatically set when you upload from a PC. The output you're getting the first time you run the first sketch shows this. It's just not keeping it when powered off - are you sure your battery is good?

Are we sure the "blinking light" was actually the LED on pin 13, not the programming LED?

This will give the appearance of working but won't behave correctly - you can't declare const arrays in EXTMEM, only uninitialized data.

The way these sort of things usually work is that they fork a popular repository (not using the built-in github fork functionality but cloning it manually) and poison the release downloads with malware. Then they force-push empty changes multiple...

Padding exists to round the code size up to a multiple of 32768. The code size increased by more than the old padding size (2568), requiring an extra 32768 bytes total to be used.

An x-ray would not replace the firmware with the blink program.

Series resistors (around 22 to 100 ohms often) damp reflections/ringing on fast logic and thus stop double-clocking which can cuase malfunctioning, particularly for clock signals - they are not doing a lot for EMI though. Think of this as like...

The USBHost_t36 library still has no support for isochronous transfers. My teensy4_usbhost library does.

Funny that the AI did not realize that if ((d & 0x80) ^ (crc & 0x80)) { can be simplified from three logic operations to two (or technically, one logic op and a sign extension): if ((d ^ crc) & 0x80) {

Even just looking only the clock speed, it's four times as fast. 64-bit (aarch64) does help because it has 31 general purpose registers compared to 8 on the M7 (arm thumb).

For the record: SdFat isn't case-sensitive, internally it converts all names to upper case when doing comparisons.

The pi5 uses a quad-core 64-bit 2.4GHz A76 ARM processor, the Teensy is a single-core 32-bit 600MHz M7 ARM processor. There's a league of difference.

If the old firmware was wiped/corrupted they wouldn't automatically reset to the blink program. Only holding the button for ~15 secs would do that, because it causes it to be copied from the top to the base of the flash memory.

I resolved it by making my own USB host library instead of using the one that's full of race conditions.

No change for me when running the code from this post; the serial monitor still does not reconnect properly, Teensy is blocked waiting for the serial connection.

That would still have the same problem with the serial monitor. The windows MTP driver also silently fails to initialize when the device doesn't respond with 5 seconds (there's further events in Event Viewer confirming this).

I'm talking about the OS (windows) MTP driver... it appears to have a 5 second delay in its startup, which probably blocks access to any interface on the device. Edit: I know what's going on... the windows MTP driver is trying to talk to the...

I only see 2 redraws; one is a short time after the upload finishes, the second is approx. 5 seconds later. Any attempts to open the COM port before the second update fail. I had a look in \windows\inf\setupapi.dev.log from when the driver for...

Windows 10 with Arduino IDE 2.3.10. Yes, I think that's when it started. Reproducible sample: #include <SD.h> void setup() { pinMode(LED_BUILTIN, OUTPUT); digitalWriteFast(LED_BUILTIN, LOW); Serial.begin(0); while(!Serial)...

uSDHC2 has more than one set of pins available, see page 314 of the reference manual (rev3): (This is why I once suggested an MMC add-on for T4.1 would be a good idea - all 8 data pins are available...)

The issue is not the code, it is the Arduino IDE not reconnecting automatically after an upload. This works with any config except Serial+MTP.

Something I am seeing when using the Serial+MTP config, every time I modify code and upload a new sketch I have to close/re-open the arduino serial monitor because it won't auto-reconnect (Teensy waits at while (!Serial);) (Slightly related...

MTP was already added to the core library several versions ago, that's why it's not looking for the separate library.

There is something I'm hoping to test in the near future, using newly available c++ features and templates...

You want PROGMEM for const data in flash, FLASHMEM is for code/functions. Since your structs are actually holding pointers to string literals, those will need to be stored separately in flash; F() is documented as intended for this but does not...

Because for Teensy 4.x all data defaults to RAM1 unless you specify otherwise.

This is handled by specifying the appropriate mode when calling the uart's begin() function, e.g. Serial1.begin(9600, SERIAL_8N1_RXINV_TXINV) specifies 9600 baud using 8 data bits, 1 stop bit, both RX and TX inverted. Although I think it would be...