Hi, ich habe auf www.mathar.com/i2c.c eine I2C-Library für den MSP430F149 geschrieben. Damit betreibe ich gerade im Moment erfolgreich einen Temperatursensor TMP100 von Texas Instruments. Alle anderen I2C-Devices sollten natürlich auch kein Problem darstellen. Wenn ich Zeit finde, löte ich mal einen I/O-Extender (Typ PCFirgendwas ...) dran und teste den auch. Vielleicht kann es ja jemand gebrauchen ...
Was sicher für manche auch interessant sein dürfte: Die neueren msps ham i2c auch in hardware(15x und 16x). mfg Flo
Also über das lcd.c, in dem die wait-Funktion steht, solltest Du mal einen Prettyprinter wie indent laufen lassen; über 1 kB in nur einer Zeile ist etwas viel. Und es sollte dabei stehen, für welchen Compiler u. welche Compiler-Version der Code ist, denn da gibt's große Unterschiede.
Die wait(x)-Funktion wollte ich eh noch optimieren. Zur Zeit macht die ja einfach x nops in einer for-Schleife. Mit dem Timer geht so etwas sicherlich eleganter. Den Compiler habe ich nur auf meiner Homepage erwähnt (IAR Embedded Workbench), nicht in jeder Sourcecode-Datei einzeln, das stimmt. Sollte ich mal ändern ... Und was meinst du mit 1kb? Object-Code oder Source-Code? Ich habe doch im reinen Plaintext fast nie mehr als 70 Zeichen pro Zeile. Und was der Compiler daraus macht, ist doch nicht meine Schuld. ;-)
Also die lcd.c besteht aus nur einer Zeile und weil darin //-Kommentare drinn sind, ist die beschädigt; man muß da dutzende Zeilenumbrüche manuell vornehmen und anschließend indent drüberlaufen lassen. Bei IAR-Compilern ist noch die Version wichtig, denn die sind untereinander inkompatibel.
Ach so meinst du das. Hm, dann macht einer von uns beiden was falsch. Bei mir hat die lcd.c ziemlich viele Zeilen, jede Zeile wie gesagt max. um die 70 Zeichen breit, mit CR+LF beendet, stinknormaler Sourcecode eben. Dann mit Ultraedit gespeichert und mit WS_FTP auf einen Linux-Server hochgeladen. Kann das Problem vielleicht noch jemand bestätigen?
Ok, nun stimmt's; vielleicht ist irgendwas bei dem einen Download falsch gelaufen. Und die wait-Funktion solltest Du mal ungefähr so umbauen, damit man die Wartezeit einstellen kann: // Aktives Abwarten von Millisekunden. void wait_ms (const unsigned int ui_steps_ms) { volatile unsigned long int uli_down_counter = 482; // Gemessen mit Oszilloskop für ui_step_ms=1, 100, 10000. // Gemessen mit MSP430F149 + 8 MHz Quarz; ist ohne (d. h. 4,8 MHz DCO) 290. uli_down_counter *= ui_steps_ms; while (uli_down_counter--) // busy waiting { }; return; } Man kann das Abwarten auch per Timer machen, aber damit belegt man eine weitere Resource und die "saubere" Lösung wäre eigentlich ein Scheduler, der in dieser Wartezeit andere Prozesse laufen läßt.
Bei mir ist der c-code den ich mit kate schreib unter windoof auch nur eine zeile. Das liegt an dem Programm mit dem man öffnet. mfg Flo
Das liegt an der unterschiedlichen Zeilenende-Markierung von Unix und Windows (Carriage Return und Linefeed).
Ja, unter MacOS hat man wieder andere Zeilenenden. Deshalb gibt's ja zumind. beim Linux die Funktionen unix2dos, dos2unix, mac2unix usw.. Programme wie Wordpad konvertieren von Unix automatisch nach DOS, aber die konvertieren nicht zurück. Das ist lästig, wenn man die Sachen unter Unix/Linux wieder braucht. Das Revisionsverwaltungs-System MKS hat beispielsweise den Bug, das es ungefragt nach DOS konvertiert, was nur archiviert werden soll; zudem werden dabei noch die Dateinamen geändert; aus Großbuchstaben werden Kleibuchstaben.
Naja, unter Unix/Linux ist es das Zeichen '\n', unter DOS die zwei Zeichen '\n' '\r' und bei MacOS nur '\r': http://www.websiterepairguy.com/articles/os/crlf.html Beim OSX ist's wie unter Linux, weil OSX wie Linux ein Unix-Derivat ist. Das ist etwas pervers, denn wenn man unter Unix Zeilen für DOS/Windoof produziert, muß am Zeilenende \n\r gesetzt werden, während das unter DOS nicht nötig ist; da besteht das Zeilenendzeichen aus zwei Zeichen. Umgekehrt gibt's natürlich Probleme beim Einlesen von Dateien. Ich bevorzuge immer die Unix-Form, weil sie die erste Variante ist und auch weil die weniger Speicherplatz belegt.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.