Free AVR simultor on linux

[sasa]

I wonder anyone is aware of free and stable AVR (ATmega 328p, at least) simulator which actually work?
If not existed, I would certainly make my own from ground, however currently I have no much free time...

Follows some failure attempts to find suitable one:

Simuino-0.1.8 at least have executable, however after load provided HelloWorld example it actually hangs or return some error.

I have ended up with a fork of simulavr, as original one seems to be abandon:
http://reprap.org/wiki/SimulAVR

After several more missing libs it actually starts to compile and after long time end with strange error:
"
In file included from gtest-1.6.0/include/gtest/internal/gtest-port.h:197:0,
                 from gtest-1.6.0/include/gtest/internal/gtest-internal.h:40,
                 from gtest-1.6.0/include/gtest/gtest.h:57,
                 from session_001/unittest001.cpp:4:
/usr/include/c++/6/sstream:300:7: error: ‘struct std::__cxx11::basic_stringbuf<_CharT, _Traits, _Alloc>::__xfer_bufptrs’ redeclared with different access
       struct __xfer_bufptrs
       ^~~~~~
"

[ataradov]

Why? Real hardware is dirt cheap.

[sasa]

Why? Real hardware is dirt cheap.

Extensive testing purposes. It is rater a PITA for every single change to compile, upload, execute...

Actually, before any update it is recommended to wait few minutes in order to follow recommendation to retain even nearly 10 000 Erase/Write cycles in programming memory...

[ataradov]

Extensive testing purposes. It is rater a PITA for every single change to compile, upload, execute...

My development style must be different. Uploading was never the factor. With simulator you will spend a lot of time trying to create input stimulus.

And if you are debugging something that does not depend on inputs - debug it on PC first.

Actually, before any update it is recommended to wait few minutes in order to follow recommendation to retain even nearly 10 000 Erase/Write cycles in programming memory...

Recommended where? Actual flash endurance is way-way higher and there is absolutely no requirement to have any delays between writes.

And even if you reach this limit (which is pretty much impossible) - just throw away the chip, and get a new one.

[sasa]

My development style must be different. Uploading was never the factor. With simulator you will spend a lot of time trying to create input stimulus.

No need for stimulus, what so ever. Anyway, good simulator will allow to prepare test cases...

And if you are debugging something that does not depend on inputs - debug it on PC first.

With what software on linux? Atmel studio7 is available only for windows (probably will fail even to run through wine on linux), except I may end up with GCC AVR debugger  Anyway, I do not need debugging, only speed testings.

Recommended where? Actual flash endurance is way-way higher and there is absolutely no requirement to have any delays between writes.

IIRC, this was recommended in any 8-bit PICs datasheet - I have actually asked once Microchip technical support exactly about. Atmel probably have no much different technology. After acquiring, perhaps that limit will gone as well for new PICs?

Have you ever tried to repeatedly flash an AVR? That is actually not bad idea to establish safety boundaries.

[ataradov]

No need for stimulus, what so ever. Anyway, good simulator will allow to prepare test cases...

There is a need if your program takes any inputs. I rally don't understand how it is possible to test anything using a fixed set of inputs.

With what software on linux? Atmel studio7 is available only for windows (probably will fail even to run through wine on linux), except I may en up with GCC AVR debugger  Anyway, I do not need debugging, only speed testings.

I meant if you are debugging some thing purely algorithmic, then just compile the code fro PC using normal GCC.

IIRC, this was recommended in any 8-bit PICs datasheet

I would actually need to see this for myself to believe. This makes no sense at all. Flash does not remember how long ago it was written.

Have you ever tried to repeatedly flash an AVR? That is actually not bad idea to establish safety boundaries.

Guys in Norway did unofficial tests long time - under a normal power supply and at room temperature it was more than 100 000. The write was performed from inside the device, since it would take forever to do that over the debugger.

[rs20]

The OP's request actually makes sense for at least one usecase: regression testing.

[b_force]

I have seen professional (paid) software that could simulate these types of things.
The problem is mostly the simulation speed(s) and optimization.

And yes, I do really see benefits in only simulating stuff.
Especially when you're working remote or are on the road a lot.
But it some cases it just makes the workflow much quicker, instead of uploading the whole code every time for just some small changes.

[ataradov]

But it some cases it just makes the workflow much quicker

Except for the part where you try to figure out why your massive code base does not work on a real hardware.

[firewalker]

I use simavr with avr-gdb.

https://github.com/buserror/simavr

Alexander.

[legacy]

No need for stimulus, what so ever. Anyway, good simulator will allow to prepare test cases...

DO178 says it very clear: Test Cases are always based on input pattern

input pattern[] = { software stimulus, hardware stimulus }

input pattern ---> system.real ---> output.actual
input pattern ---> system.ideal ---> output.expected

cmp_if_equal(output.actual, output.expected) => test_case(i).result.is[]={ success, failure }

test_case(i).result.is='falure' ~> ops, we have encountered a bug! hAllo mr.Bug! 

[b_force]

But it some cases it just makes the workflow much quicker

Except for the part where you try to figure out why your massive code base does not work on a real hardware.

Than you're simulating wrong.
Simulating is for proof of concept, in the end you always need to tweak in real life circuits.
Although the programming flow (and digital part) is going to be the same.
It's mostly the 'analog' part that goes wrong.

Proteus can simulating these things very well actually, but is not free

[legacy]

here at work we have a special board PCI-shaped made with a part of the flyboard (usually a PPC440/460 + external fpga) attached to a dual port ram

you can inject the code into the MPU ram through the PCI @ 100Mbyte/sec, and you can take the control of the board through a sort of jtag (it's more complex and faster, but basically it's like jtag)

there is also an fpga attached to the I/O of the board to simulate hardware stimulus

software stimulus are injected by the jtag-like, while hardware stimulus are injected by fpga

we usually use to launch a long set of test-cases which are required to be checked, and it's also useful on regression when we do some system integration and things start to fail

there is also a big and heavy equipment which simulate a lot of avionics components, and how they can fail

anyway, I don't know about avr8 

[sasa]

There is a need if your program takes any inputs. I rally don't understand how it is possible to test anything using a fixed set of inputs.

It does not, it prepare it itself - that is test case firmware. I actually hit the wall with pure C optimization and some functions I changing with pure hand-written ASM code (as I asked in one of my recent thread).

As I extensively testing effect of the change on each substitute and if needed change few instructions, using simulator have full sense for me to actually prove it is faster and output the same.

I would actually need to see this for myself to believe. This makes no sense at all. Flash does not remember how long ago it was written.

If you want, I will try to find that old ticket I submit on Microchip support for you and as well what exact PIC datasheet was related.

Guys in Norway did unofficial tests long time - under a normal power supply and at room temperature it was more than 100 000. The write was performed from inside the device, since it would take forever to do that over the debugger.

Simple enough automatic testing for self-programmed MCU, just need to rewrite specific blocks of programing memory in desired frequency rate and check...

Do you remember what rewriting frequency was? For self-programmed MCU as 328p is, would be possible to measure even us resolution (depending what is recommended time between write and read). And that is supposed for 100 000 E/W MCU? The ATmega 328p have specified only 10 000 E/W cycles endurance.

I doubt 328p would live much...

[ataradov]

Do you remember what rewriting frequency was?

As one is done another one starts.

And that is supposed for 100 000 E/W MCU? The ATmega 328p have specified only 10 000 E/W cycles endurance.

It was one of the AVRs, I don't know which.

10 000 is for all temperatures, supply voltages and process variations + huge margin. It will probably degrade somewhat with process improvement, but even m328 will live way longer than 10 000 E/W cycles.

Datasheet numbers have really big margins in them. I ran Cortex-M0+ that is specified as 48 MHz, at 88 MHz without any immediately obvious failures.

I doubt 328p would live much...

Why? There is no evidence that flash endurance is stretched in any way in those devices.

[wraper]

It's mostly the 'analog' part that goes wrong.

Proteus can simulating these things very well actually, but is not free

In the past I decided to never use Proteus for MCU simulation. Wasting hours finding why you get some weird issue just to find it is some sort of bug in MCU simulation, and it worked perfectly on real MCU to start with. Happened several times on different projects. This happened to the point where issue was not even related to peripherals. Last time it was doing calculations wrong, then I decided enough is enough.

[sasa]

Why? There is no evidence that flash endurance is stretched in any way in those devices.

I can't comment that deeper, as I do not know exact hardware based self-programming process.

However, with standard flashing with a programmer, you have to provide 13V, which is way too much than 5V, then temperature of the whole programming memory (or device itself) may be much higher than in self-programming mode and that may be primary reason for some time to cool down, otherwise constant flashing will  retaining high temp and degrade it much faster...

Anyway, that may be total rubbish I wrote, as I already wrote, as I really don't know exactly how flashing process work under hood, a well as self-programming.

[ataradov]

I can't comment that deeper, a I do not know exact hardware based self-programming process exactly.

It is exactly the same. Debugger uses the same register to access NVM controller.

However, with standard flashing with a programmer, you have to provide 13V, which is way too much than 5V,

All AVRs have internal charge-pump for that, and temperature does not increase that much. I mean maybe really old PICs were that bad, but definitely nothing designed in the last 10 years suffers from such problems.

[wraper]

Anyway, that may be total rubbish I wrote, as I already wrote, as I really don't know exactly how flashing process work under hood, a well as self-programming.

Yes you don't. Programming is done with voltage generated by internal converter and is much higher than 5V.

However, with standard flashing with a programmer, you have to provide 13V

That is high voltage programming. Required only if fuses are screwed up. Does not affect endurance or anything.

[b_force]

It's mostly the 'analog' part that goes wrong.

Proteus can simulating these things very well actually, but is not free

In the past I decided to never use Proteus for MCU simulation. Wasting hours finding why you get some weird issue just to find it is some sort of bug in MCU simulation, and it worked perfectly on real MCU to start with. Happened several times on different projects. This happened to the point where issue was not even related to peripherals. Last time it was doing calculations wrong, then I decided enough is enough.

Mm, yeah, that's not very good at all.
Personally haven't had these issues.
Can you share what type of projects/things you were doing?

[wraper]

I don't know if it was fixed, as it was quiet a time ago. IIRC those problems happened with atmega8 and atmega2313. But it was enough to loose any trust. Also it had bugs in some 74 series logic ICs.

[sasa]

Anyway, that may be total rubbish I wrote, as I already wrote, as I really don't know exactly how flashing process work under hood, a well as self-programming.

Yes you don't. Programming is done with voltage generated by internal converter and is much higher than 5V.

I have wrote that  I don't know and you confirm that, as well repeating the same already previous poster explain - well done! 

[sasa]

All AVRs have internal charge-pump for that, and temperature does not increase that much. I mean maybe really old PICs were that bad, but definitely nothing designed in the last 10 years suffers from such problems.

Thank you for explanation. And you are probably right for old devices, I have started with PIC16f84A/628A and PIC18F887, probably in one of these datasheets I have read such requirement.

[wraper]

as well repeating the same already previous poster explain - well done! 

Hard to understand those posts were typed simultaneously? 

[sasa]

Hard to understand those posts were typed simultaneously? 

Hint: When other post before you, the forum engine will notify you and instead to allow you to send your post, it will list few latest post...

But you already knew that. Please focus on the subject, though. I haven't near to solution a bit....