jmarsh's latest activity

My understanding is that you can do this. The logic mode has 5 inputs; four of them are fixed while one is selectable, but it's clocked. Using shifter 4 as an example: IN0 = D8 IN1 = D9 IN2 = D10 IN3 = D11 OUT = D12 IN4 when INSRC is set to 1...

One other thing about implementing programmable logic: there's a part of the XBAR module called the And-Or-Inverter that can logically combine XBAR inputs. The documentation explicitly mentions GPIOs but I've read it multiple times and can't...

Come to think of it I did post some example code for logic mode a while ago: https://forum.pjrc.com/index.php?threads/one-bit-off-when-receiving-arinc429-with-flexio.76264/#post-353293 Unfortunately something went weird with the original thread...

I don't know what the minimum latency is but the output of shifters in logic mode isn't clocked. A FlexIO timer can be used to clock one (out of the total five) of the input signals, which can sometimes come in handy for a feedback signal.

The main limitation of the logic shifter mode is that its inputs and outputs are fixed, depending on which shifter is used: - Shifter 0 in logic mode uses FlexIO pins 0-3 as input and outputs on pin 4 - Shifter 1 in logic mode uses FlexIO pins...

Still no list of changes in the top post?

That page is from the days of Teensy 2.0, things are a bit more efficient since then. The second USB port (the host port) is off by default so disabling it probably won't do anything. The primary port is acting as a device so it's not going to...

There's no selectable clock for PXP, it just runs off IPG (which is usually the cpu clock divided by 4).

PXP uses 12 bit bilinear, at least according to the documentation. There's even diagrams and equations on pages 1914/1915.

VID and PID are defined at the device level, not the interface level.

You could do that with two DMASettings chained to each other; the first one would loop over the first X-8 bytes in a line, and the second one would handle the remaining 8 bytes with the loop count set to the total number of lines to process.

It's only going to happen when you write a multi-byte value (i.e. your WriteBytes function above) across a page boundary. It's not completely clear what other values make up the records but I'm guessing most of them are written as single bytes...

The LPSPI modules aren't meant to be driven anywhere close to that though, their documented max is only around 30MHz.

This confirms the problem is as stated above; if this record starts at address 10465 then the bad data is at 10496, which is address 0x2900.

Are the two non-functional USB Serial devices above the ports related?

The physical pin numbers on the Teensy are simply made up, they are not in the hardware manual. You can see how they map to real pin names in KurtE's chart, along with their possible functions/mux values...

It's mostly fixed. Pins can choose one function to perform out of their fixed available selection; that's what the "portConfigRegister" assignment does. A pin that doesn't have any PWM function in its selection can't be used for PWM, and the ones...

int8_t* testMe(uint8_t* myList) { //uint8_t* numList = new uint8_t[sizeof(myList)]; uint8_t* numList = (uint8_t*)malloc(sizeof(myList)); // effectively the same as the above statement memcpy(numList, myList, sizeof(myList))...

Also I'm not sure what types of graphics you're rendering, but if it's just basic UI stuff (placing font glyphs and basic rect fills) consider using LCDIF's paletted mode. That way each pixel can still be 24-bit color but they only take up a...

The only relevant advice I can think of is make sure your writes from the CPU happen sequentially/with as few other memory accesses between them as possible. The reason being it's impossible to write an entire cacheline with a single instruction...

It breaks LittleFS because you changed the size in FLSHA1CR0, which affects the address used to issue commands to a flash chip attached to the second port (whether or not there is a chip attached to the first port).

Search LittleFS for "0x00800000" (equivalent to 8MB). I'm sure OP understand the ramifications so I'm not going to waste my time informing others how FlexSPI works.

That variable tells you the total size of available PSRAM. It doesn't tell you the size of the first chip only, which is needed to know the starting address of the second chip (which is the supported configuration for flash) in order to send it...

The fixed 8MB size is hardcoded in other places besides the core, for example the LittleFS library.

Why use the 1.8V when there's 3.0V versions available?

MTP devices don't show up as drive letters, it must be some other device connected to your PC.

Did you intend to use "double" (a 64-bit floating point variable) instead of an "int64_t" (a 64-bit integer) ?

TPD35014 supports USB 2 speeds (according to datasheet). SP0503BAHTG supports USB 1.1 speeds (according to datasheet). Yank SP0503BAHTG off your pcb and try again.

This sounds like a problem with your USB port/traces rather than anything to do with the bootloader. You say USB1 is the host usb, so USB2 is the port you're trying to connect to the PC? That looks backwards: USB1 has pulldowns on the CC pins so...

The logic doesn't look right. If a bit is to be unset, ORing with its inverse will set every other bit in the register. Instead just leave those bits out of the assignment and they will implicitly be set to zero/cleared.

From the looks of that is it splitting FlexRAM into 3 different regions, ITCM/DTCM/OCRAM? I tried to get that working with teensyduino once but it caused issues with things that used hardcoded address like the crash reporter.

That isn't blocking during the transfer, it's blocking while queueing the transfer. Most likely because it's not an atomic operation and there's a chance of an interrupt occurring in the middle and breaking the linked list.

Where are you seeing this in the current Teensyduino source code? This sounds more like you're not setting the priorities for your own interrupts high enough to avoid them being masked/interrupted by others. Of course if you are trying to log...

Maybe I missed it but it seems you're setting the SPDIF0 clk to use PLL4 (AKA audio PLL) as a source but never configuring it? That PLL is powered off/disabled by default.

At ~40MB/s, USB is physically the fastest way to get data in/out. If it's not getting the job done then you either need to investigate other methods of output buffering, or give up.

You don't have to do anything with it if you don't intend to use it.

RAM1 has 209248 bytes of data while RAM2 only has 12416 bytes. Your 65536 byte array is definitely in RAM1.

From memory, we managed to get 200MHz with no cap at all just leaving the trace disconnected - have you tested what the maximum safe speed is for that case? It may be higher if the trace is longer.

It's there at C11. But it could be a case of the value having to match the design; we found 10pf to be best, but the layout on this board looks a little bit different and also seems to use different size components.

Is there an external 5V pin, to power it from an external 5V supply or power connected devices that require 5V?

I would add that PSRAM tends to perform much better for sequential access rather than random access, for example if you had the choice it would be better to use array style storage rather than something like a linked list.

What I would try: the next time you plug the Teensy in and it shows up as COM5, go into device manager and tell it to uninstall the driver for that device.

Because __has_include() doesn't check if a particular file has already been included, it checks if it can be included based on its existence on the host machine. The MTP library is indeed pulling those libraries into the build simply because...

It's not ignoring it; defined(__has_include) evaluates to true and __has_include(<USBHost_t36.h>) also evaluates to true, hence the following lines are processed by the compiler. You seem to be hung up on the compiler not supporting...

Compilers don't simply ignore errors. If you put #if some_thing_that_isnt_defined anywhere in a source file the compiler will complain when it tries to evaluate it.

How could the compiler evaluate __has_include(x) if it had no definition for __has_include ?

You would still need to connect the grounds.

I don't think that is the cause. If the compiler didn't support __has_include it wouldn't be trying to pull in the USBHost_t36 library, rather that line would trigger a compilation error. This could be a filename case issue (the file is actually...

Have you ever actually used an ESP32 board? Or any other USB CP210x serial device? I think you may have a bad driver installed that is mistakenly trying to handle the Teensy, even though it's not compatible.

For the diagram the idea seems to be using two LPSPI interfaces with one in master mode and the other in slave mode using the voltage-converted/delayed clock signal. The question is how fast are these SPI devices going to be driven? Given the low...