On 2005-10-15, Andreas Schwarz <usenet@andreas-s.net> wrote:>> printf should NOT be used for debugging at all. some parts >> only have 2-4 K of program memory. > > Some parts have only 512B of memory - so what? Of course there > are exceptions. > >> Only ametures debug with printf on 78 bit micros. > > And what do professionals use?And where do you get 78 bit micros? -- Grant Edwards grante Yow! Bo Derek ruined at my life! visi.com
Microchip Introduces First 16-bit Microcontroller Product Line - the PIC24
Started by ●October 11, 2005
Reply by ●October 16, 20052005-10-16
Reply by ●October 16, 20052005-10-16
On Sunday, in article
<j6d4l1d04mj3ctm28lqqacr5sgo2slj55i@4ax.com> keinanen@sci.fi
"Paul Keinanen" wrote:
>On Sun, 16 Oct 2005 02:24:21 +0100 (BST),
>paul$@pcserviceselectronics.co.uk (Paul Carpenter) wrote:
>
>>Creating a custom printf is MUCH better than using a library function
>>many applications do not need
>>
>> Floats
>> scientific of exponential notation
>> pointer printing
>> long modifiers
>> escape characters (form feed, line feed, bell)
>>
>>Mnay only need single character or formatted strings with a byte or short
>>(signed/unsigned printing).
Forgot the one that is RARELY needed in embedded situations, and relying on
it, would mean a bad design anyway - printf returns the number of
characters output which I have not *yet* seen an application use.
>If the library sources are available, it should be easy to disable the
>floats etc.
>
>However, if the library sources are not available, but if the library
>object files have been divided intelligently, e.g. the actual printf
>function in printf.obj and the floating point printing routines in
>print_float.obj, it should be possible to create dummy_float.c
>containing e.g.
>
>void print_float (double d.....)
>{
> return ;
>}
Makes a lot of assumptions, works on one library, for better code reuse
for MINIMAL footprints, use a stripped down one for usability on more
compilers and targets.
>Put the dummy_float.obj on the linker command line _before_ the
>library files. When the linker detects the printf reference in he
>application program, it extracts the printf.obj from the library.
>Since that printf module contains a reference to print_float, the
>linker already knows where it is, since it has been provided by the
>dummy_float.obj and does not need to retrieve the print_float.obj from
>the library.
Assuming the library module for that function, is actually a separate
module whereby you can save space, otherwise you will have it *POTENTIALLY*
included but not used.
That solution is very compiler/linker/library dependant.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/> PC Services
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info
<http://www.badweb.org.uk/> For those web sites you hate
Reply by ●October 16, 20052005-10-16
On Sun, 16 Oct 2005, Everett M. Greene wrote:> Sergio Masci <sergio@NOSPAM.xcprod.com> writes: > > On Sat, 15 Oct 2005, Andreas Schwarz wrote: > > > Ian Bell schrieb: > > > > Michael N. Moran wrote: > > > > > Ian Bell wrote: > > > > > > Andreas Schwarz wrote: > > > > > > > > > > > > > The problem is that you need different instructions to read > > > > > > > from RAM and > > > > > > > ROM, so you often end up with two functions that do the same > > > > > > > thing, one > > > > > > > for RAM arguments (printf), and one for ROM arguments > > > > > > > (printf_P). > > > > > > > > > > > > Right so the *real* problem is handling large constant strings. > > > > > > > > > > Well ... strings are only one part of the problem. > > > > > Any constant tables/arrays, such as: > > > > > > > > > > o state tables > > > > > o lookup-tables > > > > > o <shield-up> v-tables <shield-down> > > > > > > > > > > are problematic to most traditional compilers/languages that > > > > > only understand a single contiguous address space. > > > > > > > > But surely that is a *compiler* issue not a fault of the underlying > > > > architecture? > > > > > > No. To achive true transparency, the compiler would have to generate code that > > > can tell a ROM address from a RAM address at runtime. Otherwise functions that > > > take pointer arguments would not be possible. > > > > This is simply wrong. A compiler can trace the use of a pointer > > throughout the code at compile time. > > Particulary not in the face of separate compilation. Even if the > entire source is available, it still may not be able to determine > where a pointer points (a number is a number is a number...).where a pointer points to is not the issue, what a pointer is pointing to is. Consider a pointer to a "char". No mater where the pointer is pointing the compiler knows it is pointing to a "char". Regardless of how you manipulate the pointer the compiler will always derefernce it as a char pointer. You can play hide and seek and force a non char pointer into it but that is not the point. Here "char" is an attribute of the pointer and the attribute is tracked throughout the use of the pointer at compile time NOT runtime. Another attribute could easily be the address space (RAM, CODE, I/O etc). The actual runtime contents is not important, the compile time attribute is. With regard to seperate compilation: don't make me laugh! Yes it may have been necessary 20 years ago to compile a 10,000 line C program as seperate 1,000 line modules because each module took 5 minutes to compile (on a state of the art PDP/11). But today a 1,000,000 line program takes less than 2 minutes to compile AND given that most programs for a tiny MCU are much smaller than this, seperate compilation is not necessary and in many cases it is actually counter productive from an optimisation standpoint. Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use .
Reply by ●October 16, 20052005-10-16
On 2005-10-16, Andreas Schwarz <usenet@andreas-s.net> wrote:> in theory you can hide any architecture issue from the > programmer with software. But if none of the compilers does this > (because it would require a lot of effort or would create too much > overhead), this knowledge is of little value for me.Hi-Tech's C compilers for the PIC have RAM/ROM pointers without the use of extensions. Const objects (those which have storage allocated) and string literals reside in ROM. Other objects reside in RAM. Pointers to const point to ROM and RAM, with the appropriate address space determined at runtime. Other pointers point only to RAM. -- John W. Temples, III
Reply by ●October 16, 20052005-10-16
Ian Bell schrieb:> Andreas Schwarz wrote: > >>Nobody uses printf for simple printing of constant strings. > > > There's a serious danger of going round in circles here because that's just > what the OP was doing with printf.Where?
Reply by ●October 16, 20052005-10-16
Andreas Schwarz wrote:> > Nobody uses printf for simple printing of constant strings.There's a serious danger of going round in circles here because that's just what the OP was doing with printf. Ian
Reply by ●October 16, 20052005-10-16
On Sun, 16 Oct 2005, Andreas Schwarz wrote:> Sergio Masci schrieb: > > On a PIC you can insert RAM page select instructions in front of all > > instructions if you wish *** OR *** you can analyse your code and only > > insert them where you NEED them. > > As I said, in theory you can hide any architecture issue from the programmer > with software.No what you said was "using a layer of software" not "with software" these are different things. We hide the underlying architecture with software every time we use a high level language.> But if none of the compilers does this (because it would > require a lot of effort or would create too much overhead), this knowledge is > of little value for me.Writing any half decent compiler "requires a lot of effort" Yes compilers that generate VERY EFFICIENT executables for the PIC do exist. And at least one assembler (XCASM) that performs analysis of RAM and code page useage does exist and yes it does insert RAM and code page select instructions at optimal locations. I guess the gripes is that this is not done by the FREE Microchip assembler. Also, using the XCSB compiler, you can add lots of embedded (inline) assembler and not worry about RAM and code paging. Yes tools that do the job (and do it very well) do exist. You just obviously don't know about them. To claim that the underlying PIC architecture is a problem is nonsense. It's crap compilers and assemblers that are the problem. Regards Sergio Masci http://www.xcprod.com/titan/XCSB - optimising PIC compiler FREE for personal non-commercial use .
Reply by ●October 16, 20052005-10-16
In article <11l4v5jf60asb27@corp.supernews.com>, Grant Edwards <grante@visi.com> writes>On 2005-10-15, Andreas Schwarz <usenet@andreas-s.net> wrote: > >>> printf should NOT be used for debugging at all. some parts >>> only have 2-4 K of program memory. >> >> Some parts have only 512B of memory - so what? Of course there >> are exceptions. >> >>> Only ametures debug with printf on 78 bit micros. >> >> And what do professionals use? > >And where do you get 78 bit micros?errrr..... in a custom FPGA :-) -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/ /\/\/ chris@phaedsys.org www.phaedsys.org \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply by ●October 16, 20052005-10-16
On Sun, 16 Oct 2005 19:41:46 +0100, Sergio Masci <sergio@NOSPAM.xcprod.com> wrote:>To claim that the underlying PIC architecture is a problem is nonsense. >It's crap compilers and assemblers that are the problem.Wow.> >Regards >Sergio Masci > >http://www.xcprod.com/titan/XCSB - optimising PIC compiler >FREE for personal non-commercial useWell, looking at your signature, I feel a little bit better, because now I understand how come someone can write paragraphs like the one above.
Reply by ●October 16, 20052005-10-16
