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....

[wraper]

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...

So you are REQUIRED to read that, and if there is anything resembling, you MUST shut up and delete all what you wrote? Hint: while you read that, often 3 more posts will appear.

[sasa]

So you are REQUIRED to read that, and if there is anything resembling, you MUST shut up and delete all what you wrote? Hint: while you read that, often 3 more posts will appear.

Correct it at least, you did not wrote a novel! Certainly I did wrote that I do not know and your confirming was pointless, as the rest.

Please focus on subject, I do not have much time to argue about nonsense, except to focus on solution.

[sasa]

I use simavr with avr-gdb.

https://github.com/buserror/simavr

Alexander.

Thank you, Alexander.

This at least compiled without problems. The first example did not produce make VCD trace file.

Code: [Select]

./simavr/run_avr tests/atmega88_example.axf
Loaded 1722 .text at address 0x0
Loaded 114 .data
Loaded 4 .eeprom
Read from eeprom 0xdeadbeef -- should be 0xdeadbeef..
Read from eeprom 0xcafef00d -- should be 0xcafef00d..

Probably this version require using some options or similar, but at least commit in git repository is actually only few hours ago. If possible to simulate and capture at least UART, it would be good enough. Though, character LCD showing can be emulated is more than fine.

[andersm]

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
       ^~~~~~
"

Try defining _GLIBCXX_USE_CXX11_ABI to 0.

[sasa]

Try defining _GLIBCXX_USE_CXX11_ABI to 0.

Thank you. I have force compilation with, however, results are the same...

As far as I briefly searched for similar bugs, probably GCC version header/lib code conflicts and as such will probably compiled fine with 4.x or other than latest version (6.5). Anyway, regression is always a burden...

Only possible solution I see is to find DVDs with some old linux distro have older GCC and try to compile...
Regardless on results, I will put in TODO list to make my own AVR simulator from ground when free time allow...

Thank you again for suggestion.

[eugenenine]

I always though simulation was for while you wanted for the parts you ordered to arrive

Mainly i just wanted to tag the thread so I could download later

[westfw]

Only possible solution I see is to find DVDs with some old linux distro have older GCC and try to compile...
Regardless on results, I will put in TODO list to make my own AVR simulator from ground when free time allow...

It's gotta be easier to figure out what's wrong with the existing implementation that used to work, than to start from scratch.
Also, older versions of gcc are still available, and it's not difficult to have more than one version present on a system...

[legacy]

Also, older versions of gcc are still available, and it's not difficult to have more than one version present on a system...

it won't work
glibc, ecosystem
a lot of dependencies

[sasa]

It's gotta be easier to figure out what's wrong with the existing implementation that used to work, than to start from scratch.

Never is easier to drill through the mountain, than building on the clean flat surface...

If you are experience programmer, you would know that very well - digging through other source is sometime real nightmare. If you know how or better had experience with similar task, it is only matter of free time to make your own solution.

On linux that is particularly difficult as anyone use some specific libs and crash is inevitable in one moment...

Also, older versions of gcc are still available, and it's not difficult to have more than one version present on a system...

As already mentioned - that is not possible.

[dsl]

Hey, guys.

If there is still an interest in simulator for Atmel AVR 8-bits MCUs,
I'd like to suggest one: MCUSim (https://github.com/dsalychev/mcusim). It's
programmed in ANSI C under New BSD license and still in development, but
instruction set interpretator, MCU initialization, basic timers for ATmega8A,
GDB RSP interface and VCD dumps are there.

Personally, I compiled it under macOS, FreeBSD, NetBSD and
elementary OS (GNU/Linux) succsessfully. I'm working on this small project
(https://github.com/dsalychev/xling/blob/master/hardware/images/xling-0.1.12-render.png)
and using simulator to track any mistakes in two-wire interface of LCD display.

I'm spending my spare time on design and programming, and if you're
ready to help or suggest anything, please, feel free to ask.