Feature: I2C / SPI "master" template component

It would be great to have "template interface components" in order to individually develop sensors / actors as a package.

My current situation: the students develop individual circuits with some sensors, which communicate via I2C/SPI. In the last semester this meant that one student programmed a sensor simulation on a microcontroller.. But I think it would also be great to have a more light-weight solution for emulating new components, which have a seril interface.

When only a component is needed, which acts on I2C / SPI data (e.g. LED driver) the circuits behind AD5160 and AD5247 provide great background in order to develop such a circuit.
However, when a component is needed, which supplies I2C data (e.g. the gyro/accelerometer MPU 6000) I only can think of more complicated circuits. For SPI a shift register and some logic might work, but seems also not available in present simulide.

It would be great to have some components which show how this interfacing might work. UART as an interface might also be interesting.
An "intelligent template component" (i.e. enabling bidirectional communication) would be perfect, but not always needed and sounds more complicated. Things like clock stretching are also not really necessary, I would think.

First: for some simple things you can use I2C to Parallel component.

I don't understan what exactly is your proposal.
Can you explain how this "template interface components" should work?

I have been thinking about similar things several times.
But most perifericals are complex, they have commands, configuration registers, etc.
So at the end you need to implement the internal behavior apart of the communications.
And the only 2 solutions I can see are: using an Mcu or programing a dedicated component.

Using an Mcu is not the most efficient, but it can be more efficient than a complicated subcircuit.
In adition you can create a custom Mcu with only the parts you really need.
I didn't think about this before, but indeed you can create a periferical directly using simulide MCUs instead of a subcircuit with a MCU inside... (my mind is at full RPM now)

Imagine a component in simulide that uses the MCU simulation system:
- It is defined in xml files.
- You can add memory, Registers, Interrupts, Pins, I2C, Timers, etc.
- And it runs directly high level language instead of machine code, let's say JavaScript or Python.

You could create any component with this...

Hmm... The latter solution sounds not as bad to me. But the students need do compile simulide for this, don't they? This would be a kind of "overkill" for them (they are just in the 3rd semester and already have to build up an own PCB design plus embedded C @AVR ).

For the earlier post: The idea details developed during my writing, so maybe the explanation was not as perfect (and the idea is also not thought out).. Initially I thought about an distinct I/O component for I2C and one for SPI.
As you mentioned (and as I also saw in AD5160 and AD5247) there are already good ways for receiving I2C / SPI data. Also transmitting SPI data (as SPI master) should work with a shift buffer and some glue logic.
One missing situation I see is for transmitting I2C data (beyond the I2C ROM): Something like an ADC with I2C communication but made by discrete components (ADC, storage, I2C-slave / I2C-master component)

Hmm... The latter solution sounds not as bad to me. But the students need do compile simulide for this, don't they?

No, you don't need to recompile, you create a component by adding an xml file.
The whole point of this idea is adding components without recompiling.

For example: now you can add a new AVR  just by adding an xml file if all the perifericals it uses are already implemented.
For example you can add an imaginary AVR with only 2 pins for I2C, no timers, no interrupts, 100 Bytes of RAM, no EEPROM, 231 words of flash an only the registers needed for I2C and other basic stuff.

You could do it right now just by adding an xml file.
Ok... also a package file.
It could be some issues to solve related with compiling firmware for that imaginary AVR, but that is other topic.

An AVR is relatively slow because it runs machine code, so for simple things in high level language it needs lots of low level instructions.
But it would be much faster if it could run high level language directly.
This is not possible right now and I'm not sure how to implement it. It would require a new type of core...

But if we had this core that can run Python (for example) you could create a component just by adding an xml file describing all the parts it uses: memories, communications, timers, etc.
And load a python script and run it as it was an MCU.

This just a general idea and not to be implemented in a few days... it will take time.
But this could be the perfect solution to create new components without recompiling simulide.

One missing situation I see is for transmitting I2C data

I2C_to_parallel component can transmit data back to the MCU or whatever is "Mastering" it.
This is still somehow incomplete, maybe we need an output pin to indicate Read/Write.
But right now an MCU can connect to an I2C_to_parallel and read data, for example if you connect an ADC to the I2C_to_parallel an MCU can read that ADC data.

I recently had to create an I2C temperature sensor (MAXIM DS1621) for a lab. As suggested by arcachofo , I started from I2C to Parallel component. For I2C management there are basically  3 functions to modify :
- setVChanged()  , actions to perform when state is changing on device pins
- readByte() , get the command from I2C, here you will have to define what to do for every I2C register address of the device
- writeByte() , send the register's content on I2C

If needed, the code can be found here : https://www.ensta-bretagne.fr/zerr/filerepo/SimulIDE/DS1621/ds1621.zip

An example of customization of SimulIDE to add new components is there :

arcachofo wrote:Imagine a component in simulide that uses the MCU simulation system:
- It is defined in xml files.
- You can add memory, Registers, Interrupts, Pins, I2C, Timers, etc.
- And it runs directly high level language instead of machine code, let's say JavaScript or Python.

You could create any component with this...

TimFisch wrote:Hmm... The latter solution sounds not as bad to me. But the students need do compile simulide for this, don't they? This would be a kind of "overkill" for them (they are just in the 3rd semester and already have to build up an own PCB design plus embedded C @AVR ).

This is coming:
https://simulide.forumotion.com/t422p25-scripted-component#4455