Thanks for your reply Andrew, just a few questions:
Sorry for this stupid one: What stands CYG for? And CYGSEM? I did not notice CYG_TRACE before. It seems to be s.th. similar. From the first look into the source it has more overhead on the side where speed counts. And it uses diag_printf or diag_write_* instead of printf. I see no big sense in the *XY* macros. Lazy writers can cause with them more reading effort. Code reading should be as easy as possible. I personally like the tag feature and the colors but it is a question of taste. If you ask me, I do not know what to recommend to use after I know CYG_PRINT now. I see nothing new in my trial. In case that there is a real chance for this code to be a part of eCos, could you please give me an explanation why? Otherwise I would not make the effort adapting it. If there is sense including this code some more questions: I never created sgml files, so I asked Google and downloaded a test license of ecpEdit - a sgml editor. So when I try to load any of the eCos sgml files it pleasures me with several error messages. A further quick search was not right away successful - so I better ask: Could you please recommend me a tool for sgml editing and point, if there is, to a sgml template for eCos doc? And an idea: In general the out fn could just send the log buffer (string pointers and values) to the host and the printf would be done there. For this the .const segment is needed there (it could be separated during the build process) and a special terminal is needed, may be kind of a filter and a standard terminal. This way the stings in the target not needed, we get rid of the appropriate code there and we have better performance. May be this point makes it worth to add the logging code to eCos. Unfortunately I have not the power to do this kind of host side implementation. Best Thomas Andrew Lunn <[EMAIL PROTECTED]> schrieb: > On Thu, Jun 08, 2006 at 07:09:52PM +0200, Thomas H?henleitner wrote: > > Hi everybody reading this, > > > > attached is a trial implementing a data logger and it would be a pleasure > > for me if you like it. > > > > Short description: > > ================== > > A colored realtime data logger allowing logging inside and outside of > > interrupts. > > Has the option to detect one or several repeated logs. > > Logs are stored in a log buffer (just string address and parameter) and > > emitted in the background. Logs are with tags which are used during compile > > time (if special tag logs are compiled), during runtime (if compiled > > special tag logs are visible) and for colored output if enabled. > > Hi Thomas > > As is the code is not very useful. Please could you turn it into an > eCos package. Maybe put it under packages/services/logging/colour/ > > Also, you need to sort out the name space polution. All public > functions/macros should have cyg_/CYG_ prefixes. This is particularly > important for this sort of code which has to be usable everywhere. > > You should add CDL to control the different build options, eg > CYGSEM_COLOUR_LOG_DETECT_REPEATED_LOGS > CYGSEM_COLOUR_LOG_COLORED_LOGGING > CYGNUM_COLOUR_LOG_MAX_LINE_LENGTH > etc. > > You might want to remove os.h and directly call the relevent > functions. > > It would also be good to write some documentation in SGML. > > Please could you also summaries how this is better/different to the > existing CYG_TRACE code. > > Thanks > Andrew >
