Search results

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 object. TL,DR: it shouldn't be documented because...

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 accumulate and eventually cause an over or underrun.

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 sample rate was 48KHz things would be a lot simpler.

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 configuration risks frying the Teensy.

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 IO pins) to ensure it receives a safe HIGH voltage...

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 bi-directionally, in which case it would be better...

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 bulk (regular TCP traffic in this case using...

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 standard filesystem interface. fgets has nothing to do...

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? You've just created a headache for anyone who has...

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 workaround.

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 should be aimed at.

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 can cause undefined behaviour for non-USB 2.0...

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"); // stop while(1); } // else continue as normal

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 strongly-ordered memory isn't guaranteed to work atomically...

How? In this unlikely situation where both a thread and an interrupt are messing with an IRQ's state, they can't overlap execution - the interrupt will interrupt the thread, do its thing (returning the IRQ to whatever state it was upon entry) and then the thread will continue none-the-wiser. The...

I think it's safe to say the System Control Space range invokes undefined behaviour. You don't need to do this though, since there are NVIC registers that let you enable/disable specific interrupts with direct writes rather than read-modify-write sequences (that could be interrupted).

Just curious, since this is such a large project / makes extensive use of the flash memory, would you be able to test my pull request that speeds up flash reading time to see if it makes any observable difference in speed?

You don't need the interrupt / cpu intervention. That timer can be routed through the crossbar to trigger SPI directly. Then SPI can be read by DMA to fill a buffer, only requiring CPU intervention when the buffer is full (and automatically switching to a new buffer to give the CPU plenty of...

These are all timing/trigger problems, that can be solved with hardware timers. It's not clear what interrupt latency has to do with any of them. Timers aren't limited to 16 bits; quad timers are 16-bits each with four timers in each module that can be cascaded, giving a maximum total of 64-bits.

50 instructions is practically nothing at 600MHz, it's ~83 nanoseconds. It's likely less than the overhead of exception entry, and there's a systick interrupt that is constantly firing every 1ms. This still isn't a practical problem unless you have a real-world scenario where it affects something.

As already explained, it isn't. The code for the usb serial port is completely separate from the UART code.

Actually they do work for any memory. The address used in the instructions is irrelevant because the cortex-m7 has a reservation size of 0xFFFFFFFF, i.e. the entire memory space. This simplifies the operations to this: - the ldrex* instructions set the exclusive access flag - clrex, any...

But Serial is the object for the USB serial port, and you've been discussing the mechanics of the UART serial port... I find it hard to believe there's any practical limitation here other than one being imagined.

I am also very confused because here this started out as a discussion of using USB serial and is now discussing the details of the hardware UART serial driver... not to mention the original issue even earlier was how to wait for a flexPWM interrupt. What's the practical issue here that can be...

Not sure why you keep saying it loops over it when that only happens during yield(), which your program shouldn't be entering unless it's idle. And the duration of time that interrupts are disabled is practically nothing; looking at the C code it's probably less than a dozen opcodes, which is...

It's easy to do it for a single value (that's what ldrex/strex are for) but significantly harder to atomically update multiple values.

Haven't looked at it but I would guess it's to protect against someone using Serial.print in an ISR, which could trigger in the middle of updating some of the buffer tracking variables and end up corrupting them. Disabling the serial interrupt alone wouldn't be enough to protect against this...

You can't use the C++ threading primitives on Teensy. They have to be implemented (e.g. like all the other stuff provided by newlib) by a kernel since you can't block on a mutex, semaphore, etc. without some sort of context/threading system including an idle thread that can always run when...

Priority of the main thread is 127.

With TeensyAtomThreads you don't need to do all the setup stuff, it's already taken care of by the time setup() is run. It uses some clever tricks to create the initial thread during startup using the default stack. So you can just use setup() and loop() like normal, all you have to add is the...

The library can do that, so I'm not sure what the problem is.

Yes due to the increased CPU speed, but floats would be faster still.