Would you like to react to this message? Create an account in a few clicks or log in to continue.

You are not connected. Please login or register

Redesigning "Mcu Monitor".

3 posters

Go down  Message [Page 1 of 1]

1Redesigning "Mcu Monitor". Empty Redesigning "Mcu Monitor". Thu Aug 11, 2022 12:14 am

arcachofo

arcachofo

There are a few things in the current Mcu Monitor that are not convenient.
For example:
- You can't watch RAM, ROM and PGM at the same time.
- You can't watch internal Registers of the CPU (I can in 6502, but that is a hack).
- What happens with devices with no RAM ROM or PGM?

And there are other features that could be interesting:
- Add breakpoints at some PC value, RAM or ROM changes (in simulation mode, not in debugger mode).

So I'm thinking how to redesign it to solve these issues.
If you have some ideas please share here.


Related:
https://simulide.forumotion.com/t291-mcu-monitor-0-5-16



Last edited by arcachofo on Sat Oct 15, 2022 12:57 am; edited 2 times in total

Malsasa likes this post

2Redesigning "Mcu Monitor". Empty Re: Redesigning "Mcu Monitor". Sat Aug 13, 2022 7:30 am

vranik



My Z80CPU Monitor looks like in the pictrure. It looks ugly and needs a little bit tunning.
There are displayed flags, registers and internal states of the CPU. The buttons at the bottom are used for execution only one T state, one machine cycle or one instruction.
I would be nice to have possibility to set breakpoints to state of registers and state of bus with possibility to set counter how many times it is skipped.

Redesigning "Mcu Monitor". Screen23

3Redesigning "Mcu Monitor". Empty Re: Redesigning "Mcu Monitor". Sat Aug 13, 2022 10:11 pm

arcachofo

arcachofo

I already did some changes:

- Monitor only shows only what the device has.
- Added cpu registers.

Here is how it looks for 6502:

Redesigning "Mcu Monitor". Mon10

Other information could be added as variables (left lower part in the image above), like T State, Address Bus, Data Bus, etc (All info you show in the lower part).

The buttons at the bottom are used for execution only one T state, one machine cycle or one instruction.
I saw that in the source code and it is very interesting.
It could be used after breakpoint to step the cpu.
Also after Logic Analyzer "Pause on Condition" or just pausing simulation with pause button.

Being able to debug the cpu without the debugger is a very useful feature.
It could also be used with the debugger:
Run the debugger to certain point and then execute by small steps.

I'm thinking to add something like that in the white area at the right in the image above.

And... I think I know why your Monitor crashes (more on this and other Z80 stuff in the other discussion).

4Redesigning "Mcu Monitor". Empty Re: Redesigning "Mcu Monitor". Wed Sep 14, 2022 12:57 am

TimFisch

TimFisch

  • separate windows for RAM, ROM and PGM would be great
  • It would be great to be able to read in map / lss files ¬†Redesigning "Mcu Monitor". 1f600
    e.g. for reading out variables similar to registers


BTW: what is the "CPU" tab in the Mcu Monitor for?

https://wiki.mexle.hs-heilbronn.de/

5Redesigning "Mcu Monitor". Empty Re: Redesigning "Mcu Monitor". Wed Sep 14, 2022 1:24 am

arcachofo

arcachofo

It would be great to be able to read in map / lss files  Redesigning "Mcu Monitor". 1f600
e.g. for reading out variables similar to registers
Something like that is already implemented for avr-gcc.
Detected (global) variables are automatically added to a list below registers (if you compile in simulide):
https://simulide.forumotion.com/t605-debugger-and-variables

Redesigning "Mcu Monitor". Vars11

BTW: what is the "CPU" tab in the Mcu Monitor for?
To show any information about the CPU itself: internal registers, internal states or any other information.

6Redesigning "Mcu Monitor". Empty Re: Redesigning "Mcu Monitor". Wed Sep 14, 2022 9:39 am

TimFisch

TimFisch

That's great. It would be good to have this also for the case hex made by external IDEs (e.g. MPLAB X for PIC / AVR).

https://wiki.mexle.hs-heilbronn.de/

7Redesigning "Mcu Monitor". Empty Re: Redesigning "Mcu Monitor". Wed Sep 14, 2022 9:38 pm

arcachofo

arcachofo

That's great. It would be good to have this also for the case hex made by external IDEs (e.g. MPLAB X for PIC / AVR).
The question is how to get the information.
When you compile in simulide the toolchain is known, which files are generated from which sources are known, etc.
From an hex file you know nothing.

lss or map files can have some information about variables or not.
And the formats are different for each compiler, so there is no generic way to find that info if it even exist.

The debugger gets information to map PGM addresses to source lines from list files, but this is much easier, and in any case some information must be provided in the compiler definition file in order to know what kind of list file it is.

Variables are not that easy, but if somebody knows a method to do it let me know.

8Redesigning "Mcu Monitor". Empty Re: Redesigning "Mcu Monitor". Sat Oct 15, 2022 12:40 am

arcachofo

arcachofo

From: https://simulide.forumotion.com/t390p150-simulide-1-0-0-tester-builds#4830

KerimF wrote:[1]
Saving the look of the MCU Monitor with its circuit.
For example, the RAM/SRAM table could be seen, therefore, as it was set (displayed) in the previous session.

[2]
Changing, on the MCU Monitor and in a convenient way, the displayed values DEC to HEX or HEX to DEC (instead of adding another column). This option eases, when necessary, the comparison between a hex value of a byte on the RAM table (mid panel) with one on the SRAM table (right panel).

I think monitoring the SRAM bytes (defined as single bytes only, not of an array) also by their defined names is not easy to implement, at least for the time being.

Sponsored content



Back to top  Message [Page 1 of 1]

Permissions in this forum:
You cannot reply to topics in this forum