Best practices re: debug logging in spin

jhh

Hi! I've been lurking the forums a while, and decided to join in so I could ask some questions of the wiser community here.

I'm presently on a mission to "clean up" the Sources folder from the C3 FTP site, turning demos into objects, and so on. Eventual plan is to publish a project on GitHub.

So far this has all been going very well, but I've gotten a bit snared on the SD driver, as it would appear to have a dependency on tv_terminal to support it's debugging. Factoring out that dependency is my next target, so there can be a "pure" spin object for the SD cards.

Now, I don't want to throw the baby out with the bathwater, and remove all this useful logging. But what DO I do with it?

I went looking around for some established practices for this, and seem to have come up a bit dry. The closest I found in the object exchange seems to be something call "MultiCogSerialDebug", and may be where I start deriving a solution, unless folks have some other suggestions?

Ideally the logging solution is not tied to a particular output, I see the implementation as containing two parts:

1) The programming interface which might offer up things like:

debug.warn( string("you don't want to do that.... Dave...") )

And stuff those into some smallish buffer for the other part to pick up

2) The output driver(s), which read the buffer and perform the output. The intent would be to have several flavors of this, and you could switch out what's needed. Among the output drivers I would like:

- serial (outputs to a serial line)
- tv_terminal (outputs to an instance of tv_terminal)
- null (takes no action, and ideally, is such a null action that the compiler can optimise out the log call itself...)

While I am using BST (prefer Linux for development), I'd like to fashion this in a way that avoids forcing that to be used, and work with the standard tools.

Any thoughts, opinions (or tomatoes) are appreciated.

Mike Green

Some of the drivers are furnished as examples, hence the built-in logging that seems to be deeply embedded. Other drivers (like the ones in FemtoBasic) are separable. sdspiFemto and fsrwFemto are designed to be used independent from FemtoBasic (and its other drivers).

BST (and Homespun) have conditional compilation features, so the debugging / logging statements and declarations used only for debugging / logging can be surrounded by a conditional {$IF} so those statement are simply not compiled if debugging / logging is disabled.

localroger

If you're not using the programming port the output method most universally unlikely to conflict with something is fullduplexserial out the programming port. It also doesn't require a screen buffer like tv_text, although you might want to use the version that allows for a 256-byte output buffer so that it the .tx method doesn't freeze the main process while it clears characters (the main reason people prefer tv to the serial for debugging is that the tv is faster). You can monitor the output with the Propeller Serial Terminal, Hyperterminal, or about five thousand other terminal programs according to your taste in functionality.

You can also leave the debug code in but conveniently switch out the functionality by including another object in your project that supports all the methods you use in fullduplexserial with the same arguments, but doesn't do anything with them; then you can just comment out the one you're not using in the OBJ block instead of commenting out all the individual debugging output lines.

jhh

Thanks for the input.

My original intent was just do a factoring exercise, mostly on the code relating to SPI, to have all users of SPI go through some common code and wrap an exclusion lock around it. I was going to then do any other de-duplication I could find, while leaving the demos/tests as-is (save for switching to the common code)

While there may be merit to a basic 'logging' system as I suggest, it may be inappropriate to go about in the manner I was thinking (think like log4j or the like), and better to use #defines as you suggest to enable instrumentation as a compile-time option. Were I to go ahead with the logging effort, I imagine it would look like a 'log' function to a ring buffer of sorts, with writers moving a head pointer, and readers (log output drivers, ie serial, tv, vga, etc) consuming from a tail pointer chasing the head.

I guess I'm less interested in the specifics of any given output mechanism, and more on how can a generic, lightweight logging facility be introduced which provides an abstraction between the needs of the object programmer wanting to log something (IE: i want to log a message, and a level, and not care about much else), and the programmer building a larger system out of components (IE: i have decided to use output method _____, now give me access to log output so I can graft that into my application where it makes sense to me.)

It's the case of one hand, I'd like to see a debug logging mechanism anyone can make use of when building components, while at the same time allow anyone else to 'tap' into that stream of information, regardless of what they have decided to use for the job, since so many options exist.

If there is some level of interest in such a thing (a logging abstraction), I may look into it some more.

Since it's just the SD driver I am having this sort of block on, I think for now however I will step back from this particular ledge, and go look at one of the more purposefully 'modular' sd drivers that have been pointed out, in the interests of my more immediate goal of giving myself a "library" set to play with my C3 on.

Thanks for your thoughts, and any others that might come.