Closed jessaskey closed 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).
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
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.
Thoughts?