joepasquariello's latest activity

HWORD half word, WORD, DWORD double word, which all depends on what the word size is on the particular architecture. In C and C++ now you can use uint8_t, int16_t, int32_t and so forth from stdint header file. Bytes on a DEC system 10 were 6...

Not sure whether it was your program or @defragster's, but it had timer period of 36 us, which is consistent with 400 rpm, not 200, and you get 19.2 seconds with 4 x DWORD. At 200 rpm you would get 38.4 seconds.

This program does what I think was intended. I used a typedef because I think it makes the syntax clearer. EXTMEM locates data in PSRAM, which is assumed to be 8MB. The number of samples is computed from size of PSRAM and size of struct, so you...

400 rpm (400/60)*4096 -> 27306.67 Hz 8 bytes -> 38.4 s 16 bytes-> 19.2 s 32 bytes -> 9.6 s 64 bytes -> 4.8 s How much time do you think you need? Cut down your data so you can capture as much time as you need.

Could each record be as simple as position (encoder edge count) and interrupt execution time for each edge? That would be 8 bytes and you would have 1024*1024 samples. At 400 rpm that make N = 38.4 seconds, and you would be able to confirm that...

You have 8 MB of storage. It's up to you to decide (a) how often you write, and (b) how much you write on each interrupt. Those determine your total logging time, which you can call N seconds. You can either define a start condition and log for N...

Start the logging whenever, at PSRAM address 0, and when you get to the end of PSRAM, jump back to the beginning and keep going. Whenever you STOP logging, you will have the N most recent seconds of data. Would that contain all the data you want...

I’m not an audio user, so I can’t answer definitively, but there’s an audio tutorial on the PHRC site that I suspect will answer your question. Also just searching the forum and YouTube will turn up a lot of resources.

Good points. No need to worry about one-time dynamic allocation of objects. Just avoid repeated allocation and deallocation.

You can use Arduino and C++ and avoid any dynamic memory allocation. How easy or hard that is will depend on what you’re trying to do, and what libraries you might want to use. Can’t say more unless you share what you’re trying to do. It would...

Sounds like the frequency is probably not very high, nor is it about high accuracy. Still you can use FreqMeasureMulti, which is nice because of the queued data, but if you already have it working with a GPIO interrupt, maybe you don't care.

You could use the FreqMeasureMulti library, which uses the input capture capabilities of FlexPWM and QuadTimer to measure the time between specified edges of an input signal. There would still be an interrupt associated with the measurement, but...

Yes, you're right. Here's the table from QuadEncoder.cpp, and pin 6 is not an option, but you could use 3, 4, 8, 30, 31, 33. Are you saying you can't simply jumper pin 5 to any of those pins, say be soldering on a blue wire? #if defined(...

A RingBuf can be located in PSRAM via the EXTMEM keyword, just like any other static variable, but since @clinker8 intends to log data while cutting and extract/print later, he doesn't need RingBuf at all. He can just write directly to PSRAM...

Yes, but you would be using pins 6,7 and not 5,6. The idea is to avoid using pin 5.

The Heterodyne code is using input 17 of XBAR1 for the signal coming into pin 0, and QuadEncoder is also using XBAR input 17 for the phase A encoder signal coming into pin 5. Since your code sets up QuadEncoder before it sets up the Heterodyne...

@AndyA provides a good answer to your question, and I can add a little more. FlasherX can be used in many different ways. There's no way I could provide a "simple working example" for every possible usage. The core functionality of FlasherX is...

For "outlines", read "shows exactly". For "most helpful", read "vital". I've tried a very simple sketch based on the vague hints in post#1, using Arduino 1.8.19 and Teensyduino 1.60b5, and completely failed to observe any problem. I'm quite...

This is a good example of why it's important to provide a complete program showing the issue. I think it would have been easy to show that memcpy() was not the issue.

Before you read from the serial port, check the number of bytes in the RX buffer using available(). If available() returns a value equal to the size of the buffer, then it's likely the buffer has overflowed. Assuming you have some unused RAM...