Adding of Atmega328pb

I will look again.
If SPI works for you I guess it's the testprogram I used.


I started to work on the Analog Comparator.
The 328pb has the ACO tied to PE0.

Therefore I tried to build a test program.
This worked with the 0.4.15 version but not on the newest from launchpad (using atmega328).

Code:

#include <avr\io.h>
#include <util\delay.h>


int main(void) {
 
 while(1)
 {
 if (ACSR & (1<<ACO))
 {
 PORTC|=(1<<PINC5);//LED is ON
 _delay_ms(250);
 }
 
 else
 {
 PORTC&=~(1<<PINC5);//LED is OFF
 }
 }
}

Is the Analog Comparator working in the newest Version?

If SPI works for you I guess it's the testprogram I used.

Who knows, it might work in some cases and not in other cases even if the code is correct.

Is the Analog Comparator working in the newest Version?

No... looks like it was left behind.

Basic case is working at Rev 919.
Vref and interrupts (all modes) should work, but not tested.
ADC inputs multiplexing and Input Capture Enable is not yet working.
I will implement the remainig features.

Nice. Analog Comp wokred in basic use.


I'm trying to set an Pin Output.

Code:


m_pins[2]->setPinMode(output);
m_pins[2]->setOutState(true);}

after 'setOutState()' ... m_OutState is still "false".
And the Pin gives out nothing in the simulation.

Did I forget something?

after 'setOutState()' ... m_OutState is still "false".
And the Pin gives out nothing in the simulation.

Did I forget something?

I suppose that you are working with comparators and m_pins is: McuComp::m_pins
... Or something similar.

If so, these are McuPins.
McuPins are controlled by it's Port by default.
Perifericals can take control of McuPins, then the Port will not be able to control that pin.
Perifericals can take control of Output State or Direction or both.

So you first need to take control of that pin when the periferical is enabled and release control when it's disabled.
Then you can set Output State or Direction.

To get an idea have a look at AvrTwi::configureA()

Thank you. I works now.


I was going through the list of differences from atmega328pb/328.
One is the Output Compare Modulator for Timer3+Timer4.
I saw that this function is also available on the atmega2560.


Therefore, I wanted to ask if it is implemented?
Else I would try to do it.

Best regards

I was going through the list of differences from atmega328pb/328.
One is the Output Compare Modulator for Timer3+Timer4.
I saw that this function is also available on the atmega2560.


Therefore, I wanted to ask if it is implemented?
Else I would try to do it.

No, Output Compare Modulator is not implemented.

There are some features already implemented that might be used for this.
You can register a callbacks to interrupts.

As an example you can have a look at: avradc.cpp, AvrAdc00::autotriggerConf()
There, the ADC module registers for a callback at Compare Match or Timer Overflow.
Then, AvrAdc::callback() will be called and it will start a new conversion.

Probably you could use this or create another mechanism that can be reused by any module.


But now I see a posible error: If the interrupt is not enabled , then callbacks will not be called:
Not sure why it is like this now, I need to have a look.

mcuinterrupts.cpp, Interrupt::raise( uint8_t v )

Code:

    if( m_enabled )
    {
        m_interrupts->addToPending( this ); // Add to pending interrupts
        if( !m_callBacks.isEmpty() ) { for( McuModule* mod : m_callBacks ) mod->callBack(); }
    }

It should be:

Code:

    if( m_enabled )
        m_interrupts->addToPending( this ); // Add to pending interrupts
    
    if( !m_callBacks.isEmpty() ) { for( McuModule* mod : m_callBacks ) mod->callBack(); }

ok thanks..

I guess, I will have to create a new module or could I somehow add it to the existing timer module?

I guess, I will have to create a new module or could I somehow add it to the existing timer module?

This is a decision to make.
But in my opinion is probably better a new module.

Some tips:
You can get a pointer to any Timer from any module:
McuTimer* timer3 = m_mcu->getTimer("TIMER3");

And you can get a pointer to an Output Compare module in that Timer:
McuOcUnit* oc3b = timer3->getOcUnit("OC3B");

Timer and ocUnit names are those defined in: mcumodel_perif.xml

Thanks for the tips.

I noticed some miss named bits in 328pb_perf & 328pb_regs.
Fixed it.

Also I made a test setup for the OCM.
Using the same skript for Timer3 or Timer4 and Timer1.

Code:

#include <avr/io.h>


 int main() {
 DDRD   = (1 << 2); // OC3B is  D2
 /*
 ICR3   = 10000;
 OCR3B  =  5000;    
 TCCR3A = (1 << COM3B1) | (1 << WGM31);            
 TCCR3B = (1 << WGM33) | (1 << WGM32) | (1 << CS31);
 */
 
 ICR4   = 10000;
 OCR4B  =  5000;    
 TCCR4A = (1 << COM4B1) | (1 << WGM41);            
 TCCR4B = (1 << WGM43) | (1 << WGM42) | (1 << CS41);
 
 // For comparison, Timer 1 works as expected, same code
 DDRB   = (1 << 2); // OC1B is B2
 ICR1   = 10000;
 OCR1B  =  5000;
 TCCR1A = (1 << COM1B1) | (1 << WGM11);
 TCCR1B = (1 << WGM13) | (1 << WGM12) | (1 << CS11);

 while(1);
}


It produces different outcomes.
Yellow Output from Timer3 or Timer4.
Green Output Timer1.

I got the creation of the module, the configuration and the autotrigger-callback to be functioning.

But after the startup of the simulation " void McuOcm::runEvent()   "
never gets called.

Do I need to do more then set the callback to one of the timer interrupts?
I orientated myself on the AvrAdc.


Also is there a extra bit where the timer output gets written to?

I noticed some miss named bits in 328pb_perf & 328pb_regs.
Fixed it.

Thanks, changes added.

Also I made a test setup for the OCM.
Using the same skript for Timer3 or Timer4 and Timer1.
It produces different outcomes.

I will have a look.

But after the startup of the simulation " void McuOcm::runEvent()   "
never gets called.

McuOcm::m_modulateTime is never defined.
McuOcm::runEvent()  will be called m_modulateTime picoseconds after Simulator::self()->addEvent() is called:

Simulator::self()->addEvent( m_modulateTime, this );

Do I need to do more then set the callback to one of the timer interrupts?
I orientated myself on the AvrAdc.

I don't know  exactly what you want to do at this moment.
If you just want to get the callback for Timer3 overflow, then that's enought.

What I see is that "trigger" is never == 5, m_trigger is always = 0.
So it will never register for the callback.

To do a quick test you can do this to register to the callback:
m_timer3->getInterrupt()->callBack( this, true );

And this to unregister:
m_timer3->getInterrupt()->callBack( this, false );

Also is there a extra bit where the timer output gets written to?

I don't understand what you mean.

I don't know  exactly what you want to do at this moment.
If you just want to get the callback for Timer3 overflow, then that's enought.

My plan was using the Timer interrupt to do the modulating when OCM is activated.

So when the Timer interrupt come:
-get the output values from Timer3 and Timer4.
-Modulate according to setting
-Give out value at pin

How I get the outputvalues from Timer3 and Timer4 I still have to look.
Also how to handle that OCM/Timer3/Timer4 will use one Pin -so the Timers have to get blockt off.

First thing is that I don't have any OCM unit in megax8pb_perif, at least not in the files you shared.

How I get the outputvalues from Timer3 and Timer4 I still have to look.

OC units have their own modules.
You already have pointers to them in your code (btw: second one should be "OC4B"?):

Code:

    m_OC3B = m_timer3->getOcUnit("OC3B");
    m_OC4B = m_timer4->getOcUnit("OC3B");

This OCM module is complex (and it will require some modifications in other modules).
I don't know this module very well, so please correct me if I'm wrong in something.
Lets go by parts:

1- This functionality enabled/disabled when both OC3B and OC4B try to control the same pin.
You need to find a way to detect this condition.
Currently I don't see an easy way to do it.

The simplest way that comes to my mind is that Each OC unit checks if the pin is already controlled.
If the pin is already controlled, the it calls OCM unit.
But by now OC units don't know about OCM.

2- You need a way to inhibit OC units to control their pins while OCM is activated.
This needs a flag or something that can be set/cleared and then used in McuOcUnit::runEvent() to inhibit drivePin()
You already have pointers to OC units in your code.
Now you need to inplement a flag or whatever in the OCunits.

3- The mode of operation is determined by PORTD2.
So you need a way to detect changes in this bit.
This can be letf for later...

4- Once OCM is in control it needs to be called when any OC unit tries to change their pin.
If OC units kew about OCM, then each OC unit could call OCM instead driving it's pin.


You can solve 1 and 4 by giving OC units a pointer to OCM.
OCM itself already knows OC3B and OC4B, so it could call them and pass a pointer to "this".

As I see the situation, not sure if better a new variant for AVR OC units.
By now I think we can take it easy, and add this to existing AvrOcUnit:
- A flag to inhibit pin control with a setter.
- A pointer to OCM unit with setter.
- A mechanism to drive pin or call OCM depending on the flag.
  I added a funtion in McuOcunit that makes this easier at Rev 939.
  So you can override McuOcUnit::setPinSate() to set the pin state or call OCM unit depending on the flag.
- In AvrOcUnit::configure() detect if the pin is already controlled (needs implementation in McuPin) and call OCM if needed.

With this aproach you don't even need callbacks.
Still pending how to get PORTD2 changes to configure mode.

This is how I see the situation in relation to what is already implemented in simulide.

With my first implementation i run into a "segmentation" fault, when getting the OCMActive value in OcUnit.

I implemented as followed.

1. I check if both OCnB are active, if yes OCM is active
2. OcUnit only takes control of the Pin if OCM is inactive
3. Operation mode left for later
4. I changed "drivePin()" so when OCM is active it calls the "modulate()" function of OCM and not "drivePin()".

With my first implementation i run into a "segmentation" fault, when getting the OCMActive value in OcUnit.

I think the main issue is:
- m_OCxB->getOCM(this); should be called at AvrOcm constructor, if not m_OCxB could be undefined when AvrOcUnit calls it.

I will have a deeper look and let you know if I find something else.

It help.Thx
I noticed more errors.
For example every OcUnit called OCM.

I think it's working, but not sure jet. I only have the "&" mode for OCM added jet.


I tested with the attached script for the atmega.

I think it's working, but not sure jet. I only have the "&" mode for OCM added jet.

Nice.

One thing I noticed is that everything is "hardcoded" to the OC unit names.
This has 2 implications:

1- The module is not configurable for other possible OC unit combinations in other AVR models.
This can be solved by adding a field ocunits="OC3B,OC4B" in the OCM description in perif.xml file.
And let McuCreator set OCM::m_OC3B, OCM::m_OC4B and AvrOcUnit::m_OcmM.
Also OCM::m_OC3B, OCM::m_OC4B should be generic names like OC1,OC2 or whatever.

2- As a general rule, for speed purposes, Strings should not be used during "MCU run time" if possible.
I'm talking about: McuOcUnit::drivePin( ocAct_t act )
There are several string comparisons.
So, here OC unit names are harcoded and not configurable.

Also This comarisons are slow and implementing in McuOcUnit will slow down all OC units in all MCUs.
Better overload McuOcUnit::setPinSate() in AvruOcUnit::setPinSate(), so it only affects AVRs:

McuOcUnit::m_active flag is kind of redundant, because you can use m_mode instead:
if m_mode == 0 then not active
if m_mode != 0 then active
You can use McuOcUnit::getMode()

Another aproach would be to use McuOcUnit::m_active flag as an indicator that the OC unit is controlling the pin.
And then use this flag instead in AvruOcUnit::setPinSate()

Code:

void AvrOcUnit::setPinSate( bool pinState )
{
    if( m_active ) m_ocPin->setOutState( pinState );
    else           m_OcmM->Modulate( pinState );
}

I cleaned up. got rid of the string comparisons and added the (and/or) Modi.
OCM is getting called correct and doesn't interrupt when its not active.
->Programm sequence is correct.

I still get the "only positive flank" output for Timer3/Timer4.
Therefore I cant really see If the OCM is really properly working.
- I attached the cleaned up files.




Also I attached two other things I did.
For one 328pb has the Analog Comparator hard connected to one PIN.
- I edited AvrComparator in a way then when you add a third pin in perf this one will output the comparator result. Reason is that the register which is named in the "comparison of 328/328pb" doesn't show up in  datasheet.


Further I build a Touchpad (ErTP080) based on the joystickwidget.
Also I adapted dspinbox as such that inputs like "20e2" are valid an usable.

I still get the "only positive flank" output for Timer3/Timer4.
Therefore I cant really see If the OCM is really properly working.

You should get any pin change coming from OC units... I will have a look.

I still don't have the OCM module entry in perif.xml file, so I can't test it.
EDIT: I see it is in attached files.

Also I attached two other things I did.
For one 328pb has the Analog Comparator hard connected to one PIN.
- I edited AvrComparator in a way then when you add a third pin in perf this one will output the comparator result. Reason is that the register which is named in the "comparison of 328/328pb" doesn't show up in  datasheet.


Further I build a Touchpad (ErTP080) based on the joystickwidget.
Also I adapted dspinbox as such that inputs like "20e2" are valid an usable.

Wow... thanks.

Some issues that are not clear to me:

For one 328pb has the Analog Comparator hard connected to one PIN.
- I edited AvrComparator in a way then when you add a third pin in perf this one will output the comparator result. Reason is that the register which is named in the "comparison of 328/328pb" doesn't show up in datasheet.

If Comparator is using an output pin, then we should create a variant, but there is missing information:
Where is the bit "ACOE"?
By now there is no such bit defined in megax8pb_regs.xml.

Further I build a Touchpad (ErTP080) based on the joystickwidget.

I can't find any datasheet by "ErTP080".
Is this an "standard" resistive touch pad?
This also probably will need a dedicate discussion.

Added a generic resizable resistive touchpad based on your ErTP080 (4 wires) at Rev 270:
https://simulide.forumotion.com/t482-resistive-touchpad-4-wires#2638

arcachofo wrote:Some issues that are not clear to me:

Where is the bit "ACOE"?
By now there is no such bit defined in megax8pb_regs.xml.

The problem here was that I wasn't able to find an entrance of this bit in the register description of atmega328pb

The problem here was that I wasn't able to find an entrance of this bit in the register description of atmega328pb

I found something:
https://www.pololu.com/file/0J1464/Atmel-42559-Differences-between-ATmega328P-and-ATmega328PB_ApplicationNote_AT15007.pdf

page 17 wrote:4.7. Analog Comparator Control and Status Register B
The Store Program Memory Control and Status Register contains the control bits needed to control the
Boot Loader operations.
When addressing I/O Registers as data space using LD and ST instructions, the provided offset must be
used. When using the I/O specific commands IN and OUT, the offset is reduced by 0x20, resulting in an
I/O address offset within 0x00 - 0x3F.
Name:  ACSRB
Offset:  0x4F
Reset:  0x00
Property:

When addressing as I/O Register: address offset is 0x2F

ACOE Access R/W Reset 0

Bit 0 – ACOE: Analog Comparator Output Enable
When this bit is set, the analog comparator output is connected to the ACO pin.

In that pdf there are some other registers that are not in the datasheet.

Topic moved to "Development" section.

Forgot to mention that Comparator Output Pin was added at Rev 978.

There are some minor issues in OCM so I didn't add it yet, hopefully I will add it in the next days.

dspinbox will be very useful, it is also the base to add functionality like math operations: 100*2 and so.
But I still have to replace current spinboxes with this one everywhere.
There are also some things I still don't understand very well, when I get fully into this I will update here.