on the I2C and HD44780 ideas, i made a while back a form of both... i
tried to make it as open as possible, allowing for all possible devices
that use the same interface. I don't have a couple things working like
checking if the display is buisy or not (4-bit interface doesn't seem to
work, 8 does, but i haven't tested extensively).

I've tested the I2C system with the TMP100 temperature sensor and a 64kbit
flash device and they work perfectly.

The display code i've tested with two optrex displays, a 1x16 display and
a 4x20 one. both displays i've tested with both 8-bit and 16-bit
interfaces.

If people want to take a look at them or anything, i can hand them the
files and examples.

      Matthew Peters




On Sun, 30 Nov 2003, georg wrote:

> Dear Steave!
>
> Incredible, what a great step for the mspgcc concept, package, toolchain
> or what ever we should call it. Thank you!
>
> Perhaps it's the right place to step in with an idea or suggestion,
> that is floating in my mind for a while now.
>
> 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.
>
> I know that there are lot of examples around the net and also in the TI
> appnotes. But they are either of poor software design (seen really ugly LCD
> routines) or they are incomplete. I²C e.g. normally just hacked together
> mostly not sticking to the philips specification in error handling and
> retries, timings etc. Wouldn't it be great if you could pull a full
> grown I²C lib from somewhere that has everything and can be shrinked to
> your needs, but would also do the full interface job (slave!) in a ready
> to go quality?
>
> 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)?
>
> I'm thinking of www.opencores.org, they have a very good approach and
> reached a lot already. Lot of research people and students (groups) work
> on projects, as do very experienced VLSI designers.
>
> It would be great to get a place running where standard problems,
> interfaces etc. for uC controllers are addressed.
>
> 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.
>
> 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.
>
> What do you think? A lot of things are in cvs already...
>
>
> Greetings,
>
>     Georg Ritter
>
>
> Steve Underwood wrote:
> > Hi all,
> >
> > The mspgcc examples hasn't seen a lot of activity lately. I thought it
> > was time to change that. :-) I have adapted all the TI packages of
> > MSP430 example code to work with mspgcc.
> >
> > For the C examples, only minor changes were needed. The syntax of the
> ...
>
>
>
>
> -------------------------------------------------------
> 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
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
>


Reply via email to