Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
As I promised, this the pic14 and pic14e libio. It includes adc, i2c, pwm, spi and usart support. Of course, only they the devices which are knows the proper hardware function. (I tried to do a flawless job, we'll see how well.)
Too late I noticed that the patch is included in the sdcc-3.2.0.spec well. I do not wanted to send this. With this I create rpm package myself.
Thanks Karoly! This is a candidate to be included after the SDCC 3.2.0 release.
We will have to decide whether the io library should be a part of SDCC or should be published elsewhere as stand alone library. Currenly SDCC includes io library only for pic16 targets. The same concern applies for delay functions you submitted in patch #3526654.
> We will have to decide whether the io library should be a part of SDCC or
> should be published elsewhere as stand alone library.
What is the obstacle? Too large of the patch, or I sent too much lately?
> What is the obstacle?
The obstacle is mostly the purpose of the sdcc project. We want to provide a C compiler for small devices. We do not want to provide a complete libc (but we more or less do ...). And we do not primarily want to provide a large amount of library code, which we would have to maintain as well.
The question of whether the library is better integrated into the compiler (as is done, e.g., with the Microchip compilers, if I am not mistaken) or whether it should be put into a separate project is difficult to answer. For the PIC16 target, someone (might have been me, not sure) opted to add an I/O library, which caused a fair amout of headache due to the numerous mutually incompatible devices. The headaches continue with each device for which support is added to the compiler, as the complete I/O lib may have to be extended as well.
I am also not sure whether the existing libraries are used by a sufficiently large number of people to justify the effort. After all, the API (especially ADC) has become pretty complex with all these #if "your device fits here" blocks that tell you, what symbols you may use.
I have not yet looked at this patch; generally I would vote in favour of accepting I/O libraries.
To cut a long story short: Adding or not adding the library to the SDCC sources is more a political decision than it is a technical one.
> Too large of the patch, or I sent too much lately?
Large patches and numerous patches might cause delays in the acceptance process, but do not cause rejection of the contributions.
Actually, I wanted to create a support is like pic16 branch. I did not want more.
> I am also not sure whether the existing libraries are used by a sufficiently large number of people to justify the effort.
I see. Maybe it's not worth it at all.
Talking about libraries to be or not to be included in the compiler, I have an eeprom library for PIC16 which I was about to submit and then I found this topic. Would you consider it useful/appropriate for SDCC to have it included?
I think it would be nice, but I became uncertain due to comment of tecodev. Maybe it would be better separate the directories from the compiler. Somehow should be published and then people decide on they need it or not.