Hello everyone,
Thanks in advance for any help, I'm a student which needs to use a QuadDec with 32 bit size counter, so I created a long int variable to storage it's value, because I need to send it through the UART interface as string to capture the quadrature information, the thing here is that even though I do select the counter with 32 bits, the data I'm receiving can't go up to -32 768 and +32 768 just as it was a 16 bits counter.
I read in the Component Data Sheet this:
"The 32-bit counter implements the lower 16 bits in the hardware counter and the upper 16 bits in software to reduce hardware resource use. For this target, an additional ISR is used. To work properly with the 32-bit counter, interrupts must be enabled. You can add ISR code to source files as needed; see the Interrupt Component datasheet for more details."
I'm not really sure to fully get what it means but as far as I can understand that it seems that it really never creates a 32 bit counter.
How can I fix this?
Thanks again.
Solved! Go to Solution.
That statement means exactly what it says.
In PSoC most of the functionality is not a fixed component, but rather implemented in UDBs. There a counten needs a certain amount of resources. To save these, the QD implemts only parts of the 32bit counter in hardware, and the rest in software. For that it uses an interrupt (triggered when the lower 16 bit overflow). To work properly, you need to enabled interrupts globally.
This internal interrupt does not prevent you from using interrupts for your own purposes. Just connect an ISR component to the interrupt output of the QD.
Welcome in the forum!
Can you please post your project here, so that we all can have a look at all of your settings? To do so, use
Creator->File->Create Workspace Bundle (minimal)
and attach the resulting file.
Bob
The 32 bit solution is a 16 bit HW counter coupled with its overflow/underflow
into a 16 bit SW counter, so thats the reason the interrupts are required.
Whats not clear to me is this API -
Does it mean the GetCounter( ) API only return the lower 16 bits, even though
API shows it as 32 bits when configed as 32 bits, or is the above API just a
convienence to strip off the upper 16 bits if so desired.
Regards, Dana.
That statement means exactly what it says.
In PSoC most of the functionality is not a fixed component, but rather implemented in UDBs. There a counten needs a certain amount of resources. To save these, the QD implemts only parts of the 32bit counter in hardware, and the rest in software. For that it uses an interrupt (triggered when the lower 16 bit overflow). To work properly, you need to enabled interrupts globally.
This internal interrupt does not prevent you from using interrupts for your own purposes. Just connect an ISR component to the interrupt output of the QD.
GetCounter() returns either an int8 / int16 or int32, so you get the full counter. The _count32softPart is, as described, the part of the 32bit counter thats handled in software. Its a global variable, but its not intended to be used externally (though can can)
Thanks it seems like it worked what you all say! š Thank you to everyone!!
hli, what seems odd to me is its clear interrupts have to be enabled,
to get 32 bit to work, per datasheet, but then what is the purpose of
attaching the ISR component, what does one need to place in the ISR
code ?
In other words component has to have interrupts enabled, but does that
translate also to adding an ISR component to the interrupt output to get
basic functionality ?
And if overflow and underflow triggering two interrupts, the "internal" one
needed for 32 bit operation, does that conflict if a user implements the
interrupts for the same OF, UF ?
Maybe I am the only one confused here. Wouldn't be the first time.
Regards, Dana.
Add an ISR component with no code in it, and it works, I am going nuts!
I was able to confirm hli's assertion, ReadCounter( ) for a 32 bit does in fact
return the SW part and the HW part for a 32 bit counter. From .lst file
Regards, Dana.
@dana the interrupt output on the QD component is for the external inerrupts (e.g. counter overflow or illegal state transition). Attaching an ISR here should not be needed or normal function (if it is thats a bug IMHO).
hli, I concur, but thats what the poster implied he did to get it to work.
I am still going nuts š
Regards, Dana.
From what the OP wrote I cannot read that an additional ISR is used. The statement was basically "worked as you described"...
We read this differently, only the poster can clear this up.
The interrupt output supports -
Regards, Dana.
This situation is very wierd because it did work with the interruption.