jmarsh's latest activity

If you only need USB for programming the Teensy, consider using the FlasherX code to be able to upload a new sketch over ethernet instead.

With a 7 port hub you would need at least two hub objects.

If you've changed the VID+PID then the program won't recognize the device. If you've reused the VID+PID but have changed the interface numbers, endpoint addresses etc. then you've broken what the program expects a device with that VID+PID to...

seremu is handled by teensy_monitor, if you've changed the interface around it probably doesn't know how to read it any more.

If you only need to preserve the date/time it might be better to use an external RTC, they'll last a lot longer.

Open collector means it never drives the outputs high, only low. When the encoder wants to output a "high" it just leaves the output open, disconnected from anything - so what you're measuring with the meter at that time is just a floating line...

That looks like the D1 and D2 pins aren't connected correctly.

There's a PR for that.

I'm not completely sure if the key is inaccessible, but (similar to what Paul said) even if it's hidden they could still run their own code on the device to use it as an oracle to decrypt your program - because the key is there, the device can...

That's a different string of "byte received" characters than what you posted in the first post, so not surprising nobody was able to recognize the issue.

If it's not locked then it defeats the purpose of using encryption, since they will be able to decrypt your code and redistribute it.

These lines look a bit strange. Are the encoder outputs open-drain and the microcontroller's inputs intended to have active pullups? If so the pinMode calls should be using INPUT_PULLUP, and you can safely connect them without the voltage divider...

A tiny receiver like that shouldn't need much power to run, it's probably just pulling too much when it initially starts up (would probably need a scope to monitor the level when it gets plugged in). Maybe putting a capacitor between the USB Host...

But you just mentioned the solution: delete one of the libraries so that ILI9341_t3_font_t only gets defined in one place, instead of being defined separately by both libraries.

From that debug log I would guess the device is pulling too much power when it initially connects, causing the disconnect. Try connecting it via a powered USB hub.

Don't put the velocity and note definitions inside the setup() function.

You MUST have a setup() function. It will not work without one.

Yes we do: https://github.com/PaulStoffregen/cores/blob/master/teensy4/Blink.cc The linker typically discards it because the sketch provides setup() and loop() symbols before the core library gets pulled in.

You need the setup() function in the same file as loop(). Why did you remove it? The copy of the Blink program in the core usually gets ignored because it contains only a setup() and loop() function, which both get overridden by your program...

You seem to have a bunch of library conflicts there, in some cases the compiler is using the teensy libraries and other cases it isn't. Why do you have other copies of libraries that are included in the Teensy installation?

Why would you want to use this chip? It's slower and has less capacity than the 128mb flash chips that are usually used with a Teensy 4.1.

For the 1062 there seems to be a SNVS_HPCR register with a bit called HPCALB_EN and a 5-bit signed field called HPCALB_VAL. You have to clear the HPCALB_EN bit, set HPCALB_VAL (which ranges from -16 to 15 ticks to add per 32768 ticks) and then...

Back when Paul asked to be reminded of bugs for beta1 I forget about this one, but ran into it again after a clean install. The way it manifests for me is that when I query the free space on a FAT32 volume that uses 64KB clusters the result is...

It's AI generated spam.

I'm not exactly sure about this, but I think when the compiler attempts to find a matching function name it will check all functions in the derived class before checking functions of a base class. Since PrintFile<FsBaseFile> is derived from...

No. That is a misconception. yield() is a common OS-style API function that is free to be called by any code, and anything connected to an EventResponder should be treated with the same respect as an ISR - in fact this would probably be more...

Well you haven't really explained or provided an example of what the problem is - all we know is that the SD library calling yield() causes your EventResponder to be executed which then attempts to use the SD library. But how is the SD library...

I mean it's the responsibility of whoever is writing the EventResponders that are getting hooked in. Library authors shouldn't need to document whether they call yield() or not (they may not even be aware of it if it happens in some platform...

I don't think Teensyduino requires any changes at all because as it is, it works as designed. The problem in this case seems to lie with hooking extra things into yield via EventResponder without appropriate safety checks. If you're going to do...

There are places that will supply the Teensy 4.1 with attached IO and ethernet headers, e.g. protosupplies. So you'd be paying ~$3 more per unit to save the trouble of adding the ethernet header yourself.

Try switching the parameters for transferSize() and transferCount(). Instead of transferring 4 bytes at a time for 1 loop, you want to transfer 1 byte at a time (like the comment in the code says!) for 4 loops. (Really you would want to transfer...

These lines immediately jump out at me as being suspicious. The ! operator performs a logical NOT operation that returns 0 or 1. I suspect what you intended to use here is the ~ bitwise NOT operator. I don't have the IMXRT datasheet available at...

Since EventResponder is a c++ class, you can always just derive from it and override triggerEvent() with the behaviour you want.

This is exactly the reason for what I proposed above: if your yield() was able to call Teensyduino's yield() (either directly or via a dedicated idle thread), EventResponder would handle calling Ethernet.loop() as intended.

It uses linker script magic to get pointers to the sections with a NULL pointer marking the end of each. I left the rejected PR open just in case the code would be useful to someone: https://github.com/PaulStoffregen/cores/pull/734/files

They are not bi-directional because there are separate signals for each device - RTS from one device connects to CTS on the other. When a device is ready to receive it asserts RTS which the other device receives as its CTS signal.

Yes, this is similar to the problem of more than one entity wanting to override the startup hook functions. Which I came up with a solution for: create a const pointer to the function and ensure the backing storage for that pointer is located in...

EventResponder doesn't override yield(), the default (weak) yield checks a flag and calls EventResponder::runFromYield() if it is set. What would perhaps be nicer, is having the default yield() called something else (i.e. default_yield() ) and...

Most non-BT wireless keyboards act just like a regular HID keyboard, the PC doesn't even know the difference. So they should work fine with the USBHost_t36 library.

Oh, also all the "fast' pin interrupts share one hardware interrupt so one long pin ISR will block all of the other pins. You have to switch the pins over to "slow" mode if you want to give them individual priorities.

Sure, check the LittleFS_Program examples.

No, but I use git branches for my own modifications and just switch back to master whenever I want to use unmodified cores.

Interrupts/exceptions have individual priority levels. When an exception is in progress it blocks all other exceptions of lower or equal priority. Whether a long ISR is a problem or not depends on what priority it has versus any other ISR that...

What I do is have the git repository located elsewhere on the PC and replace the cores directory in the arduino package with a symlink that points to the git repo (using mklink from the windows command line). That way you can change whatever you...

Sounds like the SD file reading is being done in an interrupt handler.

You're supposed to use threads.delay() instead of the ordinary delay() function.

0xEB000426 is not a valid address for code. It looks more like an opcode than a memory address.

A mechanical relay will probably use more power while it's turned on than what a "soft" power-off solution (like a mosfet) would leak while it's turned off.

It's not a sum, it's a bitmask. Each bit position in the value represents a separate button. You can use logical AND operations to easily check the state of individual buttons.

The reason I'm discounting this is because the OTA process should have nothing at all to do with the build tools/copy of Teensyduino installed on the host PC that is doing the sending. If the exact same firmware works when sent from one machine...