>>> [email protected] 28.1.2009 16:09 >>> >>>Hi Kustaa, >>> >>>I agree with you in part on this, but it is useful to have a clear answer >>>about the state of the compiler you're working with so you know what you can >>>expect. Its open source so it doesnt need to be sold, and i'm happier to >>>help improve it if I know what its like, rather than assuming its in a >>>stable state and getting disheartened. That was sort of my point: I want to know the state of a tool (sdcc in this case) and while it maybe fair to say something is (in someone's opinion) not (yet) professional quality it is more usefull to know exactly what are the problems (unless of course they are too numerous), rather than some general remarks, which will turn people off which in turn hinders the the development of the tool
>>> At the moment i'm trying to setup a >>>TCP/IP stack on a pic18f. The code doesn't compile on SDCC and the current >>>problem is the packed keyword used in the original C18 for a few structs >>>(I've just installed C18 in wine, but havent got as far as compiling it >>>yet). As I don't have much knowledge of the various compiler >>>implementations, its useful to know what issues i can expect to come across >>>with the PIC port. It looks to me like C18 is using some non standard C for >>>interrupts and data definitions, and I can't find info on how these are >>>implemented in SDCC. Interrupts seem to be described in the manual and have worked for me. I have not looked at the data structures for your TCP/IP so I should realy not comment on them but very of these types of issues can be circumvented with carefull use of bitfields (to simulate packed structures) and some macros. >>> The particular issues are interrupts in C18 being >>>definied in pragmas and inline code, and a few data structures being >>>declared as packed structs, which SDCC doesn't seem to like. As I said, that may well be doable and editing a few datastructure defs and turning a few pragmas to macros does not sound like a big job on the face of it. >>> Its been a few >>>years since I got really stuck into some c code, so i'm having to remember >>>alot of the details too. >>>On a slightly different note, i'm considering rewriting the tcp/ip stack >>>myself, as i could also (maybe) put in ipv6 support at the same time. Is >>>this as silly an idea as I think it is? or is it quite straightforward once >>>i've got some code to handle the ethernet interface? Don't want to call you silly ;-) but no, I would not advocate doing it. There are already enough TCP/IP stack implementations many of which are not maintained and have various problems. Please do not create a new one. Creating a TCP/IP stack and getting it bug free is not trivial. I have some first hand experience with lwIP stack and while it works, it has taken years. While I'm on this particular rant mode I have to say that I even wonder why the lwIP was created in the first place? I would have thought that starting from some BSD/Linux stack would have made more sence. Well, maybe it was a lisencing issue. But still. Trying to port lwIP to PIC might make sence, I've looked at the code and it seems rather straight forward C and it has been ported (IIRC) to even to the Lego Brick. And the comminity seems to be active and larger than Microchip TCP/IP community. Not to mention doing everyone a favor and supporting a more open lisencing that Microchip TCP/IP which seems to allow use on Microchip hardware only. And like I said there are other stacks out there. Just my 2snt worth, br Kusti >>>Regards >>>Peter 2009/1/28 Kustaa Nyholm <[email protected]> > > > >>> [email protected] 28.1.2009 0:51 >>> > >> I didn't mean to insult SDCC or spread FUD. I'm simply repeating > >>what's pointed on the SDCC webpage (work-in-progress), documentation > >>(lack of extended instructions, not all tests pass), and various > >>discussions on this mailing list (inline breakage, and your own > >>message about __critical missing). > Good, I like concrete examples of shortcomings, forewarned is > forearmed. > > For example: > > (from SDCC webpage) work-in-progress: not very usefull info. > This may indicate that the developers thought the compiler is > still not upto standard or that they are simply lacking confidence, > or they wanted to wash their hands. > > Lack of extended instructions: nice to know but if the compiler > works just fine without them, then this boils down to sub-optimal > code generation or performance of the generated code issue and > in embedded projects this is often clear cut. Either the code > is fast enough or not. > > inlike breakage: again very usefull to know as most of the time > the code write can just circumvent this. > > not all tests passed: not very usefull, would have been nice > to know which tests and what are the inferred implications > of not passing all tests. > > > >> SDCC is a fine compiler and I've > >>used it quite successfully on the 8051 side of things, but it's > fairly > >>clear that the PIC port is not solid yet. Trying to port C code to a > >>new platform without known-working code, guides, or detailed > >>documentation with issues like these makes development less than > >>straight forward. > > Agreed but and you maybe right that PIC port is not solid yet, on the > other hand I just worked a year using Blackfin processor and VisualDSP > IDE and the silicon and the VisualDSP (version 5.0!) did not left with > a warm and fuzzy feeling of being solid yet. (And yeah, I've got > 80 item long list of concrete issues with the IDE and Analogs silicon > anomaly list speaks for itself.) > > >> FYI, I've using the PIC18 side of SDCC about a 12-18 months ago. > It > >>took quite an effort to get some non-trivial code to work with SDCC; > >>way more effort than what is acceptable in a professional > environment. > I can say the same about the afore mentioned VisualDSP project! > > >>This is why I consider users of the PIC port as pioneers. > > You maybe right there. Seems like I've picked the right tool. If there > is > an easy way and a hardway, why pick the easy way... > > cheers Kusti > > > > > On Tue, Jan 27, 2009 at 4:10 AM, Kustaa Nyholm > <[email protected]> wrote: > > Hi, > > > > being, at least lately, partially responsible for creating the noice > on > > this list > > in regards to PIC18/SDCC I felt I need to comment on this: > > > >>>> [email protected] 27.1.2009 4:51 >>> > >>>but from what I've read on this mailing list, SDCC has a number of > > PIC18 > >>>> shortcomings. You're going to be a bit of a trailblazer here. > > > > Wiile I'm sure there are shortcomings in SDCC as well as in all > other > > compilers weather it is Keil or Gnu gcc or what have you, I'm not > > confortable > > with an off hand remark like this putting down the PIC18 port of > SDCC. > > > > I'been a long time lurker on this list and it is easy to get the > wrong > > impression > > by casual looking at the mailing since by the very nature of this > sort > > of > > activity we only hear about problems. And very often the problems > turn > > out to be problems somewhere else than in the SDCC and not everyone > > takes the trouble report solved problems, and even fewer report that > > "I've been using SDCC for years without any problems thank you very > > much". > > > > I've used both HC08 and PIC18 ports and while I've had my share of > > problems, none of them have turned out to be even indirectly related > > to SDCC, let alone turned out to be bugs in the compiler. > > > > If there are specific pin pointable problems with any of the ports, > > let us by all means discuss them, but please lets keep from > refraining > > general derogatory comments that contribute nothing but > > spread FUD. > > > > > > > > So there. > > > > br Kusti > > > > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > _______________________________________________ > > Sdcc-user mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > > > > -- > > - Tristan > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Sdcc-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Sdcc-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sdcc-user > ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Sdcc-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sdcc-user
