Search results

Thanks Paul! I've been a bit lazy in my updates here, but unfortunately there's not a lot to report on the car. The last 2 years at Bonneville have both been washed out and the nature of these events means you really only get a window of few weeks per year to make attempts. If the weather...

This would be very welcome on my project as it would save it needing to be placed in probably 40 places across the code (No there's not 40 different interrupts, but different functions that could be called depending on config/state). Having it automatically placed for all external interrupts...

I’ll have to see what I can do around this. It’s a design that was originally for the 3.5 boards that I’m altering for 4.1, but I probably have a few options for lowering the impedance of these input circuits Thanks everyone for you help, it’s greatly appreciated.

I managed to copy the code out of digital.c in the cores area and customise it to work. Looks very similar to this, but I also added the before/after checks from pinMode() just to be safe. Thanks so much for pointing me in the right direction though!

Still there yep. Didn't seem to make any difference one way or the other.

Also, just to be a pain with the questions, is there any guidance around what is 'too slow' for a rise time? In this setup the full rise from 0 to 3.3v is about 8uS, but probably around 4uS to 2.7v. That is somewhat slow, but I wouldn't have thought it was bad enough to cause a problem.

OK, it mostly fixed it by the looks. I'm still seeing the occasional false interrupt getting triggered, but it's FAR better than what it was.

Wow, that fixed it, thanks! I wouldn't ever have thought to try that as a fix for this type of issue. So the falling interrupt can fire on a rising pulse if it is too slow? Is there any way to enable the hysteresis without the pullup being set? I'm using an external pullup and would prefer to...

This makes it slightly more obvious: void setup() { // initialize digital pin LED_BUILTIN as an output. pinMode(10, OUTPUT); attachInterrupt(20, pinFallingISR, FALLING); } void loop() { } void pinFallingISR() { if(digitalRead(20) == HIGH) { digitalWrite(10, !digitalRead(10))...

Still the same thing with that asm("DSB"); added unfortunately. Doesn't matter which toggle method is used. In my actual sketch the ISR is quite a bit longer than the example, but it's probably still exiting fairly quickly. FWIW I swapped a Teensy 3.5 into the same circuit and with the same...

So, I thought I was going crazy but I think there's an issue with the edge triggering interrupts on Teensy 4.1. If I set a RISING or FALLING interrupt using attachInterrupt then I will occasionally see the ISR getting called on the wrong edge Here is a basic example sketch: void setup() {...

Logging to the SD is only at 30hz with about 110 bytes per entry (Lots of packed bytes), so it’s not too much of a problem in this case. We’ve tried at 100hz and there was also no issue. Using the SDFat library + preallocation + ringbuffer seemed to make for a very nice combination that results...

Hardware is based on the Speeduino ECUs I've done, with these using the same circuit designs for power regulation, RPM inputs, CAN, analog inputs and general purpose inputs/outputs. The fuel outputs are quite different though and there is the addition of a pair of MAX31855 based EGT inputs. The...

Thought I'd give a bit of a heads up for anyone interested. This car will be at Bonneville Speedweek from August 6th and again aiming for a new world record (C'mon 500mph!) in its class (Fastest wheel drive car). Will be running the same hardware as last year, that is a Teensy 3.5 powered FADEC...

Well has been a week of mixed results with this project. Overall the electronics side of things worked pretty well. Some noise related issues that are likely wiring related, but overall the Teensy based turbine controller performed a treat. Unfortunately due to a number of issues on the car it...

Here's the car with things up and running today

As an offshoot of the work I've done with the Speeduino ECU, I've been working the last few months to adapt the project into a FADEC turbine controller rather than piston engine controller. This is for use in a turbine powered streamliner, Turbinator II, that is currently the fastest wheel...

Thank you for this!!

Not sure if this is the best (Or correct) place to request this, but would it be possible to get an update of the FlexCAN_T4 library included? We had an issue with the init routine of this library that was resolved back in July...

There's a pair of diodes on the VBat circuit of the Teensy 3.5 from what I can see (https://www.pjrc.com/teensy/schematic36.png). One is feeding 3v3 onto the controller pin, the other is on the VBat line itself preventing this 3v3 connection back feeding out the pin on the board. I'm assuming...

Unsafe for the VBat input or unsafe for the battery? These ML batteries should be safe to fully discharge is my understanding, with the proviso that they 'only' get around 100 full charge cycles, which is fine for this use case.

Due to some fairly tight physical constraints, I need to use a fairly small battery for my RTC. 20mm, 12mm and even 10mm are all too large and I'm looking at using a 6.8mm ML621 which is a rechargeable 5mah. Rough calculations suggest this should last around 100 days for the RTC, which is fine...

It works with both ShadowDash, MSDroid and RealDash today, so there's a few nice options for doing this sort of thing already :)

Alas, I've been a bit disappointed with it. Very much personal preference, but it's too hard for my liking. Yeah it's a bit ridiculous. The loop counter was 3 and bit full turns through :D

I've got a couple of concerns with the T4 as a long term thing. The first is around timers are there aren't quite as many on the T4 as there are on the T3.5, and that's a big thing on this codebase. With the T4 I've used up all the Quad Timers + the PIT timers, so short of somehow being able to...

I just got all the compatibility work done on the Speeduino firmware to allow support for the Teensy 4.1 and fired it up on a car. It was a 'fun' challenge deciphering the massive datasheet to get all the timers info that was needed, but I got there eventually. It uses all of the quad and PIT...

Not a huge deal at all, but any way of getting CAN on pins 3/4 for compatibility with the CAN0 pins on the T3.5/3.6?

I've got a project that runs 90% of the time from an externally regulated 5v supply attached to VIN. However, the other 10% of the time I need to be able to attach and use the USB, both in cases where that external 5v might be present or might not (ie I need the Teensy to still be able to be...

So with the upfront disclaimer that I might be an idiot, .available() seems to be incrementing now, but it also appears to be returning a value that is twice what it should be. Using the original test sketch I posted, each time I sent a single byte through the serial monitor, the value getting...

Thanks so much Paul. I'm away from my T4 until tomorrow, but I'll give it a crack then and report back

I'm still working through developing the T4.0 code for Speeduino. Even if the comms stuff was working right now, I haven't done all the timers stuff yet so it won't actually run an engine. I'll get there, but not much I can do now until the serial issue is resolved.

Just to confirm back, using a 3v3 USB serial adapter and Serial1 on the Teensy 4.0, everything works perfectly, so this problem is definitely within the USB serial implementation.

After more playing, I've managed to confirm a few more things around this, but not exactly where the main problem is coming from. As best as I can tell, the serial RX interrupt is being disabled after the initial data is received and only gets turned back on after the data has been read back...

A little more playing and I can see that there's definitely an issue here with subsequent serial data being sent. It's not just that Serial.available() isn't being updated, it's that the subsequent data isn't being added to the rx buffer at all. Within usb_serial.c when the first set of bytes...

Assuming this should've been serial.setTimeout(0), it made no difference.

OK, I really hope I'm doing something dumb, but I'm having all sorts of trouble with some of the serial functions under Teensy 4. The issue I'm seeing is that the Serial.available() stops updating after the first call to it, unless there is a read performed. Here's an example sketch: void...

Hey team, I received my Teensy 4 board today with the hopes of getting my Speeduino ECU firmware running for it shortly. I'm experiencing what appear to be hard lockups of it though, seemingly serial (buffer?) related. To reproduce, here is a SUPER simple sketch based on the Arduino Serial...

Totally forgot to report back on this one, but I've got my adapter board all finished off and working. It's not 100% in terms of pin coverage of the Mega, but it uses all of the through hole IO on the Teensy, which is really all I trust for this setup. The board gerbers are viewable at...

So, I've just about got my adapter board finished off. Ended up using a pair of LMV324LIDT quad op amps, basically exactly how Epyon describe, so thanks for the input! Will report back when I've got an engine up and running, providing everything works on the adapter :)

So I thought I'd do a bit of a write up around some of the work I'm doing with the FTM timer in the hopes of potentially making life easier for others wanting to do this in the future. The background is that I'm adapting an existing project (http://speeduino.com) to support Teensy as well as the...

This is the one and only thing that made the difference for me. I have an existing project based on the Mega 2560 that has a hard requirement for at least 3kb of EEPROM. For various reasons I didn't wish to use external EEPROM, so the 3.5/3.6 boards are perfect! Granted it's meant I've had to...

Thanks for the reply, and the diagram! That was certainly the other option I'll look at if needed. Whilst the K64 datasheet does recommend the use of a 0.01 μF cap and talks about being able to change the sample time for higher impedance inputs, it doesn't specify a maximum or even recommended...

I'm about to start porting a project of mine (http://speeduino.com) for the Teensy 3.5 and looking at making an adapter board that will allow the Teensy to plug into existing shield boards designed for the Mega 2560. For the most part this is relatively straightforward, but one area that does...