jmarsh's latest activity

  • 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.
  • J
    Looks like there is some good news... I have (very basic) LCDIF code running and it is able to push 1024x768x60@8bpp (dual-buffered) without any problems... and can even manage 1280x1024x60Hz if the SDRAM is overclocked to 200MHz. I'm not exactly...
  • J
    The USB port on the Teensy 4.x is plain old USB 2.0, it is not going to support analog audio no matter what. It can however function as a USB audio sink, so you can still send audio data from the PC that way.
  • J
    That very much depends on how you interpret a "write"... if the cache is enabled in write-back mode and you repeatedly write from the CPU to the same location, the speed of the SDRAM is irrelevant because it will always hit the cache and never...
  • J
    LittleFS is designed to be included in C++ code, not regular C. You'd have to write a transitional layer (C++ code that exposes C functions) to use it from C code.
  • J
    Writing simply is faster by design because it's a "one step" transaction - the CPU says "put THIS data at THIS location" and then goes on with its other business. For a read it says "retrieve the data at THIS location" and then has to wait around...
    • write_burst.png
    • read_burst.png
  • J
    Regular test with MEM_CACHE_WBWA: Test with MEM_CACHE_WT (Write-through): Test with MEM_NOCACHE: Write speeds are pretty much the same for all modes so doesn't really matter for framebuffer usage... except for WT or NOCACHE you don't need...
  • J
    Obviously for the random access tests the cache will be a hinderance, that is the point of including them (they are "worst-access" times). For framebuffer usage access is typically sequential but it's nearly exclusively writes (from the CPU...
  • J
    It's in the examples folder in my github repo.
  • J
    Obviously non-identical code will give different results... mine has an extra step inside every read/write (the address is permutated rather than incremented, even for the sequential tests where the permutation evaluates to +1). The test results...
  • J
    eLCDIF is a lot less flexible. It can't do tricks like pixel-doubling/line-doubling so low VGA resolutions aren't available, and the minimum bitdepth is 8bpp even if you only use 16 colors (4bpp) or monochrome (1bpp) so a lot of memory is wasted...
  • J
    I updated the FlexIO VGA code to be compatible with the SDRAM DevBoard. The results aren't great... it struggles badly if both buffers are in SDRAM, and even with one buffer in DMAMEM it still can't keep up with resolutions above 640x480. Given...
  • J
    I did find a bug in your initialization routine, there's a typo skipping IOMUXC_SW_PAD_CTL_PAD_GPIO_EMC_09: https://github.com/mjs513/SDRAM_t4/blob/main/SDRAM_t4.cpp#L35
  • J
    Since the Teensy is a 32-bit CPU any variables equal or smaller to that size will be transferred in one instruction (can't be interrupted).
  • J
    Without knowing the code it really could be anything, but it would mean the bootloader mode is just a symptom of a software bug that needs finding/fixing rather than a problem with the physical PROGRAM signal.
  • J
    I don't have the means for testing out different caps in that position. I managed to get the old one off but that's about the best I can do. (I'm also not sure if it's just the RAM that is unstable at that speed, sometimes the sketch just...
  • J
    Just a wild guess but does the software you're running on them have some code hidden away somewhere that would execute a debug breakpoint instruction? For example something like FreeRTOS that would try to break into a debugger when a fault is...
  • J
    Initial work available here: https://github.com/A-Dunstan/SDRAM_EXTMEM The two main ideas here are: - make it easy for existing/new code to support either PSRAM or SDRAM by using the existing extmem_* functions - initialize SDRAM automatically...
  • J
    That's the sort of thing I was hinting at earlier... Since the linker will only include an .obj file when it provides one or more previously unresolved symbols, if you override all external symbols from an original (cores) file it will be...
  • J
    There is a way to override functions provided by the core, without modifying the core files - provided they're defined in .c/.cpp files and not inlined from headers. Hopefully I can have some example code up later today.
  • J
    For signed integers: no, they are not the same. Integer division is defined as rounding towards zero but a right-shift will round down (towards negative infinity). Right-shifting a negative value is usually undefined behaviour in C.
  • J
    I'm not sure why people keep mentioning about the core changes / Teensyduino-1.59-b5, I never had any problem with that since I use a copy of cores kept in sync with Paul's github. What I do have an issue with is the SDRAM_t4 library not being...
  • J
    Obviously you've modified the board from the design that is linked, to remove the capacitor. And the repo is still additionally broken because the earlier issue I pointed out in extmem.c hasn't been corrected, so I don't know how all your tests...
  • J
    There's a public facing PJRC page with a picture of "DevBoard 4.0", linking to the current board's design, with a link to the github repo saying "Uses SDRAM_t4 library" - which doesn't work properly out of the box. Sure, it is clearly stated to...
  • J
    That seems a bit silly when the default hardcoded speed is 133MHz which works fine with DQSMD set to zero. If someone is going to edit the code to adjust the speed they can also change the MCR register setting, otherwise the default setting...
  • J
    Received my board today. Unfortunately I can't get the SDRAM to function correctly - SDRAM_t4::begin reaches the bottom and fails the pattern check. The same with pretty much any other test, the entire SDRAM always reads 0 no matter what/where...
  • J
    By default, memory in DTCM (for Teensy 4.x) is ordered like this: Initialized data -> Uninitialized data -> Stack This means if there's a stack overflow, the uninitialized data can be silently corrupted. There's a 32 byte "no man's land" setup...
  • J
    The pushbutton is wired to connect the reset line to GND.
  • J
    jmarsh replied to the thread Teensyduino 1.59 Beta #4.
    The Cortex M7 doesn't support NEON. Look like HAS_NEON is getting defined somewhere when it shouldn't be.
Back
Top