Search results

We have an important update to our TCD1304 project. After some extensive study using the FlexPWM for precisely controlled timing, we were able to arrive at 0.19% INL. This involves idling the CNVST signal to the ADC as a kind of virtual buffer for the reference voltage system and the way it...

Yes of course and that makes directly connecting the tcd1304 a much worse proposition. You get maybe 7-8 useful bits and then there is the non-linearity. The other scheme that runs a close second is the emitter follower with the single stage opamp and a large input resistor to wash out the...

A further thought. See the above, #27, the critique about driving the analog input from the tc1304 directly. Re the other suggestion in #26 - to use the averaging in the ADC setup. Recall that you need at least 200KSPS to read the TCD1304. I am not so sure you can do that averaging 8...

sqr Sqrt(N) sqrt(8) = 2.8 So at best you get a 2.8 fold increase in S/N. That does not get you to 12 bits from 10. But where does 10 bits come from? is that because you are feeding the TCD1304 directly into the analog input? (Doing that potentially creates other issues, like...

I just noticed my earlier post #21, and there are a coupled of things that probably need to some correction or clarification. The first is that two important issues in working with the TCD1304 and any CCD sensor, are the following: 1) "undershoot" (in the ADC or analog input) - this...

A well supported WIFI with low overhead would be very useful. Another useful device would be GPS including precision timing. It is enabling for some applications in geology and oceanography.

Hopefully, it will always be an NXP chip for a while, and it will always have the 480MHz USB (or faster). The peripherals on the renesas are so far less appealing.

Yes, it seems I keep missing the fine print. But I am not clear about how it would work. I think that is why I miss the fine print. Can we start the Quad Timer from the FlexPWM? And vice versa, can we start the FlexPWM from the Quad Timer?

It seems like the linear CCD would need a combination of the FlexPWM and Quad Time and I am not sure that it is possible. In the following I connect ΦΜ, ICG and SH, to pins 4,5,6, all on FlexPWM2 submodules 0-2, all of that seems straightforward. For the ADC, the CNVST on pin 10 and the SPI...

Well.. the reason I asked, is that NXP's support engineer told me it can't be done, i.e. starting the SPI from the flexpwm without an ISR. We talked about this quite a bit and eventually I filed a support ticket to ask how to do it. That took a little while too, but finally the above answer...

Wow, that would be fantastic. It is a really generic problem, just about every ADC and DAC that we might use needs this. I asked here and NXP and was told it is not possible. Can you please show an example using the flexpwm and SPI without an ISR? The simplest example would be...

Could you please show an example how to cascade two FlexPWM without using an ISR? That would be sooo helpful. Thank you

Hi everybody, apologies for the delay in responding. We were out of town and occupied. Per the request for a benchmarks for timing, see: Teensy 4.0/UNO R4 timing (github) This is code that I threw together to check timing. It outputs average and maximum timings using the cycle counter, but...

Simple example, let's say we run the convert signal for an ADC from a FlexPWM submodule. How do you start the SPI 30 nsec after the trailing edge of each CNVST pulse? You can use an interrupt and setup the relative timing with other channel of the submodule that is not connected to a pin.

Why am I doing with this Teensy, you might ask. The project is to make open designs for high end instrumentation available and affordable. The collaborators in the designs are late career instrumentation physicists. We have had downloads by underfunded scientists on five continents. Some...

Sure, easy, The timing for the gates for a CCD, the timing for an ADC, similarly a time to digital converter for photon tagging, and simply counting pulses from a PMT. The problem for the first two is partially resolved with the flexpw, it still needs interrupts in both cases and in the first...

I previously ran timing measurements for basic operations, set a pin, read and set, interrupt latency, etc. I tried it using a scope and then using the cycle counter. The two methods agree. It looks like in some instances the Teensy might be sporadically loosing about 50 instruction cycles...

I am happy it is not in that driver, and embarassed or course, but also a little dissapointed tha the culprit is still not found

Probably yes, oops, sorry. We still have the mystery of what is effecting interrupt latencies. And the code that does use that instruction still ought to be fixed. If it is ever used, it will be disruptive.

usb_serial.c, usb_serial.h ? That one looks okay actually.

Okay great, it want clear. So where is it?

Yes, atomic read and disable for an IRQ. Perfect. However, that too is not something that should be looped over. The solution for simple producer-consumer scenarios is still a flag, and only synchronize the flag.

Paul has been pretty amazing about this. This one turns out to be pretty simple, I might take a look at it, or maybe Paul will get to it first. I have a very busy few days ahead of me. The other thing, it is the internals of the interrupt architecture on the ARM, as regards to disabling a...

@PaulStoffregen P/S I am assuming/guessing that that code is what is invoked for Serial.available().

Good morning Paul, You are right. However, the problem is the same, but the synchronization technique needs to be a little different. Perhaps it is not needed, but to recap the problem, it is the following and in specfically when this is called from loop, as is typical...

P/S it occurs to me that if done properly, a lot of the cautions about what you can do in another isr, go away. It really is worthwhile to fix this.

Super cool and really goog point, though what it might be used for in out case does not immediately come to mind. In our case, an ISR servicing the incoming serial data and loop() checking or retrieving it, we probably want to stay with the usual construct, increment the contents of one memory...

I am still flabbergasted by that remark, i.e. that because Arduino is amateur, therefore Teensy should be a disfunctional hack and amateur, too. Thank G-d for our Cathredal and the team here that attends and contributes. A) That some of the rest of the arduino world might be amateur, is...

Hi Paul, The exclusive load and store are used to protect a single fixed address in normal memory, which is then used to protect whatever you want to protect. Think of it as functioning like a semaphore or mutex. In fact that is what it is. Except that instead of threads, we are only...

This got tacked onto another thread, I forgot how. Here is a summary of what is going on, or at least at seems to me: The problem is that interrupt latencies are unreliable on the platform. One very likely culprit is repeatedly globally disabling and enabling interrupts to synchronize access...

Okay, I am signing off for the night. This was super productive I think. We now have a clue.

The trick is to design it so as to minimize the synchronizations and what is synchronized. But many of the tricks are not new. Generally, when something is incremented by only one thread, it might not need to be synchronized.

yes, we crossed messages. I found it and the hander. It looks like the patch is pretty doable, just takes a little care and attention to detail. It is tricky though and quite easy to mess it up. We will have to think about it carefully. I notice we have another experienced realtime...

When we design a real time system, what interrupts may occur and when is part of the design. Having something that gratuitously and unnecessarily loops over disabling interrupts, will in many cases make it unnecessarily impossible to implement a given real time system on a given platform...

So.... in HardwareSerial.cpp, it seems the RIE is set and interrupts are connected, and perhaps "irq_handler()" is the code at https://github.com/PaulStoffregen/cores/blob/10025393e83ca9f4dc5646643a41cb2f32022ae4/teensy4/HardwareSerial.cpp#L620 So, all we need to is use the STREX/LDREX...

Aha! Yes indeed that is it. A quick grep indicates that it is not referenced in the code. Does the driver use DMA instead? It is a little convoluted to find it and I think the text doesnt mention it. CTRL[RIE] (page 2928) enables interrrupts from STAT[RDRF] (register full, page 2924...

The code tree there is a file cores/teesy4/util/atomic.h. I think this is not used in the T4 code, but it is an interesting bit of history. It seems to be a carry over from the AVR which on quick perusal seems to lack exclusive store and load instructions. It is a kluge using instructions...

I think, not really. But I found something interesting in the processor reference manual in "49.6.1.7 LPUART Status Register (STAT)", the field labeled RXEDGIF. Am I reading that correctly? is that an interrupt on the start of recieving a character?

Perfect, thank you.

That time delay is the problem. It also accounts for the jitter in interrupt latency that we discussed in another thread. And that is s severe limitation. You simply can't do hard real-time like that. We really aught to hunt all of these down, or all of those that might show up routinely...

Thank you

No, it is not a proof, sadly. I have seen worse from vendors, in code and silicon and datasheets too. But back to the device at hand. So far the only interrupts that I notice in the documentation are for byte compares, and maybe i saw something for the fifo, normally a receive fifo would...

Isn't there already a read until or read line ?

That would be a super nice feature for the serial port.

Got it! Eureka! There is a character match interrupt. Perfect. We interrupt on cr or lf. Here is an article https://community.nxp.com/t5/i-MX-RT-Crossover-MCUs/LPUART-eDMA-Efficient-asynch-reception-of-bursty-data-with-DMA/m-p/1642814

@joepasquariello It is not immediately clear from the reference manual that there is a receive interrupt. But there seem to be example of code using it for our MCU, in the NXP community. If so, that would be pretty easy; receive character, increment flag. Never a lost character except...

Okay, checking the manual. I doubt it there is no way at all, but let's see.

Well, the we respectfully disagree. I have already done exactly this umpteen times in other platforms. But maybe you are saying there is something in the existing code that presents and obstacle? It is not obvious. The only issue that comes to mind if the isr that services the port does...

That is obviously not true as a general statement. It depends on what. Paul does it in delay.c, and he has TODO notes saying exactly that in EventResponder.c And that is part of why the atomic operations exist. Others would do it for the case we have been discussing. I probably...

@joepasquariello Are you assuming that I am using one of the thread environments mentioned above? I am not, yet. Well sometimes you do need to use a delay, when the overhead for a timer and context switch is longer than the delay or you want to hold the context.