12F683♦testing (following)

Hello,
First many for thanks for the new build :-)
Quick question that could have already been asked, but when testing interrupt on change (IOC) when GP is in input mode, it seems Simulide detects the HIGH/LOW logic change at vdd/2 (or maybe 2,5v hard coded).

Datasheets for 12F683 would say (p152) TTL INPUT THRESHOLD VIN vs. VDD is around 1.1v < n < 1.3v (depending on t° - we may have a cheap built-in sensor here ;-)

It is also possible I do not interpret correctly the datasheet , but this is anyway what I can see with a real PIC (more around 1.3v at 5v and 20° ).

Can you just confirm how Simulide would model this use case ? (Not at all a real big deal here, nor an emergency )

Yes, digital threshold for all Logic Pins is 2.5 V by default.
And by now there is no way to configure this for MCUs.

The plan is to add a default threshold for all IO Pins in each MCU but later we need some way to configure individual Pins.

Very clear, thanks a lot !

So I eventually found some time to test the different ccp1 compare mode [EDIT with then new 1.0.0-R1348 build] for the 12F683 (as usual), but I could not make sense of the interrupt handling with this peripheral.

The code is thouroughly simple : it basically toggle GP1 pin on each counter increment, inside the ccp1 interrupt service routine - which should be called every 63ms (more or less).

Problem is, the CCP1IF flag is set immediately after returning from the ISR, while it has been of course cleared right at the beginning of the ISR (as well TMR1 disabled). The interrupt flag is then set way before TMR1 could match the CCPR registers.

(CCP1M is in software interrupt mode in this example)

Hope someone can give an insight here...

Just to be sure: are you using the last build uploaded 1.0.0-R1348?

Yes indeed (Win64) - see screenshot

Thanks.
I can't reproduce the issue with other example you provided here: https://simulide.forumotion.com/t1475-p16f88x-ccp1-perif#6369

It would be good to have the .hex file and if posible the .lst to test this case.

Sure do :-)

Out of curiosity, what would be the purpose of sheduleEvent() here ?

Code:


void McuOcUnit::ocrWriteL( uint8_t val )
{
    m_comMatch = (m_comMatch & 0xFF00) | val;
    sheduleEvents( m_timer->ovfMatch(), m_timer->getCount() );
}

void McuOcUnit::ocrWriteH( uint8_t val )
{
    m_comMatch = (m_comMatch & 0x00FF) | (uint16_t)val<<8;
    //sheduleEvents( m_timer->ovfMatch(), m_timer->getCount() );
}


McuOcUnit::sheduleEvent() is used to calculate when the next match will happen.

Solved at Rev 1355.

Fantastic ! Believe it or not, I went through the madness of building the source under wsl/Ubuntu, and it turns out it is working pretty good...
(there was just the Ubuntu-R.ttf font file missing - then I lost track of time during the build...)



So I confirm we have the expected result now with the compare ccp1 module (ie a period of circa 60ms x2  / 8Hz)
I'll test the different compare features more thouroughly next week (also I will try to activate the oc toggle feature for this pic just to see - not a major must have...)

Believe it or not, I went through the madness of building the source under wsl/Ubuntu

That's great!

there was just the Ubuntu-R.ttf font file missing

Sorry, solved at Rev 1662.

So I confirm we have the expected result now with the compare ccp1 module (ie a period of circa 60ms x2 / 8Hz)
I'll test the different compare features more thouroughly next week (also I will try to activate the oc toggle feature for this pic just to see - not a major must have...)

Nice, let me know about any problem to solve it.

So this project tests about all ccp1 compare features of a mid-range 12F PIC.

I just tweaked a little picocunit.cpp to force the OC toggling for this pic, simply adding
           case 2: setOcActs( ocTOG, ocNON ); break; // Toggle OC Pin - hacked by ci

A bit quick and dirty but it does the job. Maybe for the future it is not really necessary to have this condition : if( m_enhanced && CCPxM == 2 )
since if it is not supported by the PIC, it will not be documented anyway (plus it is not harmful and would a bit simplify the code :-)





Anyway as for the PIC683, all ccp1 compare features are working as expected as far as I could see. Thanks for your help here !
Case closed

Maybe for the future it is not really necessary to have this condition : if( m_enhanced && CCPxM == 2 )
since if it is not supported by the PIC, it will not be documented anyway (plus it is not harmful and would a bit simplify the code :-)

I almost forgot about this.
Change applied at trunk Rev 1666.

Anyway as for the PIC683, all ccp1 compare features are working as expected as far as I could see. Thanks for your help here !
Case closed

Nice, thanks for the feedback.