jmarsh's latest activity

Unfortunately no. You can remove "volatile" to give the compiler a bit more leeway for scheduling, but the best you can do to try to keep the code portable is wrapping it in a macro that throws a compile error for any machine that isn't ARM...

As per https://github.com/PaulStoffregen/USBHost_t36/issues/87, devices should be given 2ms to process a SetAddress request before sending more requests. That lines up with the timing here.

This might be handy if you wanted to reverse a value without involving the CPU (e.g. using DMA) but otherwise the rbit opcode is going to be much faster.

The Arduino IDE automatically compiles all the extra code used in libraries based on files that the main sketch includes. I don't know how this is intended to work with VS2022, but it's obviously not compiling and linking the code from the SD...

My guess would be that the idle thread actually does something that's considered important (probably the original Teensy yield code...) and using vTaskDelay(1) is a hack to force the kernel to switch to it. I say "hack" because yield() shouldn't...

Can you just set freertos::g_yield_task to false so it doesn't use vTaskDelay() ?

The eeprom writing functions also call arm_dcache_delete and memcpy while the flash memory is unavailable.

I'm not going to PR any code that I can't test.

Wouldn't want to see the regular 8MB PSRAM unconditionally lose half of its potential prefetch speed gain if the PR was merged, I believe there are better ways of handling it.

Didn't you already solve this problem by updating to the latest Teensyduino beta, in the other thread?

Teensy 4.x pins are not 5v tolerant - your diagram shows that's what you've wired on the high side of the switches, which will fry your Teensy. You should stop using this circuit immediately to prevent permanently damaging it.

Hmm. So Edge must have it cached somewhere on these machines from visiting back then (even though I've supposedly purged all browser saved data, as far as it will allow me) and is showing the details for that old cert even though there's no...

Both RAM1 and RAM2 are fixed sizes of 512KB each. FlexRAM only refers to how RAM1 can be divided for code (ITCM) and data (DTCM), the overall size can't be changed.

Practically all browsers these days are built from Chrome (including Edge).

Well... it's a mild relief that's it's not something on my end, but also very disturbing that this is a widespread issue with Edge that doesn't seem to be getting any attention...

I've been seeing some odd browser issues involving multiple sites, including this one. It's affecting multiple PCs on my home network. It's only affecting MS Edge, when not using inPrivate mode. What typically happens is I'll either enter the URL...

This is a random error that happens with Arduino, restarting the PC is the easiest way to fix it or manually cleaning out the temporary files.

Not really. Lowest possible interrupt period for USB is 1/8000 (USB High Speed has 8 microframes per 1 msec frame) but the Teensy is operating as a device - that means the host controls the bus and polls the Teensy to send/receive. Ideally it...

That's not unusual, I've seen some fairly variable rates from CD drives... typically they slow down as the head moves inwards.

This entire time, I have been talking about the original code. Because it is a problem that is easily mitigated by not relying on the undocumented IntervalTimer hack and following the instructions in the audio tool about having an unused I2S...

Not sure why all the complication, all you have to do is set up an IntervalTimer for a frequency of 128 / 44100 and measure when it actually fires. If it's off by any amount (which it will be due to insufficient resolution) the update drift will...

The sample rate is whatever the device on the other end of the USB connection decides to use. The problem is the audio updates don't occur precisely when they should which leads to underruns/dropouts in the USB audio stream... If the default...

It's a bidirectional chip, there is no "right" or "wrong" side for most applications. But in this case one of the chips (the Teensy) can't handle 5V, and only one side of the buffer (the B side) can output in open-drain mode. Any other...

It's not particularly good at it though since IntervalTimer doesn't have sufficient resolution...

You don't explicitly need to level-shift because the GPIB side can be operated in open-drain output mode, i.e. it only ever drives the pins low or high-impedance. So you would use 3.3V pull-ups (or activate the internal pull-ups on the Teensy's...

What's the actual goal here? If you've got the Teensy wired to the Terminal side (the D pins), you're risking frying it if TE goes low. So it makes more sense to simply tie TE high rather than drive it.... unless you want to operate the buffer...

Not sure if it's implemented or even feasible with lwip, but have you given any thought to supporting OOB (out of band) data? It's a bit similar to how USB device can have bulk and interrupt endpoints; the regular, "big" data traffic goes over...

Are you sure? It looks like the sensors connected to them are powered by 12V, if they're returning 12V signals those 10K/20K resistors will only be dividing down to 4V which is still too high.

You say you're using 3.3V but that schematic very obviously shows everything being powered by 5V. Having the LED being run directly from an IO pin isn't great either, the resistor isn't high enough to prevent it from pulling more than 4ma.

Did you connect the GND pins on both boards?

It sounds like the hub is either designed for USB-C and there's unmentioned adapters involved, or it's just really cheap/badly designed and doesn't check for a connected device unless it detects significant current draw.

The fuse is connected inline with the positive supply current, connecting it to ground would turn the Teensy into a short circuit that would likely kill anything you connected it to.

No it doesn't. You have it backwards; LittleFS and SdFat are both implementations of the FS interface. Some of the functions may have been "inspired" by the SdFat functions originally but that is because they are generic enough to fit any...

I think you need to actually understand what the FS class is for - what happens when someone calls your new fgets method on an FS implementation (e.g. LittleFS) that doesn't support it? Or even a File object that isn't a currently opened file...

But File isn't just a wrapper for SdFat... It's a generic file handling class. Adding a function to it means every underlying filesystem object must support it. That's exactly the sort of thing that libc's formatted I/O functions are designed to...

I disagree, because fgets is a formatted I/O function provided by libc. Formatted I/O sits on top of low-level functions like read(), write(), etc. that take file descriptor arguments, which is the level of functionality the abstract File class...

File inherits Stream, so can't you use File::readBytesUntil() with a terminator argument of '\n'?

There has to be a DHCP server somewhere on the network for the Teensy to get an address from. A switch doesn't include a DHCP server, it just forwards packets between machines.

For a start I specifically said QUAD TIMER, not FlexPWM. Then you use the crossbar to route the timer's output to the appropriate LPSPI_INPUT_TRIGGER.

I've told you what can be done, I'm not going to spend my personal time working on something I'm not interested in for free.

Are they really required to be variable values? Seems like it would be easier to put the arrays as class members and dynamically create the class object rather than dynamically create the arrays.

You have to allocate the memory from PSRAM using extmem_malloc and then use placement new to initialize it. void* ptr = extmem_malloc(sizeof(String)*NumberOfLogs*NumberOfLines); message = new (ptr) String[NumberOfLogs][NumberOfLines];

I don't think the Mega and Uno should both be I2C masters on the same bus... I'm reasonably sure they can both work in slave mode; I would suggest doing that and having the Teensy act as the master, polling them for updates when it wants to.

What is the purpose of this code? Do you have something connected to pin 33?

Maybe start by showing what code you've tried to use with it? Typically when the port is idle, both D- and D+ should have approximately 15K resistance to GND. The readings you actually get can vary quite a bit depending on your meter.

No, because they are completely separate ports.

The USB Host code is full of race conditions when it comes to handling failed transactions, as soon as you see an ERROR followup it's a big red flag. It also uses a value of 0 for CERR (infinite retries) in the queue transaction descriptors which...

The memory mapping for PSRAM is always enabled regardless of whether or not it's actually present. extern "C" uint8_t external_psram_size; ... if (external_psram_size == 0) { fprintf(stderr, "You need PSRAM installed for this program\n")...

It means pin 13 is high.

LDREX/STREX are only guaranteed to work with memory-type=normal, not device or strongly-ordered. In practice it's down to how it's connected to the CPU; peripherals on an AXI bus have a reasonably good chance of working. The case where...