0

Has anyone tried using the Hi-Tech PIC18 C libraries with the MPLAB MCC18 compiler and linker? We're a small group that has been handed a legacy project which was written in MCC18. We are interested in employing the more standard and extended printf/sprintf functions of the Hi-Tech compiler. Regulatory issues prevent us from simply switching to the Hi-Tech compiler.

Specifically we are trying to replace the weak MCC18 approach of treating ROM and RAM string data differently (putsUSART and putrsUSART) and get to a standard printf which doesn't care whether the data is ROM or RAM based. In addition, we want printf/sprintf to handle floating point also without resorting to writing our own ftoa() function.

I've used the Hi-Tech compiler in the past, and their stdio functions are a pleasure to use unlike the MCC18's functions. We have both compilers, so I was thinking of creating a .LIB using the HiTech compiler and then linking that with the MCC18 code base.

Any comments from those who have tried it or use this would be greatly appreciated.

user3042888
  • 1
  • 1
  • 3
  • Interesting to use a PIC (with a [Harvard architecture](http://en.wikipedia.org/wiki/Harvard_architecture) that has separate address spaces for RAM and ROM) and then identify the MCC18 approach as weak because it treats ROM and RAM string data differently. – chux - Reinstate Monica Jun 18 '14 at 17:24
  • It is not a question about the chip architecture, but how the compiler handles the I/O. I didn't mean to infer that the Harvard Architecture was weak. It is not. I meant the MCC18 makes an unnecessary distinction about the data, and burdens the user with handling it. In cases such as STDIO, the application is gathering data to transmit it out of the chip. In this case data is data, and the compiler shouldn't care where it sourced the data. The MCC18 compiler is the only compiler that does this. Compilers for the 8051, AVR, and many other H-A devices do not make this distinction. – user3042888 Jun 18 '14 at 17:41
  • The MCC18 compiler is the not only compiler that make this distinction See http://www.ccsinfo.com/. Having worked with a number of PIC compilers, I find the various compiler _features_ to each have pros and cons. As to "standard printf which doesn't care ... ROM or RAM", there likely will be a compromise of performance (code size/speed) as fundamentally a PIC's architecture is highly RAM/ROM sensitive - but I assume your coding goal all ready considers that. Sorry this is more opinion than fact. Good luck on your approach. – chux - Reinstate Monica Jun 18 '14 at 18:05
  • Thanks for your comments, chux. We're finding that the existing code which writes data out of the USART does not seem to play well in many cases. When using putrsUSART and then continuing the message with putsUSART sometimes a random garbage character or two will be output or inserted between the ROM and RAM portions. We're concerned because we are spending too much time with STDIO issues instead of focusing on our main application. – user3042888 Jun 18 '14 at 19:23

0 Answers0