From: James H. D. <ja...@da...> - 2003-12-01 10:45:07
|
Hi All, How about a peer-to-peer scheme where, still using the I*C example, there could be an I*C directory where those who so desire could contribute their code. Perhaps the only requirement would be a "this works for me" statement. Each example should have a clear description at the beginning of pins, timers, etc. used in ther implementation (as most examples already have). Then users could select which scenarios best suited their own projects. And, of course, there would be no way to actually guarantee that the code was good - but the mailing list could be used to notify/resolve bugs. The idea of standard bit-twidling macros (and, why not, other peripherals too) is also good. It contributes to the "mspgcc way". Cheers, James > -----Original Message----- > From: msp...@li... > [mailto:msp...@li...]On Behalf Of Chris > Liechti > Sent: domingo, 30 de novembro de 2003 13:24 > To: msp...@li... > Subject: Re: [Mspgcc-users] Examples > > > georg wrote: > > > Perhaps it's the right place to step in with an idea or suggestion, > > that is floating in my mind for a while now. > > you're not the only one with that idea ;-) > > > Most people here have again and again the same needs on the > software side > > while working with the MSP430. Libraries for I²C, error > correction, writing > > to a HDD44780 LCD display, accessing MMC cards, etc. these are FAQs. > > > > Why not go the step further and include such things into > the "package" and > > develop them together, address them once and forget, go on > and evolve. > > This would save everyone a lot of time, that could be > invested at the other > > sides of your project. > > some sort of library would be nice, but it not that easy. > everything must be configurable, e.g. th character LCD has 7 wires if > you use the 4 bit bus, 11 with the eight bis bus and there are many > different ways to connect them to msp430 ports... even a > simple delay() > function cannot be made for everyone. you could make it with > a for loop > and count cpu cycles, or you could use the timer A or B or even the > watchdog timer. then with the timer it could go into one of lowpower > modes to save energy... > > this basicaly means that we cannot make a binary library that > simply can > be linked to the project. there are too much things that > change for each > project. and if the binary would be configured through some > functions/descriptors it would be much larger in code than it > could be. > > i think whats possible is to make a source code library with code > snippets that can be copied over to the own project. here you can get > easy customization and a small memory/flash footprint. > > what's needed to work out is a simple system, e.g. that a > hardware.h is > included oin each module. then a naminge scheme has to be > defines. how > are ports acessed? you can make port and bitmask macros or > one macro for > set and clear, which one should be used in the lib... > > [...] > > Of course you can buy things like that, and that is now a > question to you > > all. Do you think that real and well done libs are of such > a high value, > > that they cannot be done in GPL (or whatever license that > allows free and > > commercial use)? > > MIT license is a good fit. > > [...] > > It would be great to get a place running where standard problems, > > interfaces etc. for uC controllers are addressed. > > what we have so far, are examples on how to do many things on a MCU. > as mentioned above, it not so easy to make a library from > which you can > take code without much changes and use it in your project. > > > I think to get such a thing going would only work if a project like > > the "I²C-lib" is assigned to one responsible person with > high enough > > skills, > > experience in programming and the uC field. So he "supervises" the > > suggested changes and keeps up the quality. > > and most important, it shoud be somebody that actualy uses it ;-) > > > People who start working with this, don't start at 0 but at > the level > > that is there and are expected to improve from there and so help to > > converge and error test the things. At a certain point it becomes > > stable and other problems could be addressed, like adding cerain > > I²C node access protocols. > > chris > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SF.net Giveback Program. > Does SourceForge.net help you be more productive? Does it > help you create better code? SHARE THE LOVE, and help us help > YOU! Click Here: http://sourceforge.net/donate/ > _______________________________________________ > Mspgcc-users mailing list > Msp...@li... > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > |