gnupic: sdcc and USB
Subject:
sdcc and USB
From:
Easy B ####@####.####
Date:
3 Nov 2005 17:09:43 +0000
Message-Id: <BBA30EC1-D74F-435D-912F-EE27741F4EC0@freesurf.ch>
Hi guys
I'm planning to start programming my new 18F2550 USB PIC with sdcc.
I'm aware of the examples from microchip and other work based on
them, but I never found any code specially for sdcc. Now I'm
wondering if anybody ported the examples or has some other USB code
that compiles with sdcc. Or do I have to start from scratch? I know
that a few guys like Xiao Fan own USB PICs and also use sdcc. I
really don't want to start programming the 18f parts in assembly,
everybody is shouting that sdcc works for PICs, especially 18f ones,
so I want to try that.
Thanks in advance.
Cheers,
Ezra.
Am 02.11.2005 um 10:07 schrieb Chen Xiao Fan:
>
>
> -----Original Message-----
> From: ####@####.####
> ####@####.####
> Sent: Friday, October 28, 2005 3:49 AM
> To: ####@####.####
> Subject: [Sdcc-user] PIC14 port matures
>
>
> Dear SDCC/PIC14 users,
>
> I am really proud to announce that the PIC14 port has seen serious
> improvement over the past few days:
>
> - large quantity of bugs removed
> - generic pointer support added
> Now `unqualified' pointers are three bytes long, use qualifiers
> __data or __code to reduce them to two bytes.
> Pointers to const "variables" are no longer assumed to point to
> __code space; use __code const int *x instead)
> - better library support has been added
> Now the PIC14 port provides better support for multi-source file
> projects (still lacks initialization of variables outside the main
> module though, bet works nicely with the library).
> All support routines (generic pointer access, multiplication,
> division/modulus) should work nicely on a large number of devices
> without recompiling. All projects must link PIC14's libsdcc.lib to
> make use of these!
> (Volunteers may now start porting a libc...)
> - a new command-line switch has been added to disable a (slightly)
> faulty optimization (--no-pcode-opt).
> An improved (and correct ;-D) replacement is under development.
>
> Note that .o output from previous SDCC versions will be incompatible
> with new ones due to symbol renaming (arguments/return values are now
> passed on using a location independant `STKn' rather than `s0x<addr>'
> in order to enable library reuse across multiple devices).
>
> I am looking forward to hearing your opinions and bug reports as
> well as
> pointers to `most wanted features'.
>
> All improvements should be accessible starting with SDCC 2.5.4 #1130.
>
> Regards,
> Raphael Neider
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
