AVR Freaks

Update: 8-bit timer support.

Timer0 is now working (timer1, timer2 will follow). Currently only normal mode is available. Timer overflow (TOV0) plus interrupt works fine too. The overflow frequency seems to be accurate.

Supported Prescaler: 1/8/64/256/1024
External clock source: Currently not implemented.

CTC, PWM, etc. will follow. More details at https://github.com/Milo-D/MDX-Assembly-Debugger/releases

Yeah you are right, but I've rewritten the whole program so the old thread contains a lot of outdatet information. I would delete the old post but I can not.

Done. Thank you :)

Update (v.0.5.0)

- Performance: Reached 17 MHz execution speed. It is now possible to simulate default Arduino in realtime.

- Added: Analyzer Module.
    - The Analyzer Module consists of multiple (future) submodules.
    - Each submodule will be covering exactly one aspect of static code analysis.
    - Planned submodules:
        - ISR analysis (explore details about ISRs in your code)
        - SFR analysis (annotate addresses which target special function registers)
        - Function analysis (analyse function calls and maybe even their arguments/return-values)
        - many more...
    - The analyzer is a work in progress

- Refactor of toplevel structures
    - table_t class is now only for user-defined entries like breakpoints, etc.
    - system_t class does not contain table_t class anymore.
    - report_t class is the report of the analyzer after decoding and disassembling hexfile.

- Displaying hexadecimal addresses instead of line numbers in sidepanel.
- Table commands (like break, unbreak) are now requiring a hexadecimal address

- Added: Diagram of the analyzer dataflow
- Added: New screenshot

- DebugWindow Refactor (II)
    - panel properties are now calculated seperately in <g,s,f,d,e,o,r> pnl_ctor

Thank you for your feedback :) Next step would be to reach 20 MHz and reduce the total memory usage.

I am planning to implement the m328(p) first, then its family (16, 8). Implementing other AVRs might take a while, but maybe I will get some help ;)

17 MHz without using peripherals, but they do not affect execution speed too much. Maybe I could test the execution speed while having peripherals activated.

So yeah, there is definetely room for improvement.

Only 20 Cycles to simulate an instruction could be a tough challenge.

The virtual system is structured like a tree of submodules. So a system access has to be redirected to its corresponding submodule.

For example writing to an IO register triggers sys_write_data(...) -> data_write(...) -> io_write(...). Then the access information (whether it was a write or read access) has to be stored (so that it can be colorized later).

So there is unnecessary overhead but this helps keeping the codebase clean and structured.

I have already some ideas to boost the execution speed a little bit more. But for now there are other spots I want to improve and work on.

Thank you for your feedback :)

I am quiet sure that a much higher execution speed is possible. Hopefully I don't have to mess with the code structure too much. I am always trying to keep a balance between performance and architecture.

One thing I could do to improve the performance is to preprocess opcodes and extract every operand and store it in a struct. Currently I am extracting operands whenever executing an instruction even if it was already executed before. So that might boost the performance too.

Offtopic: Currently I am working on some submodules for the analyzer. Every submodule should cover exactly one aspect of static code analysis, for example a submodule that analyzes labels and its callers/callees. If you guys have some more ideas regarding future submodules, please let me know. I would be happy to work on them :)

GUI is the single thing in my project I don't like to work on ^^ so I am really not a fan of UI development :)

Do you mean gdb ? Isn't it core only simulation (without peripherals) ?

Really interesting suggestions. I really like them ^^ Especially the idea to analyze ISR cycles. I will add your ideas to my "list".

Thank you for your suggestions ;)

Yep you're right, thanks. ' ==' might be better here.

Thank you ccrause ^^

Update (v.0.7.0)

-> Reached 20 MHz simulation speed.

-> I don't like to work on user interfaces so I kicked out the GUI. MDX is now a library for static and dynamic analysis of AVR binaries, called libvmcu. I want to focus purely on the engine.

The library can be statically linked and its potential usecases are:

    - creating (regression) tests for embedded systems in order to validate functionalities

    - binary analysis of AVR programs

    - other people can create tools out of it, like simulators (probably even with a much better UI than MDX)

Library Features:

    - static analysis (find potential labels and their jumpers/callers, find SFRs, filter instructions, analyze operands, etc.)

    - dynamic analysis (cycle accurate realtime simulation of the ATmega328 family including peripherals and backstepping)

    - decoding intel hex (more formats are coming soon), disassembling, decomposing and analyzing

    - easy to use

Future Plans:

    - codeflow graph

    - decompiler

    - cycle analysis, ISR analysis, etc.

    - bindings for python

I would appreciate feedback, since this is the only way to develop an user-friendly library ^^

New link: https://github.com/Milo-D/libvmc...

What happens to MDX ?

MDX will be moved to another repository. It will be open for PRs, but personally I have no further interest in developing UIs (especially not with ncurses lol).

Update (v.0.7.1)

-> Added Java Bindings (thanks to pointbazaar) for libvmcu. Java bindings support

    - microcontroller simulation

    - static analysis of binary files (intel hex)

-> Added an example of a possible firmware unit test with libvmcu (driver/led/)

    - driver/led/ledtest.c is using libvmcu to verify interrupt frequency of timer0 on the ATmega328P

#define PORTB     0x0025
#define PB5       0x05

#define TESTFILE  "../../driver/led/led.hex"

#define bit(v, b) ((v & (1 << b)) >> b)

int main(const int argc, const char **argv) {

    uint8_t led;

    /* ignoring checks for this example */
    vmcu_report_t *report = vmcu_analyze_ihex(TESTFILE);
    vmcu_system_t *sys    = vmcu_system_ctor(report);

    do {

        vmcu_system_step(sys);
        led = vmcu_system_read_data(sys, PORTB);

    } while(bit(led, PB5) == 0x00);

    const double f    = 16000000U;
    const double c    = sys->cycles;
    const double time = (c / f);

    printf("Time between LED toggle: %lf [s]\n", time);
    assert((0.95 <= time) && (time <= 1.05));

    vmcu_report_dtor(report);
    vmcu_system_dtor(sys);

    return EXIT_SUCCESS;
}

// Time between LED toggle: 1.000021 [s]
// Expected Result: 0.95 [s] <= time <= 1.05 [s]

-> Added option to build libvmcu as a dynamic library