Problems with CMP and PITimers

[MikeA]

Hi,

I have just stared working with the teensy 3.5 and I am having a frustrating time with the comparators and now the PITimers. Whenever I access (even just read a register), the serial interface stops working. I am successfully initiating and calling the ADC's although no using interrupts.
void pit0_isr(){
Serial.println("pit0") ;
pit0_val = PIT_CVAL0 ;
Serial.println(pit0_val) ;
// PIT_TFLG0 |= B1 ; //clears int flag
}

I call the Isr in the main loop. I have set up nothing on the. PIT, but I assume reading would have no effect but return a random number. However as you can see the PIT current value is never printed. Something similar is happening with the Comparators, the programme never gets passed any read or write to their registers.

Start setup
interrupts enabled
calibration successful
pit setup
time = 4
pit0

I confess to being completely lost on why it's behaving this way or how to progress to solve the problem. My only thought is there might be some exception taking place, but I have no idea how to explore what is actually happening. I would appreciate some help please.

Mike

 

[Theremingenieur]

All read or write accesses to h/w registers can fail on the Teensy if the corresponding peripheral has not been previously activated in the system integration module (SIM). People are often not aware of this need because a part of the Teensy peripheral blocks is already activated by the Teensyduino core during the boot process. Others are only activated when corresponding objects are initialized, i.e. the IntervalTimer object will activate the PITs. If you need to access a peripheral without using an existing object, your code has to set the corresponding flag in the corresponding SIM register, and sometimes also to activate the peripheral’s clock before you can read or write its registers.

But I’m for sure not telling you something new since all that is documented in the reference manual.

Activation of the PIT in setup() could be done like this (similar to IntervalTimer.cpp) :

SIM_SCGC6 |= SIM_SCGC6_PIT; // enable PIT
__asm__ volatile("nop"); // give it one CPU cycle to come up
PIT_MCR = 1; // configure the PIT's module control register BEFORE any other action is taken

If you just started writing Teensy code, it might be a good idea to have a look onto the Teensyduino core files which do similar things to what you want to achieve in an approved and well tested way.

 

[MikeA]

Hi,

Thanks for that. I am aware of the SIM module but had not read it in detail. Given the manual is nearly 2000 pages long it takes a lot of studying and I had been concentrating on working out how the peripherals work and how I can use them to get my application going. I had not appreciated that I had to activate the peripheral. I will now read in more detail the SIM module chapter and try your suggestion.

Thanks again.

Mike

 

[PaulStoffregen]

the manual is nearly 2000 pages long it takes a lot of studying and I had been concentrating on working out how the peripherals work

This is why we have features like IntervalTimer, so you can use these easily without having to read the low-level hardware manual.

https://www.pjrc.com/teensy/td_timing_IntervalTimer.html


If you're used to old 8 bit chips, where everything in the chip is running right out of reset, these newer 32 bit parts take some adjustment & learning. Pretty much all newer chips are designed to most of the peripherals default to a low power shutdown state. This is really good if you want to make a low power project. But it does mean that pretty much anything needs a step to turn it on before you can use any of its registers. This isn't unique to Teensy 3.x. Nearly all newer 32 bit chips are designed this way.

The other thing you might expect from very old chips is random results when something is turned off or not configured. But 32 bit chips have more complex buses where you get an explicit error rather than just wrong/random data. The error causes a fault handler (like an interrupt) to run, and the default one does nothing other than flush any unsent data and keep the USB auto-reboot working. So your program stops running, rather than getting wrong data. Again, kinda shocking if you're used to old 8 bit chips. On the other hand, it's a pretty good feature that makes sure you know there's a problem, rather than getting random data that you may never know wasn't right.

 

[gfvalvo]

I second the recommendation of first examining the Teensyduino core files, even if they don’t do exactly what you want. Awhile ago I needed to use several PITs for a POV project. I needed different features than provided by the IntervalTimer library. But, by studying how that code initialized and used the PIT registers (along with reading the appropriate chapters in the manual several times), it was a straight forward process to figure out how to set things up for my application.

 

[MikeA]

Hi,

thanks for all the help. I have been studying the core files and I think I am getting the hang of using this chip. Also having to learn about the intricacies of C++. I gave up electronics engineering when my company switched to C (about 25 years ago) as I needed to concentrate more on the management of the business. Now having retired I can come back to something I enjoy doing.

My business made In circuit emulators for mainly Motorola and Hitachi microprocessors and micro controllers (HC11's, 68000's and their like). We failed to keep Up to date when the speeds and complexity started to go though the roof. These newer processors just blow me away.

I think you guys do an absolutely fantastic job of supporting hobbyists and professional engineers and all for very little money as the price of your modules are like the name, teensy compared to the functionality of these chips. Thanks again.

Mike