Anyone with a replacement Printf?

[Larry Barello]

I wrote a buffered i/o system for the IFI controller. It is file oriented so output can be directed to either the program port or the TTY port. It is buffered so calls to printf can occur even in interrupt handlers (no blocking) It can handle the actual i/o either as polled in the fast loop, or via a low interrupts. I'll be publishing it soon. I have fputc() fgetc(), etc. done.

The problem is that the existing IFI printf library doesn't exactly lend itself to creating an fprintf() routine, and a "printf()" on top of that (i.e. default output to one or the other ports).

Maybe I just need a primer on how printf(...) works... But I thought I would ask and see if someone has a version that would be more amenable to the streams approach to output.

The original goal was to have the debug menu on one port and still have access to another port for serial peripherals (say, a GPS unit?) But just having it buffered and polling makes a HUGE difference in performance and ability to debug with printf statements.

[Astronouth7303]

Originally Posted by Larry Barello

I wrote a buffered i/o system for the IFI controller. It is file oriented so output can be directed to either the program port or the TTY port. It is buffered so calls to printf can occur even in interrupt handlers (no blocking) It can handle the actual i/o either as polled in the fast loop, or via a low interrupts. I'll be publishing it soon. I have fputc() fgetc(), etc. done.

The problem is that the existing IFI printf library doesn't exactly lend itself to creating an fprintf() routine, and a "printf()" on top of that (i.e. default output to one or the other ports).

Maybe I just need a primer on how printf(...) works... But I thought I would ask and see if someone has a version that would be more amenable to the streams approach to output.

The original goal was to have the debug menu on one port and still have access to another port for serial peripherals (say, a GPS unit?) But just having it buffered and polling makes a HUGE difference in performance and ability to debug with printf statements.

Here:

Originally Posted by Mark McLeod

I just put some routines here http://www.chiefdelphi.com/forums/showthread.php?t=26529 that do this.

You can just call the one routine that prints decimals without changing any of your own printfs.

PS- why do you have to have at least 2 characters?

[Larry Barello]

The modified printf's referenced, above, don't help me. They just fix some of the more blatent errors in IFI's code.

[Ryan M.]

Since the system is relativly limited, streams don't do much good, as their whole point is to allow you to work with multiple devices in a similar fashion. If your thinking of writing printf over from scratch, I'll warn you that it is very hard to work with variable parameter lists in C. I, personally, would hate to have to do it.

[Crazy_Ed]

I don't know enough to answer your question, but I would just like to comment that serial ports are way to slow to send anything major across. Maybe next year we get usb or *gasp* ethernet.

[Larry Barello]

Ok, I finally figured out how to modify printf_lib to do what I want. I have posted a white paper + code out my teams web site in the white papers section.

http://www.titanrobotics.net/index2....whitepages.cfm

It is a fully buffered I/O for both the TTY and Program serial ports (i.e. streams).

It is rather nice to be able to have the user interface (to examine the health of the robot) on one port and have the diagnostics spit out on another port simutaneously.

It is also really nice to be able to put printf() in interrupt handlers and have it work without messing up the interrupt handler.

Enjoy.