Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 23:44 28 Mar 2024 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : CMM2: any possibility of PEEK access to the TRACE

Author Message
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 3807
Posted: 09:41am 25 Nov 2020
Copy link to clipboard 
Print this post

I know it's niche and obtuse, but I have a reputation to maintain and perhaps it wouldn't be too difficult to implement.

What do I want?

1) The ability to PEEK(TRACE) to get the memory address of the the datastructure used to fulfill calls to TRACE LIST.

2) To be told where that datastructure is in the firmware source-code so I can determine how to navigate it.

Why do I want it?

I believe from this I will be able to extract the necessary information for my MMBasic Unit Test framework to report the actual line numbers of failing test assertions, at the moment I have to make do with reporting the index of the failing assertion within a given test method.

e.g. currently:
> run "tests/tst_strings.bas"
A:/SPTOOLS/SRC/COMMON/tests/tst_strings.bas
 test_centre:                        PASS (3/3)
 test_join:                          FAIL (2/4)
 3: Assert equals failed, expected "one,two,three,four" but actually "one@two@three@four"
 4: Assert equals failed, expected "one, two, three, four" but actually "one@two@three@four"
 test_lpad:                          PASS (2/2)
 test_next_token:                    PASS (5/5)
 test_rpad:                          FAIL (1/2)
 1: Assert equals failed, expected "hello     " but actually "hello      "
 test_tokenise:                      PASS (6/6)
 0.010233 s


desired:
> run "tests/tst_strings.bas"
A:/SPTOOLS/SRC/COMMON/tests/tst_strings.bas
 test_centre:                        PASS (3/3)
 test_join:                          FAIL (2/4)
 Line 56: Assert equals failed, expected "one,two,three,four" but actually "one@two@three@four"
 Line 57: Assert equals failed, expected "one, two, three, four" but actually "one@two@three@four"
 test_lpad:                          PASS (2/2)
 test_next_token:                    PASS (5/5)
 test_rpad:                          FAIL (1/2)
 Line 76: Assert equals failed, expected "hello     " but actually "hello      "
 test_tokenise:                      PASS (6/6)
 0.010233 s


Best wishes,

Tom
Edited 2020-11-25 19:43 by thwill
Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8516
Posted: 10:52am 25 Nov 2020
Copy link to clipboard 
Print this post

Not really possible in any usable way. The trace buffer is just a circular buffer of memory locations of the start of a given line in memory. TRACE LIST does multiple cycles through a sequential search to find each location in turn and then generate the output so even if you knew the buffer location you would need to write a complex bit of code to parse out the line number.
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 3807
Posted: 11:06am 25 Nov 2020
Copy link to clipboard 
Print this post

  matherp said  Not really possible in any usable way. The trace buffer is just a circular buffer of memory locations of the start of a given line in memory. TRACE LIST does multiple cycles through a sequential search to find each location in turn and then generate the output so even if you knew the buffer location you would need to write a complex bit of code to parse out the line number.


Hi Peter, I didn't expect it to be easy for me to write the necessary code, but if you provided the "hook" (I'm assuming you can't just give me an explicit address because the compiler will be moving it around between builds) it would at least be possible for me to try. If not then I'll just shrug my shoulders but it would take my unit test framework to the next level.

Best wishes,

Tom
Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 3807
Posted: 11:10am 25 Nov 2020
Copy link to clipboard 
Print this post

Please don't expend time trying to make it "usable". I just want the hook so I can then sink or swim depending on my own abilities. I'm also aware I may need to tweak the code between firmware releases.
Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8516
Posted: 11:24am 25 Nov 2020
Copy link to clipboard 
Print this post

The problem is that the code you use to parse will also change the buffer so you will be trying to hit a moving target I can't begin to think how I would code it and therefore what hook you might need
Edited 2020-11-25 21:25 by matherp
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 3807
Posted: 11:38am 25 Nov 2020
Copy link to clipboard 
Print this post

  matherp said  The problem is that the code you use to parse will also change the buffer so you will be trying to hit a moving target I can't begin to think how I would code it and therefore what hook you might need


<slaps head> of course, I need a snapshot of the buffer.

Let's go back to requirements analysis:

From the first line of a SUB or FUNCTION I need to be able to determine the line number (and filename) that called that SUB/FUNCTION. Complications arising from that call occuring due to CALL, EVAL, etc. can be ignored; all bets are off if those are used.

I suppose it's too much, and too esoteric to ask for an Mm.Info$(TRACE) that returns the last 5-10 line numbers (and where appropriate file names) stored in the TRACE ? - strictly speaking I probably only need 2 or 3 entries to determine the context, but better safe than sorry. Of course you might be able to just provide Mm.Info$(CALLER) which really would go "above and beyond".

In my opinion the ability to support a good unit testing framework is quite a good cause, YMMV.

Thanks,

Tom
Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
lizby
Guru

Joined: 17/05/2016
Location: United States
Posts: 2989
Posted: 12:57pm 25 Nov 2020
Copy link to clipboard 
Print this post

The "hook" I'd want would be a call to, say, mmb_dbg(line#) for every line between "TRACE DBG" and "TRACE OFF". That would allow thwill to build his own structure (and would also allow other debugging code, like a debugger).

~
Edited 2020-11-25 22:58 by lizby
PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 3807
Posted: 01:08pm 25 Nov 2020
Copy link to clipboard 
Print this post

  lizby said  The "hook" I'd want would be a call to, say, mmb_dbg(line#) for every line between "TRACE DBG" and "TRACE OFF". That would allow thwill to build his own structure (and would also allow other debugging code, like a debugger).

~


Aargh, a hijacker - I was trying to go for a minimal possible request.

Yes that would work, but the additional load could skew the profiling that my unit test code also performs. Note that if it were implemented as @lizby describes I would also like the filename (for calling code originated in a .inc file).

Best wishes,

Tom
Edited 2020-11-25 23:09 by thwill
Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8516
Posted: 01:16pm 25 Nov 2020
Copy link to clipboard 
Print this post

Let's put this one to bed.

I'm not making any more changes in this area. Many applications for the Micromite family in general including the CMM2 are real-time or pseudo real-time. Debugging support inevitably changes the timing of program execution and often things that work in the debugger don't without it or visa-versa.

I can't use the STM32CudeIDE debugger at all in developing the firmware as it completely changes the way the firmware runs and in some case I can't even use print statements as they also have an effect and I have to rely on I/O toggling and LEDs or an oscilloscope.

You have the TRACE statements and now the #MMDEBUG directive and MMDEBUG command on the CMM2 and that is as far as it is going to go
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 3807
Posted: 01:33pm 25 Nov 2020
Copy link to clipboard 
Print this post

OK, you're the boss, but I don't see how the timing arguments as applicable as they might be to attaching a debugger apply to my request for a piece of context I can access from unit-tests ...

... damned hijackers

Tom
Edited 2020-11-25 23:34 by thwill
Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
thwill

Guru

Joined: 16/09/2019
Location: United Kingdom
Posts: 3807
Posted: 01:54pm 25 Nov 2020
Copy link to clipboard 
Print this post

OK, I know how to do this without any firmware extensions - though if you would add that Mm.Info$() extension that would be much simpler than my workaround.

I can have the framework preprocess the "tst_.bas" files and write instrumented versions that replace each call to ut.assert_foo(a, b, c) with ut.assert_foo("<file>:<line>", a, b, c).

Your can't keep a good hacker down

Enjoy the rest of your day,

Tom
Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
lizby
Guru

Joined: 17/05/2016
Location: United States
Posts: 2989
Posted: 03:09pm 25 Nov 2020
Copy link to clipboard 
Print this post

damned hijacker indeed.

Nor would a feature turned on by "TRACE DBG" have any effect on the timing of a program which didn't include that statement, howevermuch timings and all sorts of other issues might arise if TRACE DBG were activated.
PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed
 
Print this page


To reply to this topic, you need to log in.

© JAQ Software 2024