Search results

When done here - score/cut at edge of both pads enough to cut the metal cross piece then lift that short section out?

How forcefully deep was the cut between the pads made? Noted in a thread some time back there was one PCB lay that had some other trace down a layer IIRC.

Running this sketch on a T_4.o or T_4.1 exhibits bad behavior when going to 1.008 GHz //https://forum.pjrc.com/index.php?threads/t4-1-detect-reboot-type.76679/page-2#post-365582 // https://forum.pjrc.com/index.php?threads/how-to-read-last-reset-reason-for-teensy-4-1.66654/post-286811 extern...

Years back this sketch was made to test starting Teensy at 600 MHz and lowering the speed to see it work, Here is a modified version that after testing it at 600 MHz and LOWER now makes a pass at the two no cooling OC speed changes. Another section added behind "//#define YES_COOLING" that...

The point was to test an alternate hardware path that suggests the desired functionality can easily be had with USB_Host. A Teensy presenting DUAL SERIAL "example" using that 'USB_Host Indicated Example' quickly showed it to work. As noted above the device with CP2105 will NOT present the 480...

Win 11 download flagged as usual - reported as SAFE and requested KEEP and then file properties 'unblock. Install ran fine. Builds since then working as expected - just Sermon to TyComm - about to post about that

To refer to my earlier post: Have a DUAL USB: "Triple_Serial_Test" on USB host of "SerialTest" and with two lines of: USBSerial_BigBuffer userial(myusb); // Handles up to 512 but by default only for those > 64 bytes USBSerial_BigBuffer userial2(myusb); // Handles up to 512 but by default only...

Is this the same DUAL Serial Teensy presents? VID/PID not the same - but would allow testing with programmable smart device.

The playing done here is all building and running without issue.

DMM on continuity test it should see NO CONNECT. It only takes a tiny shard to complete when not wanted - that is not enough when needed :(

opps - wrong thread ???

It still works - powered by USB that is good. Looking at the linked page it shows the right spot and seems it has been hit in the picture. One note there is: "Use a DMM to verify there is no continuity between the pads." Apparently there is enough metal in the cut trace to pass power...

The kickstarter solder iron seems nearly interesting Same unit (now with HDMI output) with larger solder station platform, spool and tool holder and helping hands - just needs a fume fan :) https://www.amazon.com/Andonstar-AD249S-Max-Microscope-Soldering-Electronics/dp/B0CSNWG8CL With...

It takes using the new JSON :: https://www.pjrc.com/teensy/td_160-beta6/package_teensy_0.60.6_index.json To know about the new beta. And the Beta numbering for 1.60 is 0.60 so it won't suggest forcing a new beta over a release build - that's part of the reason for unique JSON for each beta...

@PaulStoffregen might know what the ribbon cable re-plug might do to the PHY chip? Isn't there an enable pin to the chip? Can that be toggled off on to maybe trigger the same behavior/reset? Is this happening on more than one device?

opps - that makes sense. Fastest was noted as slower before too by another.

Yeah, it will saturate - and all the pins go somewhere on your CB - the two near USBhost GND pins just seem a good stabilizing conduit. Odd - saw 3273 at 816 MHz and note above says 3214 at 1 GHz? That was new TD beta and 'Faster'. quick OC run no heat sink at 816 MHz: CoreMark 1.0 ...

That big baseboard taking 5°C is nice - saw that socketed base helps back in earlier tests. I see that is a "NE" board - but those pins and the USB Host not connected missing some opportunity :) ... and the cross pin row too. ... Just don't forget to unset the 'OC cooling' Speed before compile...

$50 dev board : https://www.microcenter.com/product/665366/arduino-nicla-voice ($53 DigiKey) Or direct ARDUINO.cc Key Features Component Type: Development Board Components: Mainboards Processor: Syntiant NDP120 Neural Decision Processor Clock Rate: 48MHz Flash Memory: 512KB SDRAM: 64KB...

5 year ago Article ends with "Volume production is scheduled for summer 2021," The link is wrong, but they have that NDP120 and newer: https://www.syntiant.com/hardware

encrypting 21504 bytes to T:\TEMP\arduino_build_106015/CoreMark.ino.ehex Memory Usage on Teensy 4.1: FLASH: code:16708, data:4040, headers:8944 free for files:8096772 RAM1: variables:4864, code:14192, padding:18576 free for local variables:486656 RAM2: variables:12416 free for...

running coremark here - from PJRC copy? - three years old last use: Newest TD 1.60b6 T_4.1 at 600 MHZ FASTER: CoreMark 1.0 : 2406.93 / GCC11.3.1 20220712 (flags unknown) / STACK T_4.1 at 528 MHZ FASTER: CoreMark 1.0 : 2118.20 / GCC11.3.1 20220712 (flags unknown) / STACK Linear 13%...

:) PJRC Jumped to 32 bit then newer improved versions of the same chip family - all working from a single TeensyDuino install and as similar as possible - adhering to Arduino standard - even when pins had to move. Chips fell out of production - added speed/usb_host/RAM+/FLASH+/multi usb...

For a given count of bytes the same 'int' type should all store the same - uint or uint32_t - being explicit with uint32_t just forces to a known known?

Download here was marked 'NO' as usual and had to 'Keep' anyway. That maybe EDGE security feature, Never use chr0me - systems are safer uninstalling it ... which I have one here to do that on just now. As shown in p#8 - marking 'Unblock' in properties allows it to then run without the Defender...

Had to override EXE to KEEP the download and now it needed to be Unblocked to run: Works fine to install and build after that

Post edited to LITTLE and strikethrough on BIG

Perhaps the byte storage order? seems this is AI so YMMV {AI is WRONG} Arduino Interger endian versus Teensy ARM Arduino's AVR microcontrollers typically use Little Endian for their interger data types, while Teensy ARM microcontrollers, such as the Teensy 3.1, use Big LITTLE Endian. This...

Also: void setup() { while (!Serial); uint xx; Serial.printf( "sizeof uint %d", sizeof(xx)); } void loop() {} gives: sizeof uint 4

Yes, " teensy 3.2 has unsigned long 32 bits " uint32_t is explicit name though uint should be the same as it is a 32 bit MCU

Discussed over the years ... IIRC ... Given the PJRC bootloader it may be compatible, or work with TeensyDuino ... but naming and such cannot violate the PJRC naming rights of the Teensy branding, or suggest it is a PJRC sanctioned item. Thanks Paul! - that most threads have never gone like...

Yes, PSRAM pins are usable as indicated on the rear of the PJRC product card.. They are probed on startup to see if PSRAM or FLASH chips are installed, not sure what effect that may have.

Indeed, code could be added there to catch missing systicks using the ARM_DWT_CYCCNT count that was added only to make micros() work. Would add code 1k/sec that 'mostly' isn't needed?

Suppose so - opps - lost track of units. As first written it would count ahead for ms misses, but that went away with edit for issue that or something caused limiting to 1 ms.

micros() is based off the LAST systick seen and ARM_DWT_CYCCNT then - as long as it isn't a whole (MILLI)-second away it will properly count elapsed micros. Quick rewrite just looks for 4 seconds of ARM_DWT_CYCCNT and gives similar results here: edit: though just seeing the second...

Quite Right! TyCommander allows Multiple Teensy connect and usage and support Dual and Triple USB as well. And gives info like what COM PORT # for Windows use and even allows friendly naming tied to each unique Serial#. It also caches all the streamed SerMon data to a disk TXT file for later...

The Integrate worked for the IDE 1.x installation. The use with platform.local.txt is very good and the added --delegate still uses the PJRC Loader for upload. Got that added when the T_4.x LOCKABLE went into Beta. Though @Koromix has recently posted an alternate EXE of TyCommander on github...

During testing 'with interrupts enabled during write' I have managed to lock up the Teensy Indeed, not at all unexpected.

Yikes, that is unexpected and unfortunate! Anything in particular going on at the time? Is that specific to Program/PCB Flash? The 'Test Integrity' in examples ran some series of read write verify with file create and delete for hours and never came across that. Though I'd guess it was least...

on that we agree.

For each? T:\T_Drive\arduino-1.8.19\hardware\teensy\avr\libraries\LittleFS\src\LittleFS.cpp: 276 } 277 278: static bool blockIsBlank(struct lfs_config *config, lfs_block_t block, void *readBuf, bool full=true ); 279: static bool blockIsBlank(struct lfs_config *config, lfs_block_t...

Except for RAM they all call out to that? static int static_erase(const struct lfs_config *c, lfs_block_t block) { //Serial.printf(" flash er: block=%d\n", block); return ((LittleFS_SPIFlash *)(c->context))->erase(block); }

Apparently, I missed that path ... <edit> that was the seen path CALLBACK from the library

Good! :: formatUnused() was written with that 'Pre-Erase' in mind! Odd there is a perf diff as the code already has blockIsBlank() check before erase? Maybe there is another path? int LittleFS_SPIFlash::erase(lfs_block_t block) { if (!port) return LFS_ERR_IO; void *buffer =...

Have any alternate source PSRAM been acquired or seen to work? After some years of PSRAM use this is the first note where this type of issue was reported. The only occasionally recurring issue was due to unclean soldering where good soldering and removed flux showed them to function.

Having an alternate copy of the SD files when it properly works should never be needed, and will prove the solution. it would be best to work through this without any efforts toward sabotage of the expected use. Those alternate errors will point to the real root of the problem and will go away...

Haven't looked in some time - but goal was to keep same what could be. Only 3.3V signals welcome. Compare the PJRC cards - they are more alike than different as far as the pins - though ALT/secondary options not so much maybe? LOCKABLE is special order - nothing different if left unlocked and...

Is the build setting the appropriate teensy one of these to have BUILTIN_SD defined? #if defined(__MK64FX512__) || defined(__MK66FX1M0__) || defined(__IMXRT1062__) #define BUILTIN_SDCARD 254 #endif

Opps - skipped that part. That 1-2 ms is a big hit, way worse than Arduino yield - especially as refined in PJRC version.

see p#3 - following not applicable to RTOS usage. yield() calls process background Serial and EventResponder items. It has been optimized and really shouldn't be anything like 1 or 2 ms as it can be called millions of times per second when there are none of those things active. Putting this in...