#225 Add 18F2450/4450 (with patches and script)

closed
nobody
None
5
2008-10-14
2007-12-05
Anonymous
No

I have interpreted information for 18F2450 and 18F4450 from the data sheet DS39760C. The result of compiling my changes in works, at least for me, at least no worse than the existing 18F2455 device does. I do get errors like:

/usr/local/bin/../share/sdcc/include/pic16/pic18f2450.h:162: warning 182: absolute address for sfr 'UFRM' probably out of range.

But the same error occurs for the '2455 already in the sdcc codebase.

In the attached file are the following:

additions.tar contains:
sdcc/device/include/pic16/pic18f2450.h
sdcc/device/include/pic16/pic18f4450.h
sdcc/device/lib/pic16/libdev/pic18f2450.c
sdcc/device/lib/pic16/libdev/pic18f4450.c
sdcc/device/lib/pic16/pics.build

updates.patch contains the edited output of svn diff for my changes to:
sdcc/src/pic16/devices.inc
sdcc/device/include/pic16/pic18fregs.h
sdcc/device/lib/pic16/pics.all

pic16sheet2deviceinc.tar contains a perl utility I created and used to translate an annotated description of the new devices as derived from the data sheet to devices.inc entries. I also made a description for 18F2221 according to the data sheet; the script produces the substantive equivalent of what is already in devices.inc for 18F2221. Attached are descriptions for 18F2221, 18F2450, and 18F4450.

Usage:
./pic16sheet2deviceinc.tar 18fxxxx.description

Feel free to edit any of the above for style or egregious errors.

Discussion

  • Contains files and patches described in report.

     
    Attachments
  • Peter S. May
    Peter S. May
    2007-12-05

    Logged In: YES
    user_id=1952271
    Originator: NO

    This is mine -- SF conveniently logged me out before submitting...

     
  • Steve deRosier
    Steve deRosier
    2008-10-14

    I'm adding the same chip to sdcc.

    I noticed one little problem: The datasheet specs RAM up to 0x1FF, and then there's a two bank hole to the next and last bank. So, RAM from 0-1FF, then 400-4FF. The patch (and your tool) doesn't account for this, giving RAM from 0-2FF And frankly, the struct in devices.inc doesn't deal with this either.

    So, I guess my question is: how to deal? In devices.inc spec RAM from 0-4FF, and in code statically assign a chunk of mem in the hole to keep the compiler out? Or, spec RAM 0-1FF, and then hope I can manually access the 400-4FF chunk (used by USB buffers BTW)?

    Anybody have suggestions?

    Thanks,
    - Steve

     
  • Raphael Neider
    Raphael Neider
    2008-10-14

    The memory hole at 0x200..0x3FF is nothing the compiler has to know about. The linker, however, must not place any (valuable) data there, so we pass the buck to gputils ;-) In addition to that, we could add some "badram 0x200 0x3FF"-like lines to pic16devices.txt and emit warnings when the user places his/her data in bad RAM (using __at()).

    However, I merely adjusted the default stack so that it is now placed by the linker (instead of pinning it to 0x200..0x2FF) in order to avoid trouble with
    (a) these devices (having the stack in a memory hole is a baaaad idea) and with
    (b) devices with only 512 bytes RAM.
    The smallest ones (256 byte RAM) still *require* a directive similar to
    #pragma stack 0x80 0x40.

    Added support for 18f[24]450 (using the existing method) in SDCC 2.8.4, r5251.

    Regards,
    Raphael

     
  • Raphael Neider
    Raphael Neider
    2008-10-14

    • status: open --> closed