I2C auf dem MSP430

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.