D
Reaction score
53

Latest activity Postings About

    • D
      Dogbone06 reacted to KurtE's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      Not sure, but most of their carrier boards, have something like: That is from their ATP board schematic. As for AREF, don't see that on their stuff. With Teensy it is probably geared more to the 3.3v pin. I don't believe raw VIN is passed to...
    • D
      Dogbone06 reacted to Rezo's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      To be honest im not sure either. Why would you need to know supply voltage if it won't work with anything much less than 3.3v? Also if it's battery powered there will be a DC-DC converter providing a stable 3.3v regardless of cell voltage...
    • D
      Dogbone06 reacted to jmarsh's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      What I'm wondering is why would Sparkfun connect the pin that way (on the micromod) in the first place though? Since it can't be used as a regular IO pin if it's hardwired to a constant voltage... nor can it be used in analog mode to monitor VIN...
    • D
      Dogbone06 reacted to jmarsh's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      Finally got around to sitting down and mapping out all the exposed pins properly and found something odd - there's a pin labelled BATT_VIN/22/A8. My first thought: "how can this pin be both BATT_VIN and an I/O pin?" The answer is it can't/isn't...
    • D
      Somewhere in history back @mjs513 posted these images of the bare DevBoard I got and scanned associated with the pin names. These are in the DOCS folder of the original github by @defragster that got abandoned when the lib was forked ... not sure...
    • D
      Dogbone06 reacted to Rezo's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      We copied the Micromod pin pad labels, that's why it says BATT_IN - it's a Micromod label. It is wired to 3.3v on the ATP board and any other MM carrier board with a voltage divider. But it's just a GPIO, so can be used for anything else on the...
    • D
      Hi I try to understand this library. Most of the things are understandable. But I was not yet able to figure out, what this function does:wdt.expired(); Is it usable in the loop function of my program, or is it just used by some other functions...
    • D
      That looks impressive!! Whats the resolution on that? I see you are wired in an 8 bit bus, and you mentioned DMA (which the original lib didn’t support as it used FlexIO3) I assume you split the data on FlexIO1 or FlexIO2 port? BTW a logic...
    • D
      Hi Rezo, it's 1024x600. It is a good display. My vision is not good enough for anything much smaller than this display. I have not set up DMA yet. It is still using FlexIO3. Still not that familiar with using FlexIO with DMA. More to learn and...
    • D
      Well I finally ordered the Buydisplay ER-TFTM101-1 with capacitive touch and had it configured for parallel communication in 8080 mode. Using parts of @Rezo's ILI984x_t41_p library, I was able to adapt my Ra8876LiteTeensy library to use the...
    • D
      Dogbone06 reacted to defragster's post in the thread xenForo Improvements with Like Like.
      Seems to have been working ,,, just sent you a PM with image and a sketch?
    • D
      Dogbone06 reacted to defragster's post in the thread xenForo Improvements with Like Like.
      Interesting - perhaps that is something unique to Sr+ - AddOn's not the same as the old forum - perhaps that is one. @BriComp - I'll add you to PM noted above to see if different? PM conversation for SDRAM on DevBoard seems to allow drag and drop...
    • D
      Dogbone06 reacted to defragster's post in the thread xenForo Improvements with Like Like.
      Okay confirmed - as a Sr+ drag and drop works for @defragster - mistakenly thought others had dropped too - where @mjs513 and @KurtE are also Sr+ and they may have managed as well on that PM thread. Doing the SDRAM @Dogbone06 has also been on...
    • D
      This is not true. Lockable Teensy (when permanently set to secure mode) will reappear after power cycling in USB bootloader mode if the flash memory gets corrupted, either by a failed upload or any other cause that alters even 1 byte of the...
    • D
      That's nice to know, I didn't know that. Haven't used any locked Teensy for real world use yet. I just tested it and you are right, a "bricked" (locked) Teensy will in fact reappear and can successfully be flashed. This is very good! But for an...
    • D
      Perhaps the "loader utility" that is contained in the 2nd part of the EHEX file is not needed when the update is done via FlasherX, i.e. from within an application that has already passed the "security barrier"? I know so little about the locked...
    • D
      I guess we'll never truly know as this is secret stuff. I am just happy that FlasherX can use the EHEX when removing the last part. I use FlasherX for everything these days, it's so conveniant and safe to have the device update itself. Using the...
    • D
      Here's something interesting. I use FlasherX as mentioned before. I just did something dirty, I removed the second part of the EHEX EOF. Meaning, I removed the 200ish lines after the first EOF. And then had FlasherX use that EHEX to update my...
    • D
      Dogbone06 reacted to Rezo's post in the thread Call to arms | Teensy + SDRAM = true with Love Love.
      Meanwhiles, for anyones enjoyment, here is a video of a music player demo running on LVGL v9.0.0 I think there is a lot of room left to optimize. It has two screen sized frame buffers (1.3Mb each) that LVGL writes into, and the eLCDIF reads from...
    • D
      Dogbone06 reacted to Rezo's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      Quick general question - can the SEMC/SDRAM read data from one address (using DMA for example) and write to another address at the same time?
    • D
      I made quick note somewhere on past pages with initial speed results showing longer at faster - but not seen with current test. Another thing the 'OneScanCap.ino' occasionally shows is an added 3 seconds to all times across the tests between one...
    • D
      Dogbone06 reacted to mjs513's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      Sorry been distracted today for a bunch of reasons. Reran the tests but added the time to copy the array DMAMEM to EXTMEM: 0 errors, 1010 microseconds to copy DMAMEM to DMAMEM: 0 errors, 319 microseconds to copy RAMMEM to RAMMEM: 0 errors...
    • D
      Dogbone06 reacted to KurtE's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      🤔I have not seen the problem of using the 8MBtye SDRam on the GIGA for the camera to read into. But when I looked at their schematic their SDRam setup looks very different than what I believe you are doing on these dev boards. That is they...
    • D
      Dogbone06 reacted to jmarsh's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      That looks pretty much the same as Dogbone's devboard to me - 16 bits of data, 2 bank pins, row and column addresses are sent multiplexed on A0-A12.
    • D
      Okay, Thanks. Something else then ... MCU cycling faster and leaving the SDRAM behind it seems ...
    • D
      Thanks Paul for giving us an answer! :giggle:
    • D
      Confirm, I generally don't comment on this code security stuff beyond the info already published on the code security web page and in the core library code, the 3 automatically generated programs and Arduino IDE plugin code. The NDA and...
    • D
      Confirmed. Even with Verify the Teensy.exe grabs/reuses .eHex part #2 when it is missing. But Close and Open Teensy.exe and point to an .eHex with No part #2 and: Still interesting that .eHex part #2 is marginally unique - but any .eHex part...
    • D
      @PaulStoffregen, I would very much appreciate if you can reply to the questions that @joepasquariello wrote above. I suspect there may be NDA stuff prohibiting you from doing that, if that's the case then please let me know. Thanks! 🙏
    • D
      As for the problems at MCU F_CPU over 600 MHz - perhaps it is these likely these ns_to_clocks() timing based values not adjusting for enhanced F_CPU_ACTUAL clock rates so recovery times are being violated ? // configure SDRAM parameters...
    • D
      Dogbone06 reacted to Rezo's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      I set it to 1 and skipped 133 as I figured there was no point in testing it - we know it works
    • D
      More fun trivia? Seemed the "wfi" would wake to allow incoming USB Serial data so indeed this works: if (CrashReport) { Serial.print(CrashReport); Serial.print("Any Key to continue ..."); delay(50); while (1) { if (...
    • D
      Wondered what happened with an MCU OC build - went to 720 MHz - Not good ... Should the freq math calc's be adjusted?: Start 57 tests with 5 reads 132.92 MHz ... wait::##########CrashReport: A problem occurred at (system time) 18:41:47 Code...
    • D
      Nice, as expected no cap seems to work up to 206 MHz - based on prior runs by one or more others, and here. Odd though it should have a line for 133 MHz if the downloaded sketch LINE#1 wasn't changed from: #define FIRST_SPEED 0 And looking at...
    • D
      Dogbone06 reacted to Rezo's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      @defragster Test with no cap Test results 57 tests with 5 ReReads: At 166 MHz in 142 seconds with 0 read errors At 196 MHz in 132 seconds with 0 read errors At 206 MHz in 130 seconds with 0 read errors At 216 MHz in 128...
    • D
      Posted this just now: https://github.com/mjs513/SDRAM_t4/tree/main/examples/OneScanCap and running with DevBoard v 4.0 and twin 6.8 pF caps the summary is: Test results 57 tests with 5 ReReads: At 133 MHz in 157 seconds with 0 read errors...
    • D
      Perhaps better to first ask, does the hardware truly need cache disable? Seems hard to believe. The effect of the cache isn't even visible outside the ARM core, other than fewer actual accesses to memory. That's why arm_decache_flush_delete()...
    • D
      Dogbone06 reacted to Rezo's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      As I mentioned, I tried to flush the cache but it had no affect at all. I can't confirm nor dismiss that the hardware needs a region with cache disabled, but from all the code examples I have observed (NXP, LVGL) and application notes, they all...
    • D
      Dogbone06 reacted to jmarsh's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      It's relatively simple to walk through all the MPU regions and add a new one at the end. Shouldn't need to disable/enable the data cache as long as it's done before the SDRAM/SEMC initialization. I agree that it should not be necessary though as...
    • D
      Dogbone06 reacted to Rezo's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      Ugh… I should have multiplied the screen resolution by sizeof(uint32_t) in the flush call.. 🤦🏻‍♂️ How did I miss that one? Will test in a couple of hours - I'm sure that’s going to fix it. But regardless, the L1 Cache application notes does...
    • D
      Dogbone06 reacted to jmarsh's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      I don't think that's always accurate, especially for non-sequential writes - tile / character based rendering for example, would greatly benefit from writes to separate lines being collected in the cache before being flushed to RAM.
    • D
      Working without cache attention seems called for and beneficial. And only reads suffer with cache not covering that region that is only used for writes? Posted twice the note from NXP reads go to ~1/4 speed without cache - writes drop 1 MB/sec...
    • D
      Interesting - that case in use here would be easy to test.
    • D
      Dogbone06 reacted to Rezo's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      If we can reset it, and run though the same sequence of region setup, then we should be good - no? or, we know what the value of i is, as we have 11 regions set up in configure_cache and the next region can be 12.
    • D
      Dogbone06 reacted to Rezo's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      @mjs513 @defragster think we could do this? Perhaps we can add a function to the class such as uint32_t setNoCacheRegion(uint8_t size) Based on the size (we can use a struct to set values) we can return the calculated base address for the non...
    • D
      If Paul suggests that, it would be worth a try to emulate the needed parts of that config function to add that new non-cache region. As I read the startup.c code for the configure_cache() it seemed like altering the cache/MPU when already set...
    • D
      Let's first make an effort to add it in the SDRAM_t4 library. Maybe disable interrupts, turn off the cache, add that extra region, then turn the caches back on. That is, if arm_decache_flush_delete() and arm_decache_flush() aren't enough...
    • D
      Dogbone06 reacted to KurtE's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      For what is worth, back in T4 beta cycle, I was running into issues with the caching getting in the way. Sometimes the cache flush and/or delete could help, other times a royal PIA... That is why I found it sort of amusing that we used the...
    • D
      Dogbone06 reacted to Rezo's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      I have a library that supports 8080 for the ili948x Uses FlexIO and DMA. So it has no cpu hold up. You can use that with the camera
    • D
      Dogbone06 reacted to Rezo's post in the thread Call to arms | Teensy + SDRAM = true with Like Like.
      Right so piping it directly to the display without the need for a ram buffer. It can be done, but you’d need a new dev board for that. I have seen many implementations of LCDs on memory driver on the STM32 platform.
  • Loading…
  • Loading…
Back
Top