defragster's latest activity

Don't recall ever seeing signs of that github author here posting notes on the work. If there is a FAST MRAM option of decent size and usable QSPI operation - it would be higher cost - but cool. BTW: PSRAM does survive across WARM restarts...

Thanks, and Merry (post) Christmas to everyone! Robin & I spent the day with both our families. I'm just now catching up to messages from the last couple days.

Merry Christmas, happy Hanukkah and an upcoming 2025 - may it be a great year all around!

Not specific to TD 1.60b3, but an updated version of my Norton 360 was automatically installed earlier this week. Running the Arduino IDE 1.8.19 + TD 1.60b3 this morning for the first time since the update, Norton decided that several of the...

Thanks to @BriComp for the title which says it all :)

MRAM Mfr. Part # AS3016204-0108X0PSAY (* 2 for 32MB) --- but the price $49.88 WOW.

Apologies for the wiring mess and messy desk! Played a bit more with byte interval timing today and now I can control each led individually by toggling specific bits in specific bytes of specific frames And I can also read out buttons clicks...

Only this version from PJRC is usably programmed to make a 'Teensy bootloader' based device.

If you start with a fresh U1 and a PJRC U2 then it should work as @PaulStoffregen posted. The SDRAM thread boards have been built using the xxxCVL5B chips with the PJRC U2 and they work...

https://forum.pjrc.com/index.php?threads/call-to-arms-teensy-sdram-true.73898/ Enjoy

I would not rely on a SD card for an important file written so often. External flash chip is maybe more reliable, I don't know. The best solution is to use a FRAM.

Modern flash memory basically always has wear leveling built into the firmware of the storage media. So, frequent writes will cause it to write to different spots on the card and level out the wear and tear. But, they may not do wear leveling on...

Seems the writes could be spread across the media by pre-allocating a file and just putting updates on the end - followed by a flush or write in 512 blocks? Not sure of all the details - but that should keep the directory entry from getting hit...

The answer must be yes, but by how much I don't know. What about adding some SPI FRAM which can be written very fast many many times?

That is the general behavior. Using TYQT/tycommander allows picking a unique Teensy with multiple online. See this post for a IDE mod file (platform.local.txt) to call Tycommander instead. Only if the same hex goes to more than one then does it...

Any effort to overclocking needs to account for added heat that will generate - especially on those speeds noting: "cooling req'd" With proper cooling the faster speeds can work and might shorten cycle times giving desired results as long as the...

For IDE 2.x the scroll bar on the preferences can be very slight on the edge - scroll down to add the URL. Seems that was documented on the install page as it was a common issue. For IDE 1.8.19 once that supported version is installed. Close the...

If the board offered a creative place for two pins Paul would find it. Don't forget it is also using the longer USB-C connector so even that room wouldn't be there if a T_4,x were configured for that to fit. Note on tool change in Beta thread -...

See this page: https://www.pjrc.com/teensy/td_download.html For IDE 2.x the JSON link shown must be added to see the PJRC Boards to install. Then the PJRC boards will be listed. For IDE 1.8.x it has to be installed directly from Arduino site -...

Maybe this helps? Can't tell from screen shots: For IDE 2.x: use the Board Manager installer For IDE 1.8.x use only TeensyDuino after pointing it to the Arduino 1.8.x install location - it does the work of the Board Mgr install.

Indeed, look at a 4.0 and 4.1 ALL the middle ground is used at least once both top and bottom - not to mention the unseen middle layers. The d+ and d- are packed under the connector close to the source - as they need to be for reliable use.

Which 2 pins would you want to give up to be able to have this?

Note: if power is removed from the Teensy any CrashReport findings will be lost. The data for that only survives across powered warm restarts. Opps - wrote long ago and left without posting ...

If there is a Crash when not connected code like that will clear it unseen however. To run unconnected until the Crash - then recognizing it by restarts, Then connect it to a Host with SerMon and code like this will then spit it out without it...

Didn't start a new adventure yet, but continued an old one a bit... went and did some reading and configuring - now the memory protection unit, or MPU to friends, is working for the money, enforcing the user/supervisor split as it should. Now you...

Good to hear there is a view on something new! Wow - never saw that - awesomely good/bad/hoaky And over 385KB available?

Future Teensy with will USB-C. I can't discuss any other details at this time. I probably should not even write this message, but hopefully it at least answers this 1 simple question.

I was (and am) surprised by the I/O speed and the overall snappiness of it. I haven't benchmarked the raw SD card access speed, but even when writing a single large file to the filesystem (read: with the filesystem layer making things slower) I'm...

Given Paul doesn't design the actual microprocessor within the Teensy, he is dependent on the chips that are designed by the microprocessor companies. Given the newer chips no longer have 5 volt tolerance, Paul can't magically make the future...

Indeed, the hardware we get really depends on what NXP (or perhaps other microcontroller manufacturers) design into their chips. I have no control over this. In the past I've had conversations with people at NXP, especially expressing desire...

Wikipedia does a good job explaining the history of Unix it was one of the first comprehensive operating system for computers, and the fore-runner for DOS, Windows, Linux So not a small compact RTOS, the real-deal So the notion that it can run on...

Wondered that too - even a T_3.6 which would have less structural differences ...

How would it perform on the much faster T4.x?

Read into that sumotoy and that is what he was finding: Old controller two finger gestures zoom in/out worked - but new controller failed to have those and neither has the expected U/D/L/R slide detect.

I'm not sure there are any, unless you're already familiar with it. This is more of an exercise in futility than anything else - though I have to admit that it does perform way better than I expected.

Now hang on a moment... p1 is also a global variable and the ISR is using it to track the current write position? How does that work when loop() is constantly resetting it to the beginning, regardless of whether bufferdone is set or not? This...

The FT5206 touch chip used on these displays has gone EOL. The new displays are starting to ship with the FT5316 touch chip that is suppose to be fully compatible per my communications with BuyDisplay. I just tested one with the new FT5316...

And you soldered the connection, right?

I just got one of these (Thank's Ken) - I'm seeing the same results - and no solutions yet - but Found this: but strangely I can get only the zoom in and zoom out with my FT chip, In this 9 year old effort...

Is that Flash SD a 512MB device? That's small. That example uses SD.sdfs. Try it using one of the PJRC SD examples that don't use sdfs. Also Teensyduino ships with a specific version of SDFS - if there is another version in the libraries...

The println() has no expected affect - except blasting out 'CR+NL' 1999 times. Except noInterrupts() won't let that happen? So, if not that, then something unshown/unseen is causing trouble. 1Msamp/sec means this is happening 500 times/sec...

FINAL UPDATE: Changing the crystal to the correct 24 MHz fixed my problem and it is all working now!

Crosspost ... 'delay cycles' ... That explains why the DOCS and perf show write being 4X(?) faster. I wondered about the cache being undercut on return - that and the changes from configure. Can you post code for write?

Same here. p#18 was done looking to dual test the native access with the bitbang. Didn't find write_func(), but ran the test as posted, then found native access returning bad data just doing the fixed pattern write as coded in the PJRC example...

Can it write as well? After the PSRAM_Configure() - the normal access fails. Can it be undone to allow other code to use normally?

Great stuff

Lately been trying to consolidate/organize my IMU efforts and decided to grab a couple of new sensors that are used on the Nano Sense V2, the BMI270/BMM150 specifically. For reference Sparkfun has a BMI270 sensor and Waveshare has a BMM150...

Thx for (re)posting @mjs513. Just ran this (132.9 MHz) with the PJRC PSRAM test and times are faster: AFTER at 132: test ran for 25.52 seconds BEFORE at 88: test ran for 36.43 seconds 57 Write Read passes 8MB - where 44 need calc of next number...

Big thanks to @defragster for dogging this problem that had me stymied and to @KurtE for the quick fix!

Already did msg 17:)