SimulIDE_0.5.16 Tester builds

These are Windows 64 builds of trunk at:

...

Last commits: https://bazaar.launchpad.net/~arcachofo/simulide/trunk/changes

Issues to test:
- New Compilers.
- New Diodes.
- Component properties.


For new AVRs use only atmega 328.



___________________________________________________

Hi, I found more some morge issues:

1. The slave state machine seems to stop at some point. I tried to connect a TWI master to a slave and started transmitting. Then, the slave TWSR shows 0x60 (= "I saw my address!") and 0x80 (= "Yay, some data for me!"), but TWDR does not get filled up.
   
2. When one uses a baudrate in the TWI-slave (TWBR) the ACK behaves strange. It looks like the ACK pulldown is not released anymore and the slave occupies SDA forever.
   
3. more a convenience topic: it would be great to have the "reload firmware" in the menu and the file path in the property window back  
   

The first one is the most annoying one, since it hinders the correct master - slave connection. I would be really great to get a fix for this in order to test TWI further.
As every time: one bug fixed, only @️#! to go...

Aand more things...

1. Mayor bug: When sending multiple data in one TWI message, and the next bit after ACK ist high, this bit gets interpreted as STOP condition.
   It seems that the ACK / SDA = low is to long active (I had similar issues with mit soft slave TWI ACK...).
   
   The firsts image shows address byte + SLA-ACK + Data1 + SLA-ACK  + Data2. Data1 has MSB = 0, Data2 has MSB = 1 and shows the SDA rising after SCL rising.
   
   The second image depicts the detail with the wrong stop condition.
   
   
2. Only minor issue: It seems that "only" standard mode I2C is possible, i.e. up to 100kHz. Beyond 200Hkz the slave is not ACK'ing - it seems that it cannot catch up anymore.
   
   Standard mode I2C is for me absolute fine . But it would be great to clarify this detail in the delivery notes.
   

Thanks.. I will have a look.

Hi.

I solved some issues and working in the wrong "stop condition".
I will also implement "Reupload" and "Autoload" (loads firmware at simulation start).

It would be nice if I had the circuit ahd firmware you are using (source and hex) , so I can replicate the problems much faster that creating my own.

New build at Rev 346 uploaded. Details in first post.

Hopefully solved:

- The slave state machine seems to stop at some point. I tried to connect a TWI master to a slave and started transmitting. Then, the slave TWSR shows 0x60 (= "I saw my address!") and 0x80 (= "Yay, some data for me!"), but TWDR does not get filled up.

- When one uses a baudrate in the TWI-slave (TWBR) the ACK behaves strange. It looks like the ACK pulldown is not released anymore and the slave occupies SDA forever.

- more a convenience topic: it would be great to have the "reload firmware" in the menu and the file path in the property window back

Probably solved:

- Mayor bug: When sending multiple data in one TWI message, and the next bit after ACK ist high, this bit gets interpreted as STOP condition.

Hi,

sorry for not already sending the test code. It's now available here:
https://wiki.mexle.org/microcontrollertechnik/10._i2c_schnittstelle#software

I also found some issues in the new one:

• Mayor: It seems like the slave can only acknowledge the first message. In the test code, I see an ACK after the address message, but there is no ACK after the data message. I tried to reset the TWI state machine within the slave by TWSTO=true, to restart by TWEN=true and to reset the interrupt bit (TWINT=1) but haven't seen a change.
  
• Mayor: After the first message bunch and STO+STA the TWI frequency seems to speed up. It looks like a doubling of the frequency after the first STO+STA.
  
• Minor: I use the condition "Ch1R & Ch2H " in order to pause on STOP condition. However, when i restart the simulation (start button) I have additionally to unpause, since the MCU does send an STOP like signal by activating TWI. This is technically not wrong, but still annoying.
  
  

Thanks for the test example.

Mayor: After the first message bunch and STO+STA the TWI frequency seems to speed up. It looks like a doubling of the frequency after the first STO+STA.

Solved in Rev. 347.

Minor: I use the condition "Ch1R & Ch2H " in order to pause on STOP condition. However, when i restart the simulation (start button) I have additionally to unpause, since the MCU does send an STOP like signal by activating TWI. This is technically not wrong, but still annoying.

Not sure why but this is now not happening to me.
Pausing only at real stop condition.
Maybe some change solved this just by chance...

Mayor: It seems like the slave can only acknowledge the first message. In the test code, I see an ACK after the address message, but there is no ACK after the data message. I tried to reset the TWI state machine within the slave by TWSTO=true, to restart by TWEN=true and to reset the interrupt bit (TWINT=1) but haven't seen a change.

Not sure about this, but as I see in i2c_slave.c TWI is being disabled at I2C_readData() ??

Code:

TWCR = (1<<TWSTO)|(1<<TWEA)|(1<<TWINT);  //  TWEN=0:

For me the slave (in Rev 346) was also not ACK'ing without the line nor with "TWCR = (1<<TWSTO)|(1<<TWEA)|(1<<TWINT)|(1<<TWEN)"

But you are right, there has to be the "1<<TWEN" inside.

The TWSTO ist there to resets the state machine:
"In slave mode, setting the TWSTO bit can be used to recover from an error condition. This will not generate a STOP condition, but the TWI returns to a well-defined unaddressed Slave mode and releases the SCL and SDA lines to a high impedance state."
https://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-9365-Automotive-Microcontrollers-ATmega88-ATmega168_Datasheet.pdf#page=181

The TWSTO ist there to resets the state machine:
"In slave mode, setting the TWSTO bit can be used to recover from an error condition. This will not generate a STOP condition, but the TWI returns to a well-defined unaddressed Slave mode and releases the SCL and SDA lines to a high impedance state."

There are some things not implemented yet like arbitration lost or SCL stretching.
But this is implemented.
Not sure if it's working properly though.

I will try different variations...

It looks better an better every time! Not only the increasing implenentation of the COMs but also the "debug features" like MCU Monitor and the logic analyzer are really great for education.

I'm quite eager to test the next versions

sI found another bug, or better not working function, which worked already some month ago.

Somehow I'm not able to get the internal pullups of the AVR328 working.

hex and simu are attached.

Expected behavior:
- PORTC shows in MCU monitor the setting of the switches.

Shown behavior
- PORTC does not change.
- DDR ist correct
- functionality is ok for external pullup.

Code:

Code:


#include <avr/io.h>

int main(void)
{
 PORTB = 0b11111111;
 DDRC = 0b11111111;
    while (1)
    {
 PORTC = PINB;
    }
}


Aand another bug or better a "difference to RL":

It's a minor bug, and discussable whether it has to be solved.
I2C works even without pullups... Usually the I2C modules are not able to send logic high, but only "high impedance" or "logic low".

This might not be most important thing to correct, I know. But it confused some of my students, had it works without the external pullups..

I found a problem not related to I2C that is meesing with all I/O pins.
The funny thing is that after solving thiss, I2C does not work, so one error was compensating for another error.

Now I'm rewriting a few things, and solving issues.
I will have a look to pullups as well.

I think all issues are solved in Rev. 348.

Details in first post.

I will test the fixes in the next days.
Thanks very much.

I also tested other parts (also with the version R348) and found some "hickups":

1. The ADC does not seem to work probperly in the new AVR core. I do not get any change in ADCL and ADCH.
   
2. The UART monitor is missing. I roughly had in mind that you mentioned you want to develop a separate output component for this.
   

Edit: Demo code, hex and simu of a temperature sensor attached. It also should output the temperatur via UART. Input of r + return via UART resets the max temp.

I also have still some issues of not visible inputs on the option window (e.g. in the demo simu: one of the thermistor hides the B value)

Hi. Somehow I'm not able to get the TWI test circuit and code running.
Since I mixed my software TWI code with the test one, ther were some bugs also in the test code.. (e.g. the port with I2C was set as an output).

The downloadable c+hex+simu files at the following link work in R346, but in R348 the slave pulls the TWI down right after the start condition : https://wiki.mexle.org/microcontrollertechnik/10._i2c_schnittstelle#software

Since I mixed my software TWI code with the test one, ther were some bugs also in the test code.. (e.g. the port with I2C was set as an output).

That should not be a problem since the TWI module takes total control of the Pins, overiding DDRX and PORTX.
Anyway I noticed it when I added 7segments to see the received data: ovbiously PORTC could not be used, and the only option was PORTD.

Hi. Somehow I'm not able to get the TWI test circuit and code running.

What's the problem?
Seems to be working for me.
One thing I changed is I'm not using tunnels to avoid mixing problems that could come from tunnels.
I will try with tunnels and see what happens.




With this code:

MASTER (using pullups):

Code:

/* ----------------------------------------------------------------------------
 
 Experiment 10:   I2C Kommunikation
 =============    ===============================
 
 Dateiname   : I2C_SimpleMaster.c
  
 Autoren    : Tim Fischer       (Hochschule Heilbronn, Fakultaet T1)
              
 Datum      : 23.06.2021
  
 Version    : 1.0
  
 Hardware:  Simulide 0.5.16-RC5
 
 Software:  Entwicklungsumgebung: AtmelStudio 7.0
            C-Compiler: AVR/GNU C Compiler 5.4.0
 
 Funktion : TBD
 
 Displayanzeige:    TBD
 
 Tastenfunktion:    keine
 
 Jumperstellung:    keine
 
 Fuses im uC:       CKDIV8: Aus (keine generelle Vorteilung des Takts)
 
 Header-Files:  lcd_lib_de.h (Library zur Ansteuerung LCD-Display Ver.1.3)
 
  
// ----------------------------------------------------------------------------*/
 
// Deklarationen ==============================================================
 
// Festlegung der Quarzfrequenz
#define F_CPU 8000000UL   // CPU Frequenz von 8MHz
#define F_SCL 40000L   // Baudrate von 100 kHz

// Include von Header-Dateien
#include <stdio.h>
#include <avr/interrupt.h>
#include <math.h>   
#include <util/delay.h>

// Konstanten
#define SET_BIT(PORT, BIT)  ((PORT) |=  (1 << (BIT))) // Port-Bit Zustand setzen
#define CLR_BIT(PORT, BIT)  ((PORT) &= ~(1 << (BIT))) // Port-Bit Zustand loeschen
#define TGL_BIT(PORT, BIT)  ((PORT) ^=  (1 << (BIT))) // Port-Bit Zustand wechseln (toggle)

//Funktionsprototypen
void I2C_Init();
void I2C_transmitStart();
void I2C_transmitDataOrAddress(char Data);
void I2C_transmitStop();
void I2C_Data();

uint8_t TWI_Address = 0b0001010;
uint8_t TWI_Data   = 0b00110111;


int main(void)
{
   cli ();                  // Interrupt aktivieren
    SET_BIT(PORTC, PORTC4);
    SET_BIT(PORTC, PORTC5);
   SET_BIT(DDRD, PORTD1);      // Debug Ausgang ansprechen -> Wechsel auf low
   TGL_BIT(PORTD, PORTD1);      // Debug Ausgang ansprechen -> Wechsel auf High
   I2C_Init();               // Initialisierung von TWI anstoßen


   while (1)
   {
      TGL_BIT(PORTD, PORTD1); // Debug Ausgang ansprechen -> Wechsel auf High
      I2C_Init();            // Initialisierung von TWI anstoßen
      TGL_BIT(PORTD, PORTD1); // Debug Ausgang ansprechen -> Wechsel auf Low
      I2C_transmitStart();   // Startbit schreiben
      TGL_BIT(PORTD, PORTD1); // Debug Ausgang ansprechen -> Wechsel auf High
      I2C_transmitDataOrAddress((TWI_Address<<1) + 0);// Adresse senden
      TGL_BIT(PORTD, PORTD1); // Debug Ausgang ansprechen -> Wechsel auf Low
      I2C_transmitDataOrAddress(TWI_Data);// Daten senden
      TGL_BIT(PORTD, PORTD1); // Debug Ausgang ansprechen -> Wechsel auf High
      I2C_transmitStop();      // Stoppbit schreiben
      TGL_BIT(PORTD, PORTD1); // Debug Ausgang ansprechen -> Wechsel auf Low
      _delay_us(1);
      
   }
}

/////////////////////////////////////////
// I2C Initialisierung
/////////////////////////////////////////
void I2C_Init()
{
   TWSR = CLR_BIT(TWSR, TWPS0);// Es wird kein Prescaler verwendet
   TWSR = CLR_BIT(TWSR, TWPS1);//
   TWCR = 0;               //
   TWBR = ((F_CPU/F_SCL)-16)/2;// die Bitrate wird mittels CPU Frequenz und Serial Clock Frequenz ermittelt
}

/////////////////////////////////////////
// I2C Startbit senden
/////////////////////////////////////////
void I2C_transmitStart()
{
   TWCR = (1<<TWSTA)|(1<<TWEN)|(1<<TWINT); // TWSTA = Startbit aktivieren, TWEN = TWI starten (ENable), TWINT = Interrupt bit löschen (durch setzen)
   while (!(TWCR & (1<<TWINT))){};         // warten bis Übertragung erfolgreich, Trigger ist hier das Setzen von TWINT
}


/////////////////////////////////////////
// I2C Adressbyte/Daten senden
/////////////////////////////////////////
void I2C_transmitDataOrAddress(char Data)                  
{
   TWDR = Data;
   TWCR = (1<<TWINT)|(1<<TWEN);         // TWEN = TWI starten (ENable), TWINT = Interrupt bit löschen (durch setzen)
   while (!(TWCR & (1<<TWINT)));         // warten bis Übertragung erfolgreich, Trigger ist hier das Setzen von TWINT
}

/////////////////////////////////////////
// I2C Stoppbit senden
/////////////////////////////////////////
void I2C_transmitStop()
{
   TWCR=(1<<TWSTO)|(1<<TWINT)|(1<<TWEN);   // TWSTO = Stopptbit aktivieren, TWEN = TWI starten (ENable), TWINT = Interrupt bit löschen (durch setzen)
   while (!(TWCR & (1<<TWINT)));         // warten bis Übertragung erfolgreich, Trigger ist hier das Setzen von TWINT
   //   while(TWCR & (1<<TWSTO));            // warten bis Übertragung erfolgreich, Trigger ist hier das setzen von TWINT
}

SLAVE:

Code:

/* ----------------------------------------------------------------------------
 
 Experiment 10:   I2C Kommunikation
 =============    ===============================
 
 Dateiname   : I2C_SimpleMaster.c
 
 Autoren    : Tim Fischer       (Hochschule Heilbronn, Fakultaet T1)
 
 Datum      : 23.06.2021
 
 Version    : 1.0
  
 Hardware:  Simulide 0.5.16-RC5
 
 Software:  Entwicklungsumgebung: AtmelStudio 7.0
            C-Compiler: AVR/GNU C Compiler 5.4.0
 
 Funktion:   tbd

 
  
// ----------------------------------------------------------------------------*/
 
// Deklarationen ==============================================================
 
// Festlegung der Quarzfrequenz
#define F_CPU 16000000UL
#define F_SCL 10000L //100 kHz

// Include von Header-Dateien
#include <avr/interrupt.h>

// Konstanten
#define SET_BIT(PORT, BIT)  ((PORT) |=  (1 << (BIT))) // Port-Bit Zustand setzen
#define CLR_BIT(PORT, BIT)  ((PORT) &= ~(1 << (BIT))) // Port-Bit Zustand loeschen
#define TGL_BIT(PORT, BIT)  ((PORT) ^=  (1 << (BIT))) // Port-Bit Zustand wechseln (toggle)

//Funktionsprototypen
void I2C_Init();
void I2C_setAddress(char Address);
char I2C_readData();

uint8_t TWI_Address         =  0b0001010;
uint8_t TWI_AddressMask      = 0b11111110;

int main(void)
{
   DDRD= 0xFF;                        // Auf DDRC die Daten ausgeben
   I2C_setAddress(TWI_Address);            // eigene Adresse setzen
   
    while (1)
    {
      PORTD = I2C_readData();            // Daten an PortC ausgeben
    }
}

//////////////////////////////////////////////////
// Setzen der I2C Adresse auf die der Slave hört
//////////////////////////////////////////////////
void I2C_setAddress(char Address)                  
{
   TWAR = (Address<<1);                        // Adresse in das Pseudoregister schreiben
   TWAMR= TWI_AddressMask;                        // Adressmaske in das Pseudoregister schreiben
   TWCR = (1<<TWEA)|(1<<TWEN)|(1<<TWIE);            // Enable Ack, Enable Interupt und Enable TIW

}

//////////////////////////////////////////////////
// Auslesen der übermittelten Daten
//////////////////////////////////////////////////
char I2C_readData()                  
{
   while (!(TWCR & (1<<TWINT)));                  // warte solange bis TWINT gesetzt ist
   //TWCR = (1<<TWSTO)|(1<<TWEA)|(1<<TWINT);            // Resetieren der State Machine, nicht zwingend notwendig
   return TWDR;                              // übermittle Daten
}


I will test your eval code and recheck where it differs.
In the meantime I found more things on SPI...

The image below shows one of my educational circuits (files attached). On top the old AVR MCU is shown, on the bottom the new one. Monitor and analyzer are also on their respective positions. The logic analyzer shows:
- CLK (f1st yellow line),
- MOSI (2nd bright blue line),
- DC (3rd orange line, not used in SPI),
- CS (4th green line)

1. The new AVR shows in the in the mcu monitor neither the register names to choose nor the bit naming of the status register.
   
2. The mcu monitor of the new AVR displays not the correct register address in the first column.
   
3. The EEPROM of the new AVR is not accessible.
   
4. The SPI with the new AVR seems to invert CLK and MOSI. On CS high (green) both are high, when SPCR::CPOL=0 and CPHA=0. I thought the upper one with the old AVR is correct for this SPI configuration. The new one seem not to change polarisation and phase with CPOL and CPHA changed.
   

An additional question: One of the tab is called "variables". Should it be possible to see the values of internal variables in the mcu monitor? When I put in a variable name, I don't see the correct value and also not the correct address.

I also try to write simpler test code for SPI, which especially tests the bidirectional communication.



edit: added better image..

Thanks for all the test examples.

I will have a look to these issues.

- There are many things still not implemented, like uart monitor and some mcu monitor features.
I will be adding them as they are needed for testing.

- It is not possible to get variables from an hex file.
It would be possible from elf files, but most variables are optimized and doesn't exist as a permanent location in RAM, so ussually only available from a debugger.

In the case of Arduino sketches compiled in simulide it is possible to get truly global variables (those having a permanent location in RAM).

In this version it is possible to add custom compilers (eg. avr-gcc), but still very basic.
It should be possible to get global variables from avr-gcc generated .elf files, but right now this is half done.

- Polarisation and Phase in New SPI Module should work. I will have a look.

I also try to write simpler test code for SPI, which especially tests the bidirectional communication.

In the current state of development this is the best aproach.
There are too many things that can fail...

SPI seems to work for me, at least master mode.
This is using Arduino SPI library and Adafruit PCD8544.
Clock polarity and phase looks ok:

I tried I2C but did not succeed:
I built up a new simu file in SimulIDE_0.5.16-R348_Win64 and used the code unchanged, but my output shows the resulting image below  
Is the SimulIDE_0.5.16-R348_Win64 the correct one?

I got confused by the name "variable" maybe it's better to call it register . I know the use of the elf file - we had this in automotive, too (there w). I was wondering whether simulide looks for this files automatically..

Hmm.. also the SPI with pcd-spi-h.simu seems not to work for me.
It shows the similar behavior: CLK starts with high..

Could you check whether the R348 in the first post is the correct one?

Could you check whether the R348 in the first post is the correct one?

Maybe...
I built again and uploaded.

Hmm... strange. I still see a different CLK / MOSI situation (high between the signals).    

Might there be some difference for the WIN export?
Which plattform do you use for testing?