Rnbfra Multi-Thread und Netzwerkfähig mit GUI im www, jetzt

So, wieder mal ein Zwischen-Status.
In der ZIP
RNSI2C Folder Coprozessor-Zeugs
RN_COMM Folder Atmega32-Zeugs
BASC_LIB Folder div. Libraries
RN_Server.exe PC Appl.
RN_ADC.exe PC adc 0-4 auslesen und zeigen
RN_CLIENT.exe PC Servo-#1 bewegen
XVH1.exe PC Radar Servo#1 mit GP2D12 auf adc-1 (!)

Hinten und vorn Demo-Sauhaufen-Unstrukturiert-Programme

Wesenlich nach wie vor die messages und nicht sosehr, was sie tun.

RADAR bewegt Servo #1 hin und her
und liest GP2D12 werte von ADC # 1 (nicht von #0, der ist kaputt bei mir)

Anschauen und staunen, mehr is im Moment nicht drin'.

Gute Güte
Präsente für einige Kurzweil.
Sobald mich die niederen Alltagspflichten aus den Klauen lassen, werde ich mich sofort dran machen.
Klarer Fall das hier alles Baustelle ist.

Vorab den besten Dank für die Kollektion.

Netter Gruß

Zitat:

---

..niederen Alltagspflichten ..

---

Schon wieder mähen ?

Übrigens RADAR: ich bin absolut unglücklich mit dem erreichten Ergebnis. Irgendwie flattert der Output vom GP2.. und die Umrechnung auf cm ist offenbar auch unter der Sau. Ich muß mir nach unserem Netz-Massaker unter Laborbedingungen die Sache mal zur Brust nehmen.

Zur Erläuterung:
IP-seitig wird verwendet:

16-Bit Anzahl Bytes, die nun folgen
8-Bit Zieladr Klasse
8-Bit Zieladr Ident
8-Bit AbsAdr Klasse
8-Bit AbsAdr Ident
x-Daten

Ich hab noch kein "NAK" eingebaut, wenn das Ziel nicht gefunden wird. Da haben wir ja noch kein allgemeines Format vereinbart.

Die ADC schicken als Anwort ihren Getadc() Wert als 16-Bit Daten
(82 00 ---> 82 07)


Die Servo (53 00 ---> 53 09) kriegen
8 Bit = &H01
16 Bit Position (dez. 600- 2000)

Mähen:
Die Vogonen haben ja versprochen das Rasenwachstum demnächst auszuschalten. Dann habe ich mehr Zeit an meiner Rasenmäh-Zukunft zu basteln.

Danke, dass Du das noch mal so sorgfältig auseinandergeklappt hast.
Mir hilft so was ungemein.
auch so Doppeldefinitionen in dez. und hex. Da sehe ich gleich ob die Zuordnung und Umrechnung in meinem Programm geklappt hat. Auch wo der Wert steht, ob im Low oder High Byte.
Außerdem ist lieb das Du dem Nachwuchs schon mal eine Längenangabe spendiert hast :-)

ADC:
Joggele maulte auch schon rum was denn nu mit der Genauigkeit bei dem GP2 wäre. Er hatte es mit einem ganz anderen Programm ausprobiert. Ich kann mich erinnern als ich mal so was aufgebaut habe da war auch irgendwas nicht so richtig. Wäre interessant was es damit auf sich hat.


Netter Gruß

Zitat:

---

..eine Längenangabe spendiert ..

---

Ja, so bin ich halt :-)

Getadc(): Wird werden den Manf einspannen, der liebt das elektrische Erbsenzählen :mrgreen:

@PicNick:
Danke, das mit den kompletten Libs hat prima geklappt.
Mein Compiler macht wie er soll.
Ich weis nicht, was es war, aber wenn man es auf diese Art nicht rausfinden muss ist mir das ganz lieb.
Deiner kleine TCP/IP Herde geht es prächtig, alle verstehen sich und schwadronieren miteinander rum.
als einziger ist der CoController noch nicht so recht bei der Sache. Aber das wird daran liegen, dass ich ihm noch nicht die richtige Weisung eingespielt habe.
Dieser Post ist jetzt nicht als Aufruf zur Fehlersuche gedacht, das mach ich schon alleine noch richtig. Ich wollte nur mal melden, dass die Sachen nicht achtlos in der Ecke liegen wenn von mir nichts zu hören ist.

Netter Gruß

Immer mit der Ruhe, wir haben ja alle unsere peripheren Störfaktoren.

Btw: Beim Coprozessor ist mir folgendes aufgefallen: Beim Brennen wird öfters mal der EEPROM als collateral-schaden vernudelt. Und wenn im ersten byte auf einmal 00 als I2C-Adresse steht, klappt die Sache dann nicht.
ggf. kontrollieren (read eeprom to Buffer, Edit &H68, write Eeprom)

Danke für den Tip jetzt läuft alles. Ein schöner Ausblick.
Du hast mit deinen Testclients früher eine GUI fertig als ich :-)

Netter Gruß