HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
buserror
simavr
C2014–2025
buserror / simavr

simavr

simavr is a lean, mean and hackable AVR simulator for linux & OSX

Developer ToolsSystems & InfrastructureHardware & Embedded
Explore on GitHubRead Hacker News discussions
2Distinct people
17Mentions
1Explicit recommenders
1.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

simavr is a lean, mean and hackable AVR simulator for linux & OSX

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

I do use it as interpreter on embedded boards! Preprocess/trim the headers you need, and add #!/bin/tcc -run at the top of your .C file, add a +x to it and it'll run just fine!…

buserror used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year17 dated mentions

Observed mentions: 2014-12-29 11:22:18 UTC to 2025-10-07 13:24:43 UTC.

0123452014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC101
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC101
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC404
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC505
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

What Hacker News says

17 sources
buserror·Jun 6, 2024
Haven't played with these yet, but they do look interesting. Might have also to add support for the new IO blocks in my AVR simulator simavr[0] -- I still use the AVR a lot, since they have no pipeline and other fancy CPU optimization, they are 'cycle accurate' and are a lot closer to a PIO than most other more complex 32 bit CPUs.. Now that they ALSO have an equivalent to PIO it might even help with reaching faster IO speed when toggling pins. [0]: https://github.com/buserror/simavr
In PSA: If you're a fan of ATmega, try AVR Dx
buserror·Jan 3, 2024
I wrote my own pet Apple IIe emulator for linux fairly recently [0]. It works fairly well, even if it doesn't try to emulate an exact cycle accurate 'pixel' video modes, instead, it 'cheats' and do it line by line. I think it is a good tradeoff between quality of emulation and CPU spent doing it... Only some demos will fail to display properly (mostly the ones changing video mode during line displays!), all the games and tools and applications I tried works just fine. I mostly did my emu due to the rather poor quality I found for linux emulators I've seen, the 'goto' one is linapple, but the codebase is rather crusty.. I wanted a cleaner base to hack on, without the baggage -- more in the style of my own AVR emulator [1]. I've got a very big patchset to push 'soon' with a new UI library (that will be a topic of its own!) and a bunch of ne
Read the rest
w features and improvements... [0]: https://github.com/buserror/mii_emu [1]: https://github.com/buserror/simavr
In Apple II Emulation Evaluation (2022)
buserror·Dec 31, 2019
I'm rarely keen on posting negatives on articles that clearly took a lot of time to make, but I think this requires a bit of correction. I think this article is very, very simplistic. All of it relates to a 8 bits CPU that is 40+ years old. I switched to HLL as soon as I could get my hand on a compiler, namely, UCSD Pascal at the time! Then the Pascal, then to C and then myriads of other languages. I covered 6502, Z80, 68k (all of them, to 68040), PowerPC (all of them from 601 prototypes to G5s), ARMs (more than I can count) and x86s (same). True to be told, the assembly language I started with /helped a LOT/ with be becoming an efficient developer; a developer who understand what 'code' is being generated when he writes an expression, a statement, a loop, and one who understands what the runtime implication are for most of the 'sugar coa
Read the rest
ting' HLL gives. However, starting (a bit) with the 68k, then even more so with the PowerPC, it became pretty much impossible to write /from scratch/ an assembly equivalent that was QUICKER than the compiler generated code. That was 20+ years ago. DRAM latency happened, pipelining happened and SIMD happened. Today, hand writing assembly is pretty much stupid on modern CPUs. Given the register files, timings, shadow registers, bus latencies etc etc the compiler will ALWAYS be better because there is so much criteria to think about when generating code... I'm not saying that having the knowledge is not useful; the best use of assembly is to write some code il HLL, one that is supposed to be super-mega-critical-quick, then disassemble it and see how it looks. More often then not, you can't make it better than it is in situ -- most of the time you will gain is to prepare your data better, align it better etc etc -- basically, 'hinting' the compiler to do a better job. You can do serious code butchery like that, without a hint of assembler [0]. But really, I haven't written any assembly for /performance reasons/ in 15 years, and that was Altivec on PowerPC. For 8 bits, it's all smooth as butter, but the article also doesn't take into account the massive progress in compilers; I'm the author of SimAVR [1] and I've seen my load of generated code for that CPU, and the GCC toolchain is /very hard to beat/ by hand these days. [0]: critical audio loop on one of my old PCI card driver, converting float<->int, applying gain etc while using the register file to the max, and making most use of the pipelining of the G4 (at the time) https://gist.github.com/buserror/0a3a69cca927b8da6c9c7ee1605... -- note, the inner loop was generated by a script that was doing the cycle calculations (!) [1]: https://github.com/buserror/simavr
In Assembly Language Programming: Still Relevant Today (2015)
buserror·May 30, 2018
I also think that the committee is out of touch. C99 was an awesome improvement on the language, and since then, it went downhill. We don't need the extra weird C11 syntax things, duplicating of existing libraries; we want tools that scope C better, or extensions that have been proven helpful and stable (one such example is the switch(x) { case A...B: } from gcc!). I want strict boundary checking, I want an array base type that can't be cast as a pointer. I want some sort of scoping mechanism (ie, blocks), I want a bit of standardisation of memory barrier and such. I want #pragma once FFS -- it was proven a good idea for 25 years. Basically there's tons of stuff that could help make the language better -- C99 did that; C99 is a masterpiece for example on how you can statically initialise extremely complex data into a single block, without
Read the rest
having to use code. It's used all over the Linux kernel (amongst other thing; for example my own simavr is heavily based on that feature [0]). * Standardise the stupid bit order in bitfield declaration FFS. I've been wanting to use that feature for 30 years and I can't because they 'forgot' to make up their mind! * Coroutine standardisation would be awesome (stack swap primitives, with boundary checks etc).... * gcc 'sub functions' (or a derivative) would be awesome if improved to make them safe. * Reference counted allocator (basically, get libtalloc and roll it in [1]) There are so many things that could be improved, without diverging into weird stuff nobody needs (complex math anyone??!?!). * In fact I want SIMD. I don't need these complex types. [0]: https://github.com/buserror/simavr/blob/master/simavr/cores/... [1]: https://talloc.samba.org/talloc/doc/html/index.html
In Depressing and faintly terrifying days for the C standard [pdf]
buserror·Sep 18, 2017
I'm a huge fan of tcc. I use it on embedded systems -- a good trick is to pre-process any headers you need via cpp preprocessor, 'compress' them in a single file, and add your .c to that. That way you don't need to cart around all the -dev packages etc. The 'hidden gem' of tcc is libtcc (the backend), which you can use as a JIT subsystem in your own code. For example I've written a full JIT translator for simavr [0] like that. The code translates each AVR opcode into it's own little piece of C, then compile the whole 'firmware' and runs it. [0]: https://github.com/buserror/simavr/tree/wip/jit
In TCC – Tiny C Compiler
buserror·May 4, 2017
I tend to agree, up to a point, however I still use the GPL because it at least gives me a leg to stand on for people actually ripping your code and selling it as is... (What I call the packagers) I'm sure that if Linux wasn't GPL, you'd have 'vendors' selling 'HP Linux' and 'Corp Linux' to their locked in customers in no time at all. The only reason Linux grew up to this point is that the vendors are forced to contribute back and cooperate (up to a point). Mind you it might also be the reason Linux is so bloated these days, but at least there is no vendor lock in... As a small example, someone decided a few years back to release a "Arduino UI" over my own simavr[0] as an indigogo project. ie trying to be paid to package a demo I made (for free): he had screenshots, a few promises and no source code. I managed to email the guy telling him
Read the rest
I wanted to see the source code of the whole lot and somehow, the project fizzed out. If my project had been BSD, I might have seen someone making money from my project and associate my name with something that I had zero control on. When I give a project away, I want it to stay free for use, and I really hate to see 'packagers' who don't contribute anything at all move over and try to monetize it. Same story as when I released freewares a few years back, I had a note saying it was NOT ok to package it on 'CDs' sold around. [0]: https://github.com/buserror/simavr
In Is the GPL Really Declining?
buserror·Feb 28, 2017Recommendation phrase
I do use it as interpreter on embedded boards! Preprocess/trim the headers you need, and add #!/bin/tcc -run at the top of your .C file, add a +x to it and it'll run just fine! I love tcc, in fact I added a firmware instruction translator to 'JIT' AVR code to simavr a few weeks ago. Takes a AVR binary, translates it to C, and compiles it on the fly with libtcc to run it :-) https://github.com/buserror/simavr/tree/jit-wip
In Let's compile like it's 1992 (2014)
buserror·Feb 22, 2017
I'm a huge fan of simulations, I don't think you can develop a 'good' embedded system without it. My way of implementing something embedded is: * Develop a capture program for the input feed/sensors, and capture as much as you can. * Develop a software model to recreate the input for a 'target' embedded system * Write the embedded system against the captured input. That will get you 95% there. * Run it 'live', check anything wrong (you will). Usual debugging & tweaks. * Do a feedback loop if problem input comes in, and keep /that/ preciously for your test unit sequence. * Once software is done, every time you make a change, run your simulator with all the test input you have and check your output for divergence. I very, VERY rarely need to JTAG into a board, I'd rather spend the time on the simulation model and get it accurate as I can th
Read the rest
an spend time 'debugging' on the target. That's why I wrote simavr for example [0], but I also use qemu lot for bigger systems. Unfortunately it's next to impossible to get anything upstream in qemu, so most of the work there just is dropped eventually [1]. [0]: https://github.com/buserror/simavr [1]: https://github.com/buserror/qemu-buserror
In What Are the Tricky Parts of Embedded Development?
buserror·Feb 2, 2017
Yes it's strange, it's one of the reason I stopped using C++ as a matter of fact. Given the innate amount of code required in C++ constructor to initialize objects, you'd think that would be very handy. BTW, shameless plug, but my own simavr uses these C99 features as more or less the whole basic structure on how multiple cores are described, see a sample core declaration [0] for example. The beauty is that there is no code involved in the declaration, it'll be 'const' too. Imagine the boilerplate you'd need to do that in C++! [0]: https://github.com/buserror/simavr/blob/master/simavr/cores/...
In St – A simple terminal implementation for X
buserror·Jan 20, 2016
Well there still is a case for the AVR -- you get zero pipelining effects, no flash latency etc; it's like a tiny, slow, scalar CPLD for all intent and purpose. Cortex can't beat that, you can tight loop an AVR to cycle precision and get pretty cool return for your running frequency; the Cortex are nowhere as linear. [0] Altho, I agree that the bigger parts are useless... xmegas and such have absolutely no reason to exist IMO. On the other hand the CM3 and especially M4's are awesome beast; and the parts like the STM32's are just peerless in terms of features -- they are just borderline scary. On the other hand, I was worried a little while back that there was nothing between these trusted 8 bits cores and the ARMs -- but nowadays there is; Espressif esp8266 is pretty cool, but the next one in the pipeline is awesome [1]; 2 (well 3 but) c
Read the rest
ores, and more peripherals than you can shake a stick at. Thats the first SoC that for me can give the STM32 (and NXP equivalent) a good run for their money (and win, in my opinion). Dislaimer: [0] I know the AVR very well, I'm the author of simavr: http://github.com/buserror/simavr -- [1] I'm also one of the beta tester for the ESP31/32 new chipset.
In Microchip to Acquire Atmel for $3.56B

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.