SimulIDE 1.0.0 Tester builds.

Alex68 wrote:Из тех же инструментов в сборке R815. Модель двух разрядного индикатора. Нет индикации уровня. На всех остальных с большим числом разрядов так же.

That is not how you test a subcircuit.
That subcircuit is working perfectly.

arcachofo wrote:

Например вот такое. Простая схема инструмента - формирователя импульсной последовательности с клавиатуры. В двух версиях. Может такое и с моделями контроллеров. Где то что то не пропечаталась связь и все. Работать не будет.

Just move that decoder and see what happens...

Please, stop talking about what you don't know.
Again: you have no idea of what you are talking about, and you are talking silly things.

This section is for testers, for people that is willing to help testing and reporting errors.
You found an error in a subcircuit and you don't report what model has the problem.
Instead you start to talk silly things about a topic you ignore completely.

Куда я должен перемещать этот декодер если у него внутри во первых неправильно сделан шифратор на 15. И связи от этого нарушены. Я его открыл ВАМ а вы не видите видимо. Подписал
в одной версии он правильно сделан в последней нет.
Это разве не ошибка. О каком тестировании может речь идти если
обычная цифровая база сделана не правильно в версии R815.
Я у себя конечно исправлю эти связи. И он будет работать.
Сейчас я вам открою индикатор логических уровней и покажу как он хорошо по вашему работает.

Куда я должен перемещать этот декодер если у него внутри во первых неправильно сделан шифратор на 15. И связи от этого нарушены. Я его открыл ВАМ а вы не видите видимо.

This guy...

"Move it" means just that: MOVE IT



And that is not a problem, that subcircuit works perfectly as far as I know.

I'm tired of wasting my time with this kind of things.

Tried to open ATmega1281.

Hi dvarkin.

Tried to open ATmega1281.

Thanks.
You can solve the issue by editing line 20 in m1281_int.xml.
End character missing, just add it: />

I'm going to fork the scripting talk to it's own thread:
https://simulide.forumotion.com/t422-scripted-component

New build at Rev 853 uploaded.

Have a look at first post for download links and list of changes.

New build at Rev 853 have been reuploaded.
I was not sure that a fix for a problem that can cause AVRs to crash was included in last build.

The MCUs (at least explicitly the mega328) are missing SimulIDE_1.0.0-R853_Win64...

The MCUs (at least explicitly the mega328) are missing SimulIDE_1.0.0-R853_Win64..

Ohh sorry, I will reupload.

Anyway you can fix it in the meanwhile by creating the data folder and move everything there except for simulide executable and examples folder.

Files reuploaded...

During testing, I found 2 errors.

1) encoder error when operating in 16-bit mode.


2) The probes are not working correctly. In some situations, they do not display information. After redrawing the screen (for example, when zooming with the mouse wheel), the correct value is shown. For example, test circuits for subcircuits: 74HC174_test, 74HC112_test, 74HC151_test, …

Thanks, I will have a look.

For me the "not correctly working visible output" disappears for 74HC174_TEST.simu @R853 / WIN10 when I activate "show voltage".

I also had a similar kind of "not correctly working visible output" issue when using mulitple 7-segment displays driven by a MCU with the R853 / WIN10 . There it seems to be connected to the simu speed.
Fizik_S's problem doesn't dissappear when reducing the speed.

1) encoder error when operating in 16-bit mode.

Solved at Rev 862.

2) The probes are not working correctly.

Solved at Rev 863.

I also had a similar kind of "not correctly working visible output" issue when using mulitple 7-segment displays driven by a MCU with the R853 / WIN10 . There it seems to be connected to the simu speed.

Can you explain this issue?

I also had a similar kind of "not correctly working visible output" issue when using mulitple 7-segment displays driven by a MCU with the R853 / WIN10 . There it seems to be connected to the simu speed.

I forgot to mention:
At low simulation speed, if you are multiplexing or doing PWM, you will see the led turning on and off.

My bug is a bit trickier to trigger, but tracking it down gave me some "new bugs" (without any direct connection have to think on famous dilbert ):

The first bug is: logic analyzer and wire animation does not work for flashed hex at any speed.

The second bug is: The direction arrows are going crazy when putting simu steps = 1 sec and steps per second to 1. At this setting they shouldn't move faster than per second. At one point the simulation crashed when pushing the stop button (I don't know the additional conditions, so i cannot reproduce it anymore).

The third bug is: the 7 segment does not show anything, when running at 100% speed and zooming the display large before start. Changes only when focus is back to window.

The 4th(?) bug is: the 7 segment does not show anything, when after the 3rd bug running at 0.01% speed after start. Changes only when focus is back to window.

The 5th(?) bug is: after stimulating 3rd and 4th bug, the 7 segment does not show anything at any speed. Changes only when focus is back to window.


Some of the bugs can be seen here:
https://wiki.mexle.org/_media/simulide_bugs/7segment.mp4

Initially, I only had the not refreshing at 100% and zoom bug, but it seems to be a bug family. I think I have to pay my students for the bug finding...

Edit: Crashing on the second bug seems reproducable, when the simulation runs for >10s with "crazy arrows" and then trying to stop on my setup (WIN10)

(without any direct connection have to think on famous dilbert Very Happy ):

Man... this circuit is EVIL!!!!

jep... The basic circuit used a timer based 10msec trigger for the output and only produced two of the bugs.
But my "purified one" seems to jump deeper into pandoras box...

The logical primitive "Function" allows only lowercase letters in logical formulas (i 0, i 1, ...). When using capital letters in a formula (I 0, I 1, ...), "Function" does not work correctly.


In the program version 0.4.15, both spellings work.

The logical primitive "Function" allows only lowercase letters in logical formulas (i 0, i 1, ...). When using capital letters in a formula (I 0, I 1, ...), "Function" does not work correctly.

Thanks. Solved at Rev 864.

@TimFish
About the "evil" circuit:
First let me say that this must be part of a malefic plan carefully designed to drive me mad.
But is has no chance to succeed... I'm already mad!!

Let's try to analize...
Not sure why, but this is how the circuit is working:
- All pins are configured as inputs, except the pin driving 7seg cathode.
- Led segments are driven by AVR Pin pullups.
- In order to make the segments "shine", 7seg is configured with max. current = 0.01 mA, that is 10 uA.
- There is no delay betwen display changes, everything is just "free running" at maximum speed.

When I open the circuit and load the hex, it is working "OK" for me.
"OK" meaning it is working as described above.
There is an error though: it starts at 10 steps/second, but if I open Simulation Settings it shows 1 step/second.
The circuit files shows 10 stepsPS.

The animation is working "OK": it shows PORTC Pins going Output for the display that is driven and Input for the rest, as defined in the program.

The Logic Analizer is showing what is actually happening:
A voltage swinging around the Leds forward voltage: 2.4 V
An Oscilloscope is much better for this case.

One thing that can be confusing is that it takes 20 us to start driving the 7segs.
I think this is the time it needs to load the array in RAM.

But then... If I try to run it at 100%... then oh boy the pandora's box is actually open.
The GUI starts to get blocked...
If I use simulide compiled for "release" it works in my machine.
But in "debug" mode (which is much slower), the GUI gets completely blocked.
If I try slower speeds there is a point when it doesn't block 100%, but it gets very slow and doesn't refresh until you zoom or change focus.
This "state" last even if the simulation is stopped.

In conclussion:
The way this circuit is working:
- Leds floating: these are non-linear and very unstable in those conditions, so can use lots of cpu.
- Ports changing at maximum speed.
- Changes in Ports are done in pullups or direcction (the most cpu intensive).
- Using a Logic Analizer also adds lots of cpu load (this needs optimization).

Is overloading the simulation to a point that it's blocking the GUI....
And that is not easy, but this depends on the capabilities of the computer.

This circuit is the perfect "stress test" for the simulator.
I'm working in some solutions to make the GUI really unblockable...

The cofiguration as input was my fault. Initially the students used DDRB and DDRD correctly. But even with DDRB = 0xFF and DDRD = 0xFF the circuit behaves unusual: the simulation crashes for "normal" speeds

It initially started with a program like the following, where an interrupt is initiating the refresh. This is not as ugly (and ugly behaving) as the first code and works also with the diodes in the linear range and higher currents.

Code:


 uint8_t numberToOutput = 0;
 uint8_t sevenSegmentPos = 0;


int main()
{
 TCCR0A  = 0; // Timer 0 auf "Normal Mode" schalten
 SET_BIT(TCCR0B,CS10); // mit Prescaler 8 betreiben
 SET_BIT(TIMSK0,TOIE0); // Overflow-Interrpt aktivieren

 DDRD=0xff;
 DDRB=0xff;
 
 sei();
 
 while(1)
 {
 if (flag)
 {
 flag=0;
 numberToOutput = sevenSegmentPos;

 PORTD = 0;
 PORTB = 0;
 
 DDRC  = sevenSegmentOutput[2][sevenSegmentPos]; // sets used Common Cathode
 PORTD = sevenSegmentOutput[0][numberToOutput];  // PORTD and PORTB writes a..g of 7-Segment-Display
 PORTB = sevenSegmentOutput[1][numberToOutput];  //
 
 if (++sevenSegmentPos > 3) sevenSegmentPos = 0;
 }
 }
 return 0;
}

ISR (TIMER0_OVF_vect)
{
 flag = 1;
}



The cofiguration as input was my fault. Initially the students used DDRB and DDRD correctly. But even with DDRB = 0xFF and DDRD = 0xFF the circuit behaves unusual: the simulation crashes for "normal" speeds

Yes, there are several problems.

- Simulation Setting has several errors.
I also think  that "Steps per second" should not be less than FPS.

- The GUI is blocking.
This causes the 7seg and LA don't update unless you force a redraw (zoom, change focus, etc.)
I think this is also the source of those crashes.
The weird part is that once it starts to fail, the GUI doesn't update any more unless you force it, even with simulation stopped.

I'm working in it, but can't find the origin yet.
This problem is in Qt main loop, so not easy to debug.
I have done a few optimizations in the animation and simulation engine, which is good.
Logic Analizer also needs optimization, I have some ideas,  will implement this later.
Still have a few things to try, hopefully one will solve the problem.

It initially started with a program like the following, where an interrupt is initiating the refresh. This is not as ugly (and ugly behaving) as the first code and works also with the diodes in the linear range and higher currents.

Indeed the "ugly" version is the good one to find the problem:
It stress the simulation much more and don't use Timers, ruling out Timers a a source of the problem.