profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/FrankBoesing/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

FrankBoesing/FastCRC 107

Fast CRC library for ARDUINO

FrankBoesing/Arduino-Teensy-Codec-lib 83

MP3/AAC/FLAC Codecs for Teensy 3.x

FrankBoesing/memoryboard 28

6 * spi- jedec memory for teensy

FrankBoesing/ILI9341_t3DMA 22

Descendant of ILI9341_t3, but DMA and 150KB Buffer in RAM (T3.6 only)

DD4WH/Teensy-DCF77 17

Decode time signal with minimum hardware [Frank Boesing & DD4WH cooperation]

FrankBoesing/Minimal-SDR 10

Only one active component (MCP2036)

FrankBoesing/FlexiBoard 8

Board for Teensy 3.5, 3.6

FrankBoesing/fonts 8

Google Fonts converted for ILI9341_t3

FrankBoesing/LinearTimecode-Decoder 6

LTC decoder for Teensy Audio Library

push eventWMXZ-EU/MTP_t4

WMXZ-EU

commit sha 9c2ca81440646ba4c9989f5f6acbc34c7df8f8f0

Create mtp-basic.ino

view details

push time in 8 hours

issue commentWMXZ-EU/MTP_t4

MTP device not in windows explorer, serial port not available

Is there a specific USB driver to use? I set up on another computer (without any Arduino or Teensyduino software) and at first the teensy was there as Teensy under an unknown device until the device drivers finished loading/installing then it moved to portable devices as MTP USB DEVICE with a yellow ! next to it and the error message "Device driver software was not successfully installed" came up. BTW the serial port only displays in Device Manager when the port is set to serial. Goes away when set to MTP disk and programed.

Maybe a driver issue?
Or teensyduino? I just don't know.

Fluxanode

comment created time in 9 hours

issue commentWMXZ-EU/MTP_t4

MTP device not in windows explorer, serial port not available

Thanks for the reply.
I am using a new T3.5 with arduino 1.8.15 and Teensyduino-beta9 with the built-in SD. Both with a fresh install. I'm not sure what you mean "if you declare multiple sd devices (as with mtp-test.ino) : sdx[0] MUST exits." I'm only using the one onboard SD with the out of the box install, do I need to change something in the test program? What versions did you test with and what example program are you using? I have followed the install directions to the letter and tested using the included MPT-test.ino.

Can you review the discussion on the PJRC forum MTP responder? You can see I worked with Defragster on this and verified the SDfat is working and my install is good and working, at least the SD part...

Fluxanode

comment created time in 10 hours

push eventPaulStoffregen/cores

PaulStoffregen

commit sha c84bb2fc56b7d60af82cd92ec84f4e9e51fd6ab1

Fix compiler warnings

view details

push time in 14 hours

push eventPaulStoffregen/cores

PaulStoffregen

commit sha eb0e021f56fe296c570e9883526db094d0a03c05

Enable fault handlers on Teensy 4

view details

push time in 14 hours

created repositoryPaulStoffregen/MyFault

created time in 15 hours

push eventPaulStoffregen/cores

Frank

commit sha 303a50219ddd5d3c4ec87389984c7ee83380c00a

rmv printing of "Hello World" text from crash report

view details

Paul Stoffregen

commit sha 44960b6f9fac5fbd6a01042cbcf631a64bc5f37d

Merge pull request #575 from FrankBoesing/patch-7 rmv printing of "Hello World" text from crash report

view details

push time in 17 hours

push eventPaulStoffregen/cores

Mike S

commit sha 5af9d01bfda415259ce207dbab9f81f7695cd09c

Added Sysclock setting to Crash Report

view details

Paul Stoffregen

commit sha 23f84924bcc284d06765575739a0f4bc38fcd515

Merge pull request #574 from mjs513/master Added Sysclock setting to Crash Report

view details

push time in 17 hours

PR merged PaulStoffregen/cores

Added Sysclock setting to Crash Report

Good Morning Paul Made 1 slight addition to the crash report. I added printing the System clock to report. Only affects crashreport.cpp.

Unless you want to crash the panic temp from shut down to cool down. I can't see me making any other changes.

Let us know when you want to freeze changes to crash reporting.

Thanks Mike

+3 -3

0 comment

1 changed file

mjs513

pr closed time in 17 hours

push eventWMXZ-EU/MTP_t4

WMXZ-EU

commit sha 06e2dbe7312b6fe2901de565b9de8cd96b8ecfdd

updated mtp-logger

view details

WMXZ-EU

commit sha c10f8b7fd671569e5b61f4f16330e2456a246b0b

Merge branch 'master' of https://github.com/WMXZ-EU/MTP_t4

view details

push time in 18 hours

issue commentWMXZ-EU/MTP_t4

MTP device not in windows explorer, serial port not available

MTP does work on T3.5. Just compiled and run it. compiled with USB type "MTP Disk Serial (Experimental)".

In Device Manager portable device shows as Teensy USB Serial Com port is accessible.

Note: if you declare multiple sd devices (as with mtp-test.ino) : sdx[0] MUST exits. If you are using jumper cables to connect micro sd boards, the spi speed (33 MHz) may be too high. reduce to say 15 MHz.

Fluxanode

comment created time in a day

push eventWMXZ-EU/MTP_t4

WMXZ-EU

commit sha 3b9623ce1c61e96d81322963001f6b61be446254

Update README.md

view details

push time in a day

push eventWMXZ-EU/MTP_t4

WMXZ-EU

commit sha 51a0ac35fdd7ed4471b54b02cee9281ff6855e4d

Added T3.5 to Makefile

view details

push time in a day

issue commentPaulStoffregen/cores

Wire library and Serail1 conflict on Teensy 4.0

Work is happening right now on better fault handling and crash reporting. So if you wait a while, we may have 1.54-beta11 with that work included.

deadeert

comment created time in a day

issue commentPaulStoffregen/cores

Wire library and Serail1 conflict on Teensy 4.0

no worries, whenever is fine

deadeert

comment created time in a day

issue commentPaulStoffregen/cores

Wire library and Serail1 conflict on Teensy 4.0

Expect some delays because I’m currently out of the office, but will give a try most probably begin of July.

deadeert

comment created time in a day

issue commentPaulStoffregen/cores

Wire library and Serail1 conflict on Teensy 4.0

Hey, Sorry for the delay. will give a try as soon as I can. thanks for the support.

deadeert

comment created time in a day

PR opened PaulStoffregen/cores

Added Sysclock setting to Crash Report

Good Morning Paul Made 1 slight addition to the crash report. I added printing the System clock to report. Only affects crashreport.cpp.

Unless you want to crash the panic temp from shut down to cool down. I can't see me making any other changes.

Let us know when you want to freeze changes to crash reporting.

Thanks Mike

+3 -3

0 comment

1 changed file

pr created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

Tim - see my response in https://forum.pjrc.com/threads/66403-Re-enable-bootloader-interrupts-after-a-hard-fault-Teensy-4-1?p=281920&viewfull=1#post281920

mjs513

comment created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

Okay - saw both githubs same 4 hrs old.

It is against first plan to restart - shutdown seems safe path. In your test case of a heating lamp dropping speed wouldn't help - in the real world it might be a fan or airflow failure causing over temp.

Only issue is that the crash data won't survive is power shutdown happens for system restart.

But an ill behaving Teensy in any oddly controlling of critical stuff could wake up and half baked and do bad stuff without supervision.

Also not sure what the Teensy state of I/O is in that 8 second time period? No interrupts or programmatic response can happen - what is the state of the outputs? Are they maintained as last set? Assuming a proper design would fail safe if the Teensy went off/poof ... what is it

Would be nice to commandeer 11 DWORDS of EEPROM for more permanent recall.

mjs513

comment created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

Tim: the shutdown on panic alarm. Yes it us. For testing I made set him temp to 50 and panic temp to 55 and ran over clicked at >800

mjs513

comment created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

Mike: is this code in the current PJRC github as last merged?

mjs513

comment created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

@PaulStoffregen and @Defragster Between sleep cycles and doing this response - I must be crazy. In response

Looks like we still need checking to only start the 8 seconds when temperature is safe.

Right now on panic alarm there is no reboot. The T4.1 shuts down on panic alarm with the following messages:

Reboot was caused by temperature sensor Panic Temp Exceeded Shutting Down Can be caused by Overclocking w/o Heatsink or other unknown reason

If you still want it to restart as opposed to shutdown let me know. I did mention this up on the thread as well. Tim seemed to agree:

Shutdown seems right.

As I said I am leery of continuing to reboot when the cause for the panic temp is unknown. Before the merge tempmon would shutdown the T4 if the panic temp was reached. Agree more than likely its due to overclocking but ....

mjs513

comment created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

The only thing I'm wondering is startup.c might have is in https://forum.pjrc.com/threads/66403-Re-enable-bootloader-interrupts-after-a-hard-fault-Teensy-4-1?p=281851&viewfull=1#post281851

Though of course without the call to CrashReport - then there would be 'fast' repeated reboot. Unless there was a 'weak' call the user could add to sketch to replace the default wait for reaction of their choosing.

That "weak void userCrashReport() { // on prior Crash wait 8 secs }" then enter setup() Sketch "void userCrashReport()" - could wait for Serial - or other - and then stream the output to a place of their choosing - that might solve KurtE's issue where it could go to elsewhere. Not a simple as "if ( CrashReport ) {" - but that would still work, and pasting a template copy of userCrashReport() could give more control?

mjs513

comment created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

Figured not ... doing a flush() that waits forever would be bad.

perhaps auto clear is weak - better to see it twice and then have it clear()'d, than to not get to see it at all if the user codes it wrong - they still can if they do a clear() with a ready stream. Given how easy it is to call Serial.print(CrashReport); it wasn't much harder to overtly call .clear() when the user so chooses confirming the Report was seen ... as the user sees fit to code it.

mjs513

comment created time in 2 days

pull request commentPaulStoffregen/cores

Shutdown on Panic Alarm after CrashRPT printed.

No, there is no API to query buffer status. But the API does have a flush() function which waits (or is supposed to wait) until all data is actually transmitted.

mjs513

comment created time in 2 days