search

hoglet67 / AtomBusMon

This project is an open-source In-Circuit Emulator for the 6502, 65C02, Z80, 6809 and 6809E 8-bit processors. See:
https://github.com/hoglet67/AtomBusMon/wiki
GNU General Public License v3.0
99 stars 21 forks source link

Commands Optimized for Programmatic Execution #21

Closed jessaskey closed 3 years ago

jessaskey commented 3 years ago

Hi Dave... Im writing Window's based software that will do a bunch of automation in regards to scripting out a 'hardware test map' for a user defined platforms using your ICE projects. So if you envision the steps required to maybe do the following..

Test RAM from 0x000-01FF - maybe test all patterns SET RAM Page 1(via memory write to 0x1740 of 0) Test RAM from 0x0200-07FF SET RAM Page 1 (via memory write to 0x1740 of 1) Test RAM from 0x0200-07FF Test RAM from 0x0800-09FF Test Paged ROM similar to above (8 pages from 0x2000-0x3FFF) - match a preconfigured checksum Test RAM from 0x4000-4FFF Test ROM from 0x5000-5FFF - match a preconfigured checksum Test Paged ROM similar to above (4 pages from 0x6000-7FFF) - match a preconfigured checksum Test ROM from 0x8000-BFFF - match a preconfigured checksum Test ROM from 0xC000-FFFF - match a preconfigured checksum

I'm batching a straight PASS/FAIL and the basic concept is that both the commands and return values need to be easy to read from a programmatic standpoint. It certainly isn't the end of world to parse this out, but it certainly will be error prone over time.

So for example... right now, upon start, I need to run the 'help' command to identify connectivity and get the CPU Identifier string (and then ignore all the rest). Or if I want to read the Version of the firmware, I need to run 'help' and then parse out through string regex the version number in the middle of the response.

The next example which is simpler, but still illustrates a point is the 'crc' command which I just need to skip out the leading 'crc: ' from the 4 digit hex value.

With all of that, I wanted to ask a couple questions to make sure that if Im doing work, that Im in line with your vision because I am happy to contribute to your main Dev branch if you find it valuable.

  1. I suspect that many of the 'programmatic' versions of commands will be very similar, just less wordy. For example I have in my branch and 'id' command that simply returns the ICE Identifier 'ICE6809' and another command 'ver' just returns '0.998' and for crc it returns just 'FFFF' or whatever. as I look at your code, this will become problematic eventually because there will be essentially double the commands potentially. Perhaps it is more worthwhile to make a command to set an internal flag that is the opposite of verbose and more like 'concise'... it would be false by default unless set, and then once 'concise' is set, then all commands would return the shorter version. Even with 'concise', I would probably still need an 'id' and 'ver' commands.
  2. Another option since this is programmatic only, is to make a super flexible command that just takes parameters... so maybe like 'xxx' that takes a first parameter from 0-i which actually maps to a whole different command structure. so 'x 0' might return the ICE Identifier, 'x 1' would return the version number, 'x 2 0000 01FFF' would return a CSUM from 0000-1FFF etc. Perhaps that actually makes more sense?
  3. Maybe you don't even want to have this functionality in your branch and that is good too, I just want to know what you prefer because I can see pros and cons for both directions. Plus, if you don't want this in your branch, I won't bother with pull requests to you.

Thoughts?

jessaskey commented 3 years ago

So I attempted to implement this in AtomBusMon.c last night and indeed, on the .c side, things start to get complicated pretty quickly, especially when trying to optimize code so there aren't two copies of every command for each 'verbosity'. The concept for #2 above also was problematic because the Extended help required a static configuration for parameters it looks like. Plus making doCmdX routines that had more than the standard single params variable, broke the CommandFunctionTable lengths.

Lots of challenges... with, that it make me rethink my 'programmatic side' and I think it will just be best for me to make pretty extensive RegEx match groups for each command and leave AtomBusMon.c alone and allow it to stay focused on returning info and functionality. On my UI side with C# I have a lot more flexibility and way less impact on the FPGA code (none).

hoglet67 commented 3 years ago

The other consideration with extending AtomBusMon.c is code size. The FPGA hardware at the moment allows for 16KB of code space, and some of the builds come quite close to that limit. I've done extensive optimization of the libraries (i.e. avoiding the use of printf and scanf), so there isn't much scope to shrink things firther.

I think you will find adding programmatic API underneath the command interface will make things much larger, and it will no longer fit in 16KB.

An alternative might be to write your own version of AtomBusMon.c that replaces the current command interface with a lower level API-like interface.

Dave