Value monitor / debug monitor in separate cog
Erlend
Posts: 612
What I want is to run a continous routine in the background which reads a block of global variables (in Main) and displays them on a serial terminal (PC or LCD) on a continous basis (call parameter= ptr to first variable, number of varables in contigous block). I started off coding a simple method running in a separate cog, and calling PST to do the displaying work, but before I finished I realised that I will not have two cogs to spare, I must do with one.
Before I start butchering PST and incorporating my Print_values routine into a hybrid Object, I want to ask for advice. Surely I cannot be the first one to want a monitor to sit running independantly in a (single) cog, and display values of variable as my main program executes?
Erlend
Before I start butchering PST and incorporating my Print_values routine into a hybrid Object, I want to ask for advice. Surely I cannot be the first one to want a monitor to sit running independantly in a (single) cog, and display values of variable as my main program executes?
Erlend
Comments
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 ' use 5MHz crystal VAR long monitorStack[20] long parameter1 long parameter2 PUB main cognew(monitor,@monitorStack) repeat waitcnt(cnt + clkfreq / 2) parameter1 += parameter2 += 1 PUB monitor dira[30]~~ repeat waitcnt(cnt + clkfreq / 2) Tx($00) str(string("parameter1: ")) dec(parameter1) str(string($0D,"parameter2: ")) dec(parameter2) PRI str(stringPtr) repeat strsize(stringPtr) Tx(byte[stringPtr++]) 'Transmit each byte in the string PRI Dec(value) | i, x x := value == NEGX 'Check for max negative if value < 0 value := ||(value+x) 'If negative, make positive; adjust for max negative Tx("-") 'and output sign i := 1_000_000_000 'Initialize divisor repeat 10 'Loop for 10 digits if value => i Tx(value / i + "0" + x*(i == 1)) 'If non-zero digit, output digit; adjust for max negative value //= i 'and digit from value result~~ 'flag non-zero found elseif result or i == 1 Tx("0") 'If zero digit (or only digit) output it i /= 10 'Update divisor PRI Hex(value, digits) value <<= (8 - digits) << 2 repeat digits 'do it for the number of hex digits being transmitted Tx(lookupz((value <-= 4) & $F : "0".."9", "A".."F"))' Transmit the ASCII value of the hex characters PRI Tx(txByte) | t, bit_delay bit_delay := clkfreq / 19200 txByte <<= 2 t := cnt repeat 10 outa[30] := (txByte >>= 1) & 1 waitcnt (t += bit_delay) outa[30]~~Thank you!
Erlend
As I dig through my archives to 2008 I can indeed confirm that you are not the first one wanting this
Here is a still from an ANSI debug screen I had running at 115.2K baud to monitor the operation of a Prop based 12 channel pill counter written in Spin.
However with Forth I always have access to the system when it's running, to monitor, to change, to run or change code etc.
Why is there no Forth for mortals, i.e. with a syntax that is not the opposite of my brain processes/thinking?
Erlend
As soon as you use the word syntax I see where the problem lies. You have hardwired a perfectly good brain that was otherwise able to make all kinds of connections and limited it to what you have been taught as "programming language". Anyway without getting into all these endless debates about "languages" the thing is Forth is far more than a language as it can very well be the complete O/S and command shell, compiler, and debugger, except it resides on the Prop in this case.
The other little thing is that just as you have your own unique way of thinking and expressing yourself that is also most natural for you, so too in the manner in which we can program in Forth in that we shape it to suit the way we think. Not doing so results in ugly write-only code because the person who wrote it didn't know what they were thinking. However when we start thinking outside the syntax box we can be far more creative and productive in the process, and if I haven't said it before, have more fun.
Well,...because if there was such thing it would not be Forth. It would be some other language like C or Scheme or Spin or...
Thing is, Forth is a solution to a specific problem. How to provide some kind of human friendly programming environment on a computer using the least amount of resources. Specifically memory space and perhaps processor speed.
To solve this problem Forth has the minimal amount of syntax (and semantics). Which means it takes minimal amount of code to parse it and produce something that runs. That makes it's run time really small.
I can't imagine any other way to do what Forth does apart from dropping to the level of a debug monitor that allows the user to enter programs as machine code in hexadecimal.
Been there done that. It's a waste of time because the end result is specific to a particular processor instruction set / architecture.
Presumably others have tackled this problem over the decades and not come up with a better solution.
Problem is, Forth is the only "high level language" that makes writing programs harder than writing the same functionality in PASM. Basically Forth leaves all the book keeping that a real language compiler does up to the programmer.
Forth is a very clever solution to that "minimalist programming environment" problem.
Do you want to invest you time into that solution? Up to you.
Forth does fascinate me - but the times I have tried it has been to alien for me. I hate to think I will probably die without having learned Forth, but there are just too many things I want to do and learn. And I like Spin+Propeller.
Erlend
If you wanted to speak Japanese you would learn more from someone who mastered it rather than from someone who has obviously failed even if they have a lot to say (and you can't stop them). Same with Forth.
If Forth was really that much harder than PASM etc then it would be difficult to be productive right? How is it then that many are the most productive and have the most fun with Forth? To learn a language you must immerse yourself in and not keep reverting to your native language. So immerse yourself in it with a real project however you will never learn just by dipping your big toe in or watching from afar.
Forth is actually a very simple language. The postfix syntax seems odd at first, but it greatly simplifies the interpreter because an infix parser is not needed. The singularly linked list dictionary is simple to implement and works very well. Some the words such as IMMEDIATE and DOES> may take a while to fully understand, but once you do understand them they can become quite powerful. Because of the simplicity of Forth it can be easily ported to new processors, and immediately provide a simple OS and development environment. The interactive nature of Forth makes it useful for interfacing to hardware by writing and running snippets of code to see how the hardware reacts.
However, Forth does have some disadvantages. The dictionary consumes space that could better be used for code and data. The outer-interpreter also uses space that may not be needed for a fixed application. Forth uses data and return stacks that are constantly pushed and popped. The programmer must keep track of where values are located on the stack, and must duplicate them on the stack when needed for a calculation. Some Forth interpreters keep the stacks in registers to reduce stack thrashing, but this imposes limitations on the code. Forth does not support structures or objects, and all variables and words are global. There are ways to implement structures and objects in Forth, but some other HLLs provide these features as part of the language.
Try Forth, and keep using it if it works for you.
It has excellent options to view and change Hub and even Breakpoints in SPIN.
To use it you need to install one Cog running a object feeding data thru serial/USB to the ViewPort Program.
Nice visualization of Pin States, behavior over time, ton's of goodies.
Link here: http://onerobot.org/products/viewport/
Enjoy!
Mike
I wouldn't disagree too much with what's been said here, usually the best opinions are the ones that are balanced and informed, so you will have the pros and cons and some kind of positive recommendation, then it's up to us to weigh that in the balance with our own situation and choose.
I also agree with some of the cons which is also why Tachyon is non-standard in such respects as deep stack manipulation. My philosophy is that if you need to PICK and ROLL you are doing something wrong, so I don't and won't implement these words plus I actually keep loop parameters and loop branches on their own stack for very sensible and practical reasons.
With regards to the dictionary taking up space, well that is fine in systems with lots of memory but the poor 32K RAM bound Prop doesn't have a lot to go around. But on the plus side Tachyon's compact bytecode implementation doesn't take up a lot of RAM. On another plus side in systems that have larger dictionaries they usually are using SD and I have made it so that the dictionary resides in a file thus freeing up RAM and with the way it's implemented it actually searches faster!
Many HLLs are PC based that churn out a binary blob for the target so they can do a lot of the structuring, optimisations, and checking at the PC compile level so I find it hard to compare those features with a 32K RAM based compiler that runs on the Prop. How could you ever compete in that regard but once again it's a matter of weighing up the pros and cons.
As for stacks being pushed and popped this is not something unique to Forth however rather than being hidden, the parameters are openly exposed to the programmer, which you can either count as a pro or a con, depending upon your point of view.
So that's a couple of cons I have turned into pros compared to traditional Forths anyway.