jmarsh's latest activity

  • J
    I have an OV2640 that can do 1600x1200... it also does onboard MJPG compression, so the framerate isn't absolutely terrible at high resolutions. Supposedly the CSI can handle this. Currently don't have any way to connect it to the devboard though...
  • J
    It does. DMA can access anywhere the CPU can (besides the CPU cache - which isn't directly addressable anyway). Start with a DMASetting instance, set the misc settings that aren't going to change between calls. For the actual transfers use a...
  • J
    You have to set the pin mux (IOMUXC_SW_MUX_CTL_PAD_GPIO_*) and the pin pad configuration (IOMUXC_SW_PAD_CTL_PAD_GPIO_*).
  • J
    If the only thing being changed is the location of the pixel buffer (DMAMEM vs SDRAM) so all the other code is exactly identical... maybe it's those BMCR0/BMCR1 register settings causing reads/writes to happen in the wrong order?
  • J
    Does the camera deliver YUV data (rather than RGB) ? It looks like chroma/UV values are being significantly rounded somehow.
  • J
    Another idea occurred to me while I was digging through old VGA cards looking for a DAC. It was pretty common for video cards "back in the day" to have a VESA feature connector. They were mostly intended for connecting to accelerator cards, which...
  • J
    jmarsh reacted to joepasquariello's post in the thread using DMAMEM with Like Like.
    You're telling the compiler that you want RingBuf to be stored in a different location from the rest of the class data member. If you want the RingBuf to be in DMAMEM, you'll have to either put the entire class in DMAMEM (not sure that works), or...
  • J
    It doesn't. The USB Host library resets the port and replaces the interrupt handler.
  • J
    Yes it works just like the Teensy 4.1 host port. Except I'm very careful not to hot plug since there's no protection IC.
  • J
    I sent a pull request for cores to support multiple startup hook functions: https://github.com/PaulStoffregen/cores/pull/734 The reason I need this is because both the SDRAM library and a threading library that my USB Host implementation uses...
  • J
    jmarsh replied to the thread C++ code inside ISR.
    That mutex implementation looks very iffy. If a thread locks multiple mutexes (including using one mutex recursively), interrupts will be re-enabled the first time unlock() is called. Usually it's not allowed for an ISR to try to claim a mutex...
  • J
    Speed-wise, SDRAM sits between RAM and PSRAM. Even in a worst-case scenario (random access reads that negate the benefits of a cache and burst-access) it's more than twice the speed of PSRAM.
  • J
    jmarsh replied to the thread Memory Usage for T4.1.
    Well you started off saying you had very little RAM1, but the first screenshot shows you actually have quite a lot...
  • J
    jmarsh replied to the thread Memory Usage for T4.1.
    You must be changing more than that, the overall size of the code (the number on the FLASH line) is growing by nearly 4 times.
  • J
    Have managed to get my USB Host library to work with the micro usb port on a Teensy 4.1 - should also work with a USB-C port on the devboard but I need to be able to run multiple startup_middle_hook() functions first...
  • J
    You can still get the same thing if the CPU and DMA are both accessing it.
  • J
    Found an interesting thread: https://community.nxp.com/t5/i-MX-RT/i-MXRT1060-SEMC-SDRAM-Data-Corruption/m-p/1170738 Basically boils down to: set the BMCR0 and BMCR1 registers to 0x81 if you don't want reads/writes to end up possibly out of order...
  • J
    I believe it does - @Dogbone06 made this board that has B0_13 disconnected from PTB4. You can see there's pads on the board to join them if needed, but at the moment it runs fine without that connection.
  • J
    I think it would be best to disable the pattern test at the end of begin() in the case where you explicitly want to experience read errors (or just call begin() and blindly ignore the returned value).
  • J
    jmarsh replied to the thread Reading from OV7670 using FlexIO.
    Actually, I'm an idiot... this is only a 32-bit CPU so the compiler would split a uint64_t load into two 32-bit loads. The alignment problem makes sense though, for DMA the source/destination has to be an even multiple of whatever the read/write...
  • J
    jmarsh replied to the thread Reading from OV7670 using FlexIO.
    I guess the easy way to check would be to put something in shifter buffers and then try to read it as 8 bytes: FLEXIO2_SHIFTBUF0 = 0x89ABCDEF; FLEXIO2_SHIFTBUF1 = 0x01234567; uint64_t i = *(uint64_t*)&FLEXIO2_SHIFTBUF0; printf("Result: %llx\n"...
  • J
    jmarsh replied to the thread Reading from OV7670 using FlexIO.
    Looks odd to me... again they're setting SSIZE to 5, which does 4x64-bit reads (32 bytes total)... which won't work when the shift buffer hardware registers are only 32-bits wide. It's not safe to access hardware registers with any width other...
  • J
    jmarsh replied to the thread Reading from OV7670 using FlexIO.
    IIRC you can't chain all eight because they're split into two groups of four (shifter4 can't feed shifter3). I can't recall where I saw this but it was hidden away somewhere - maybe it was a misconception due to the 1050 only having 4 shift...
  • J
    Since it's being used to measure a delay between the clock signal and when data actually arrives from the SDRAM I think the "best" value would vary based on the board design / track lengths.
  • J
    Crashing during the upload might be indicative of a power supply issue (erasure of flash memory triggering a brown-out) which is being avoided when the code is slimmed down due to less flash pages being occupied...
  • J
    Added a mandelbrot sample that cycles the palette colors (still using only 4bpp/16 colors because it turns out I only have RAMDACs on hand, not direct VGA DACs...) A picture of 1920x1080 output for @Dogbone06 :
    • IMG_20240129_133556209.jpg
  • J
    Try changing this code to this: CCM_ANALOG_PFD_480_SET = 0x80 << 8; CCM_ANALOG_PFD_480_CLR = 0x7F << 8; unsigned int frac = roundf(8640.0f / (float)(clock * clockdiv)); if (frac < 12 || frac > 35) return false; //...
  • J
    CCM_ANALOG_PFD_480_SET = (0x80 | frac) << 8; Doesn't setting the top bit (0x80) disable the PFD?
  • J
    If CCM_CBCDR_SEMC_CLK_SEL and CCM_CBCDR_SEMC_ALT_CLK_SEL are both cleared in CCM_CBCDR, the base clock (before CCM_CBCDR_SEMC_PODF is applied) is the CPU clock*. So you can use that with dividers to get other frequencies... but the downside is it...
  • J
    Without a capacitor yes, but the control register must have DQSMD set in those cases. If it's not set there is no chance of those speeds working no matter if the pin is floating or connected to anything.
  • J
    Hmm probably this would work: LRsample = (((int64_t)leftSample << 32) | ((int64_t)rightSample & 0x0FFFFFFFFLL));
  • J
    The code is on my github, with instructions in the elcdif_vga example describing how to build the R2R ladder for VGA output (except the pin numbers are still for Teensy 4.1 since there's no equivalents for micromod)... I'm not hoarding it by any...
  • J
    This is why I made my code automatically use DQS for any frequency above 133MHz... it's guaranteed not to work otherwise, so why make it an option.
  • J
    Converting a signed int32 to signed int64 performs sign extension. Consider if rightSample was -1 and it wasn't sign extended, it would become 4294967295...
  • J
    jmarsh replied to the thread Bootloading the code.
    All the source code for cores.a is in the github repository that I linked to.
  • J
    jmarsh replied to the thread USB Host Library MIDI hanging.
    Don't use -D USB_MIDI, that's for making the Teensy function as a USB device which isn't needed as a host.. Start with the USBHost_t36 examples and work from there, since they're known working code (you won't see 5V on the USB port until it's...
  • J
    jmarsh replied to the thread Bootloading the code.
    All of the code that handles receiving and flashing new programs on the device is inside the bootloader (the MKL02 chip). It is not public. The code that transfers control to the bootloader is here...
  • J
    It's not clear what you expect the result to be, or what is wrong with the results you've posted. What is clear, is that by calling readString() inside a while loop you are potentially throwing away input without processing it.
  • J
    @Dogbone06 In the schematics for the board way back at the start of the thread, there's a diode shown going from VUSB to +5V. If I supply external power to +5V the USB port won't be able to power anything connected to it... so I guess using a...
  • J
    startup_early_hook() must have the FLASHMEM attribute.
  • J
    I'd say they were basing that on either the required pixel clock (70.5MHz for 1280x800 vs. 75MHz, the supposed max for eLCDIF) or the required memory bandwidth for 24bpp (184MB/sec) rather than it being a limitation of the signal generation hardware.
  • J
    It's not much to look at currently because I'm using 4 bit output (16 colors) through resistors to run a VGA monitor. I need to dig up an old ISA VGA card with a removable DAC that I can repurpose... or get USB working so I can have file...
  • J
    Switching the pin to low (which would only work if the pin is set to output mode) would short the incoming voltage to GND, via the Teensy. You have to physically prevent excess voltage reaching the pin.
  • J
    Can't find any reference to the maximum supported resolution in the documentation but I doubt the clock could go much higher.
  • J
    Must have made a mistake somewhere yesterday... first thing I tried today was setting the SDRAM speed to 133MHz and running the elcdif sample at 1280x1024x60... and it works perfectly. No glitches/corruption visible on the frames, and no...
  • J
    It won't, because they are fixed-function pins on the Teensy's MCU. There is no possible way they can function as anything other than regular USB 2.0 data pins, despite what you signal to whatever device they're connected to.
  • J
    Changing the connector to USB-C won't do anything, it doesn't magically upgrade the capabilities of the port.
  • J
    My understanding is that making things 32-byte aligned is usually due to the CPU cache since each line is 32 bytes long. That really doesn't matter for a framebuffer, since the CPU is the only device that writes to it, it is safe to perform...
  • J
    https://github.com/A-Dunstan/SDRAM_EXTMEM/blob/master/examples/elcdif_vga/elcdif_vga.ino LCDIF requires 64-byte aligned buffers, the extmem_malloc interface doesn't have a way to request aligned allocations... should probably fix that.
  • J
    Using the board manager try manually updating to 0.59.5. That's the current test version for the upcoming 1.59, 1.58 had some bugs that could cause crashes on startup like you're seeing.
Back
Top