Free AVR simultor on linux - Page 1
Forum section: electronics / general

author: sasa
author_rank: Regular Contributor
timestamp: September 15, 2017, 07:12:34 am
content: 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/SimulAVRAfter 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 accessstruct __xfer_bufptrs^~~~~~"

author: ataradov
author_rank: Super Contributor
timestamp: September 15, 2017, 07:21:44 am
content: Why? Real hardware is dirt cheap.

author: sasa
author_rank: Regular Contributor
timestamp: September 15, 2017, 07:30:33 am
content: Quote from: ataradov on September 15, 2017, 07:21:44 amExtensive 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...

author: ataradov
author_rank: Super Contributor
timestamp: September 15, 2017, 07:35:14 am
content: Quote from: sasa on September 15, 2017, 07:30:33 amMy 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.Quote from: sasa on September 15, 2017, 07:30:33 amRecommended 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.

author: sasa
author_rank: Regular Contributor
timestamp: September 15, 2017, 07:58:50 am
content: Quote from: ataradov on September 15, 2017, 07:35:14 amNo need for stimulus, what so ever. Anyway, good simulator will allow to prepare test cases...QuoteWith 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.Quote from: sasa on September 15, 2017, 07:30:33 amIIRC, 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.

author: ataradov
author_rank: Super Contributor
timestamp: September 15, 2017, 08:03:55 am
content: Quote from: sasa on September 15, 2017, 07:58:50 amThere 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.Quote from: sasa on September 15, 2017, 07:58:50 amI meant if you are debugging some thing purely algorithmic, then just compile the code fro PC using normal GCC.Quote from: sasa on September 15, 2017, 07:58:50 amI 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.Quote from: sasa on September 15, 2017, 07:58:50 amGuys 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.

author: rs20
author_rank: Super Contributor
timestamp: September 15, 2017, 08:06:37 am
content: The OP's request actually makes sense for at least one usecase: regression testing.

author: b_force
author_rank: Super Contributor
timestamp: September 15, 2017, 08:27:05 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: September 15, 2017, 08:29:21 am
content: Quote from: b_force on September 15, 2017, 08:27:05 amExcept for the part where you try to figure out why your massive code base does not work on a real hardware.

author: firewalker
author_rank: Super Contributor
timestamp: September 15, 2017, 08:32:11 am
content: I use simavr with avr-gdb.https://github.com/buserror/simavrAlexander.

author: legacy
author_rank: Super Contributor
timestamp: September 15, 2017, 08:33:26 am
content: Quote from: sasa on September 15, 2017, 07:58:50 amDO178 says it very clear: Test Cases are always based on input patterninput pattern[] = { software stimulus, hardware stimulus }input pattern ---> system.real ---> output.actualinput pattern ---> system.ideal ---> output.expectedcmp_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!

author: b_force
author_rank: Super Contributor
timestamp: September 15, 2017, 08:39:35 am
content: Quote from: ataradov on September 15, 2017, 08:29:21 amThan 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

author: legacy
author_rank: Super Contributor
timestamp: September 15, 2017, 08:45:01 am
content: 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 ramyou 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 stimulussoftware stimulus are injected by the jtag-like, while hardware stimulus are injected by fpgawe 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 failthere is also a big and heavy equipment which simulate a lot of avionics components, and how they can failanyway, I don't know about avr8

author: sasa
author_rank: Regular Contributor
timestamp: September 15, 2017, 09:01:43 am
content: Quote from: ataradov on September 15, 2017, 08:03:55 amIt 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.QuoteIf 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.QuoteSimple 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...

author: ataradov
author_rank: Super Contributor
timestamp: September 15, 2017, 09:05:29 am
content: Quote from: sasa on September 15, 2017, 09:01:43 amAs one is done another one starts.Quote from: sasa on September 15, 2017, 09:01:43 amIt 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.Quote from: sasa on September 15, 2017, 09:01:43 amWhy? There is no evidence that flash endurance is stretched in any way in those devices.

author: wraper
author_rank: Unknown
timestamp: September 15, 2017, 09:36:14 am
content: Quote from: b_force on September 15, 2017, 08:39:35 amIn 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.

author: sasa
author_rank: Regular Contributor
timestamp: September 15, 2017, 09:40:07 am
content: Quote from: ataradov on September 15, 2017, 09:05:29 amI 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.

author: ataradov
author_rank: Super Contributor
timestamp: September 15, 2017, 09:43:43 am
content: Quote from: sasa on September 15, 2017, 09:40:07 amIt is exactly the same. Debugger uses the same register to access NVM controller.Quote from: sasa on September 15, 2017, 09:40:07 amAll 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.

author: wraper
author_rank: Unknown
timestamp: September 15, 2017, 09:49:12 am
content: Quote from: sasa on September 15, 2017, 09:40:07 amYes you don't. Programming is done with voltage generated by internal converter and is much higher than 5V.QuoteThat is high voltage programming. Required only if fuses are screwed up. Does not affect endurance or anything.

author: b_force
author_rank: Super Contributor
timestamp: September 15, 2017, 09:49:26 am
content: Quote from: wraper on September 15, 2017, 09:36:14 amMm, 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?

author: wraper
author_rank: Unknown
timestamp: September 15, 2017, 10:02:26 am
content: 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.

author: sasa
author_rank: Regular Contributor
timestamp: September 15, 2017, 10:16:53 am
content: Quote from: wraper on September 15, 2017, 09:49:12 amI have wrote that I don't know and you confirm that, as well repeating the same already previous poster explain - well done!

author: sasa
author_rank: Regular Contributor
timestamp: September 15, 2017, 10:22:07 am
content: Quote from: ataradov on September 15, 2017, 09:43:43 amThank 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.

author: wraper
author_rank: Unknown
timestamp: September 15, 2017, 10:26:52 am
content: Quote from: sasa on September 15, 2017, 10:16:53 amHard to understand those posts were typed simultaneously?

author: sasa
author_rank: Regular Contributor
timestamp: September 15, 2017, 10:38:25 am
content: Quote from: wraper on September 15, 2017, 10:26:52 amHint: 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....

author: wraper
author_rank: Unknown
timestamp: September 15, 2017, 11:04:35 am
content: Quote from: sasa on September 15, 2017, 10:38:25 amSo 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.

author: sasa
author_rank: Regular Contributor
timestamp: September 15, 2017, 11:12:08 am
content: Quote from: wraper on September 15, 2017, 11:04:35 amCorrect 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.

author: sasa
author_rank: Regular Contributor
timestamp: September 15, 2017, 12:22:13 pm
content: Quote from: firewalker on September 15, 2017, 08:32:11 amThank you, Alexander.This at least compiled without problems. The first example did not produce make VCD trace file.Code:./simavr/run_avr tests/atmega88_example.axfLoaded 1722 .text at address 0x0Loaded 114 .dataLoaded 4 .eepromRead 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.

author: andersm
author_rank: Super Contributor
timestamp: September 15, 2017, 08:27:26 pm
content: Quote from: sasa on September 15, 2017, 07:12:34 amTry defining_GLIBCXX_USE_CXX11_ABIto 0.

author: sasa
author_rank: Regular Contributor
timestamp: September 18, 2017, 05:51:23 pm
content: Quote from: andersm on September 15, 2017, 08:27:26 pmThank 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.

author: eugenenine
author_rank: Frequent Contributor
timestamp: September 18, 2017, 05:59:22 pm
content: I always though simulation was for while you wanted for the parts you ordered to arriveMainly i just wanted to tag the thread so I could download later

author: westfw
author_rank: Super Contributor
timestamp: September 18, 2017, 07:36:44 pm
content: QuoteIt'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...

author: legacy
author_rank: Super Contributor
timestamp: September 18, 2017, 08:13:30 pm
content: Quote from: westfw on September 18, 2017, 07:36:44 pmit won't workglibc, ecosystema lot of dependencies

author: sasa
author_rank: Regular Contributor
timestamp: September 18, 2017, 09:37:48 pm
content: Quote from: westfw on September 18, 2017, 07:36:44 pmNever 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...QuoteAs already mentioned - that is not possible.

author: dsl
author_rank: Newbie
timestamp: February 23, 2018, 11:46:03 pm
content: 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'sprogrammed in ANSI C under New BSD license and still in development, butinstruction set interpretator, MCU initialization, basic timers for ATmega8A,GDB RSP interface and VCD dumps are there.Personally, I compiled it under macOS, FreeBSD, NetBSD andelementary 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'reready to help or suggest anything, please, feel free to ask.