joepasquariello's latest activity

Something else to keep in mind is when you change F_CPU or call set_arm_clock(), you change both F_CPU_ACTUAL and F_BUS_ACTUAL, and the relationship between the two is not always the same. For example, if you call set_arm_clock(600), you get...

The link below will take you to a post where Paul discusses F_CPU_ACTUAL versus F_CPU. It says you should use F_CPU_ACTUAL, which is a uint32_t variable, not a constant. It doesn't say anything about...

Can you post your code? It's really not possible to trouble-shoot with so little information.

Based on this description, I would say you should use FreqMeasureMulti, as opposed to Encoder or QuadEncoder. If you configure FreqMeasureMulti on both of the encoder output pins (A and B), you can record the time of each rising and falling edge...

Until now you haven't said what you are trying to accomplish. I mentioned that you can calculate speed because that is often what one does with a relative encoder. What are you doing with the encoder, and how fast is it going to turn (revs/sec or...

Could you add some state logic to your application to "shut down" before update? Maybe I misunderstand, but it sounds like you are doing build/update while your system is operating.

Use the QuadEncoder library on T4.x for this type of high-PPR encoder. No point in having hundreds or thousands of interrupts per second when they are easily avoided.

Use QuadEncoder, which does the quadrature counting entirely in hardware, with no interrupts. If you want to know the speed, use an IntervalTimer. In the IntervalTimer handler, read the encoder count value and subtract the value from the previous...

Also TeensyTimerTool.

Have you searched the forum? Look for TyTools and/or TyCommander. I think that's generally what folks use who want to manage multiple Teensy.

You don't specify which Teensy, but these days I assume 4.x, and therefore I would continue to use the RTC, for a couple of reasons. One is that the RTC built into T4.x has much higher backup current requirements than an external RTC. The second...

Just a note, I ran the SdFat library SdFormatter example sketch on my 32GB Sandisk Extreme, and I noticed that after the erase, it says "All data set to 0x00".

If you are using EEPROM, you must set the value of FLASH_RESERVE_HI in FlashTxx.h to 256KB (64 sectors) as shown below. This tells FlasherX that the buffer must be below EEPROM. #elif defined(__IMXRT1062__) && defined(ARDUINO_TEENSY41) #define...

Yes, I think it is possible. Your programs have access to the program flash, which begins at address 0x6000'0000. If you look in cores\Teensy4\eeprom.c, you will find a function to erase a sector. If you erase the sector at the base address and...

Unlikely the flash would be going bad. It's good for something like 100,000 cycles. You should probably try just printing to the serial monitor instead of writing to your display, just to simplify things.

I'll do some testing one of these days and let you know if I can duplicate your results. If you don't mind sharing your sketch, that would probably be the best way for me to try to do that. I don't know of any way to "erase" a file, certainly...

That makes sense. The number of bytes in the RingBuf is going to spike each time the SD reports "busy". I never recorded the intervals at which that occurs. It's interesting that it's periodic at 4MB, with a larger spike around 32MB. Someone who...

The RingBuf class never calls flush(). It's important to ALWAYS and ONLY write in chunks of 512. Using rb.sync() any time except at the end of your data logging is not consistent with that requirement. Please just try it.

Here is RingBuf::sync(). As you can see, it's very simple. /** * Write all data in the RingBuf to the underlying file. * \return true for success. */ bool sync() { size_t n = bytesUsed(); return writeOut(n) == n; } It's...

You're talking about file.sync(). The OP is talking about rb.sync(), which is part of SdFat's RingBuf class. It's not a file system sync().

Yes, the core PWM functions yield edge-aligned PWM.

rb.sync() simply calls file.write() with however many bytes are in the RingBuf. The point of having the RingBuf is to allow your loop() to write in chunks of 512 bytes, and avoid writing when the SD is busy. If you always write in 512 byte...

What does that mean relative to PWM? CS low after PWM high?

A related article: The Lost Art of Structure Packing

If the local variables are in registers, RAM access would be avoided within the for loop, so yes, it would be faster this way.

You can control the amplitude, either keep it the same or make it whatever you want. Consider the identities below from the trusty Wikipedia page. sin ⁡ ( α ± β ) = sin ⁡ α cos ⁡ β ± cos ⁡ α sin ⁡ β cos ⁡ ( α ± β ) = cos ⁡ α cos ⁡ β ∓...

We use MCP4922, but check specs

The simple and clever way that I have seen to generate a sinusoidal signal with a variable phase delay is as follows: signal A --> band-pass X Hz --> signal B --> low-pass X Hz --> signal C this results in B being in phase with A, and C being 90...

My "cheat sheet" for identifying the FlexPWM signals is FreqMeasureMultiIMXRT.cpp. Pin 33 is FlexPWM 2.0.B I can't tell from your code what you want the relationship of CS to be to the PWM edges, but I think you should be able to do what you're...

For a while now, I have not liked having #ifdef tables defined in a different places in the cores or libraries to handle the differences in Arduino pins that are on each of the different boards. It made it more complicated when PJRC releases a...