From: Beau E. C. <be...@ha...> - 2005-09-21 21:13:08
|
Hozit* Howard - ======= At 2005-09-21, 10:32:34 you wrote: ======= >Hi Beau, > I haven't been posting to the list because I'm still in the problem >definition phase. I've been talking to Rapheal and am attaching the last >message I sent to him. > I'm new to sdcc, new to pics and new to the mailing lists, so I'm not >sure how this process should work. I've only started on this process a >couple of weeks ago and it sounds like you've got a lot more experience. > The script enclosed should produce a subdirectory with the output files >as a rudimentary project tree. I was just starting a code change to sort >the bitfields "prettier" and then do a code cleanup before posting. > The output files ending with .proto I think you'll recognize. The file >ening with .mml was a point for sdcc list discussion to create information >storage for future processing. I wasn't sure if XML or .ini style would be >better received, but once the data is there, it can be converted. I think XML is the way to go. It's an established standard unencumbered by copyright and has a large support base of tools in almost all languages. > The file ending in .debug_a is intended to be a one stop check to look >for abnormalities, and additional .debug_X is to provide for future >debugging checks and is currently for illustration purposes only. It's >output (.debug_b) is presently for debugging the bitfiled sorts. > The .inc source file is copied into the output directory and also the >script is copied under a new name. If the script is executed under the >'general' name, it creates the output directory and respects the lock >file. If executed under the 'local' name, it operates on the local files >and ignores the lock. That's so the user can tweak the script for the >individual .inc file if needed. > In the note to Rapheal, I suggest a modification to the sdcc source >tree to allow for easy incorporation of new processors. I'd like to get >that idea hammered out and a mechanism in place. > Hope all this makes sense, and I look forward to hearing from you. In >the mean time, I'll try your scripts and be in touch. > It's going to take me a few days to digest your work,,, After reading your note to Raphael, I should explain further on how I integrate my changes into the 'official' sdcc. The second of my scripts ( xml2chm ), produces .h/.c/.m files for each processor as well as 'devices.inc', 'pics.all', and 'i2c.ignore'. To integrate into sdcc ( before I do the sdcc build ), I copy the .h and .c files to sdcc/device/include/pic16 and sdcc/device/lib/pic16/libdev. The .m files (.m==miscellaneous) presently contain conversion warnings. Next I replace 'pics.all' and 'i2c.ignore' in the sdcc tree. I then patch sdcc/src/pic16/device.c by removing the standard device defs and replacing them with '#include "devices.inc"'. Two other minor patches are applied because some of the names of the sfr bits changed in my automated generation. I will send you my complete series of scripts (bash and gnu Makefiles) soon and you can see what I'm talking about. I also think we should post to the list as well as each other during our talks. Who knows - we may stir the interest of some of the lurkers... ( I should talk, I'm a lurker on a half-dozen lists myself :) ). If the list community doesn't want our discussion, please let us know. Aloha => Beau; be...@ha... 2005-09-21 *Howzit => local Hawaiian slang for 'How's it going?' |