mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik eDIP kein 'DC1' in Antwort


Autor: E. F. (e-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi folks,

ich werde noch wahnsinnig. Ich möchte ein eDIP vom PC aus vi RS232 
ansteuern. Kommunikation funktioniert hervorragend, ich kann zeichnen, 
Text ausgeben ect. Jetzt möchte ich eine Touch-Taste anzeigen lassen und 
deren Up-/Down-Event abfragen. Eigentlich klappt das ja auch. ABER: in 
der SPezifikation (siehe Anhang) steht, dass nach dem ACK (0x06) ein DC1 
(0x11) folgt. Tut es aber nicht. Alle anderen Daten sind (beinahe) 
perfekt ok. Das heißt, nach dem ACK kommt sofort die Länge der Daten (in 
meinem Fall 8, wg. Up/Down-Antwort in eeinem Paket) und danach die 
Prüfsumme. Die Prüfsumme verstehe ich beim Empfang auch nicht richtig. 
Die Routine müsste stimmen da ich sie beim senden auch einsetzte. Hier 
ein Auszug:

character received 8
006 012 027 065 001 126 027 065 001 127 027 065 001 126 175    164

Ganz hinten ist die Zahl die ich aus den empfangenen Daten errechnet 
habe und davor die Prüfsumme die vom eDIP kam.

Wenn ich den eDIP Simulator via com0com mit meinem Programm benutze, 
kommt exakt das Selbe raus. Als habe ich gedacht dass vielleicht im 
Empangspuffer das Zeichen verloren geht und habe Portmon von 
Sysinternals benutzt um den Port zu "belauschen" und auch dieses 
Programm bescheinigt mir: nach dem ACK kommt die Länge und nicht DC1.

Autor: E. F. (e-f)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ähhhm, wegen der Vorschau ist der Dateianhang wieder "rausgeflogen". 
Hier ist er.

Autor: E. F. (e-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, interessanterweise funktioniert das mit dem DC1 wenn ich die 
Puffergrößen anfordere.

Autor: E. F. (e-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interessant, wenn ich in meiner Prüfsummenberechnung, in der ich für 
diesen Fall aus lauter Verzweiflung über das fehlende Byte das ACK (6) 
rausnehme (wie sich's ja auch gehört) und dafür das DC1 (17) reinnehme, 
passt die Prüfsumme ... da brat' mir doch einer 'nen Storch ... ;))

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo E. F.,

witzig! sitz grad an der selben sch... ,-)

wollt ma fragen ob du auf des rätsels lösung schon gekommen bist?
hab das edip auch soweit per KitEditor mit makros usw bepackt und 
befehle per atmega32 ans edip senden funktioniert auch, nur eben bekomm 
ich keinerlei antwort! bis auf eben als mir byteweise 0x00 geschickt 
wurde.
baudraten usw sind denk soweit auch ok, da es hinzugs ja auch 
einwandfrei funktioklappert!

frage? hast du J2 geschlossen (SmallProtokoll ausgestellt)? hab darüber 
was gelesen was für mich auch aber sehr unverständlich klingt???!!!

hättest du ma den genauen befehl im hex-format, den du ans edip sendest 
für den empfang des sendepuffers?

wär echt super! thx

gruß keniff

Autor: Atmega_8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn das Problem noch nicht gelöst sein sollte könnte ich mich 
vielleicht einschalten.
Hatte die letzten Wochen mit dem eDIP320 Erfahrungen gesammelt.

Das mit den Nullen hört sich so nach meinen Problemen an.
Hatte teilweise Probleme mit einigen Nullen oder Einsen sprich 00h oder 
FFh
statt der gewünschten Antwort.

Führt denn das eDIP die Funktionen aus die du sendest ?(@martin)
Was genau sendest du ?(Bitte mal den vollständigen hex code)


Gruß Alex

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hey danke atmega_8,

habs jetz soweit erstma hinbekommen, dass es mich versteht...

wenn das ding nur nich so verwirrend wäre! ,-)

aber trotzem ma danke

gruß keniff

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin seit eingen Wochen auch mit einem edip240 am experimentieren und 
bin doch sehr enttäuscht von dem Teil.

1. Es ist EXTREM langsam, steuere es über SPI und will da Messwerte 
anzeigen die aus je 5 Zeichen bestehen. Bei ca. 10 Messwerten wird das 
ganze sehr unpraktikabel da alles nur noch stottert weil das Display zu 
langsam ist.

2. Teilweise werden Befehle für die Grafikebene, auf der Termianlebene, 
trotzdem diese ausgeschaltet ist, einfach angezeigt. Wieso weiss 
niemand. Einmal beim 3. Wert, einmal beim 5000. Wert, völlig wirr...

3. Man kann den Empfangsbuffer nicht löschen. Super, ich hab ein Menu 
aufgebaut und wenn ich jetzt ins Main zurückspringe, wird der Buffer da 
erst entleert und es stehen die letzten Messwerte des Untermenus im 
Mainmenu. Das mit dem Warten vor dem Makro ausführen klappt auch nicht, 
da er dann die Daten die sich im Buffer befinden nicht ausgibt. Er 
wartet zwar, wechselt auf Main, und dann kommen die Daten, also 
unbrauchbar.

4. Die Zeiten des Displays sind nicht spezifiziert und das ist das 
Hauptproblem. Ich kann doch nicht jedes Mal diesen blöden Buffer 
abfragen um zu wissen ob ich jetzt noch Daten senden kann oder ob der 
Buffer bereits voll ist! Entweder müsste das über einen zusätzlichen 
Interrupt gelöst werden, oder dann müsste der Buffer einfach grösser 
sein. Der ist mit seinen 64Byte sehr klein bemessen. Ich warte mir jetzt 
einfach immer einen ab bis ich die nächsten Daten sende. Diese Zeit habe 
ich im Try and Error verfahren erarbeitet. Sie ist auch nicht für alle 
Befehle gleich lang. Ich kann mir vorstellen wieso sie diese Zeiten 
nicht ins Datenblatt schreiben, dann würde niemand dieses Display mehr 
kaufen, da schlicht unbrauchbar.

5. Die Geschwindigkeit: Also ich habe bereits vor 10 Jahren Displays 
eingesetzt die um Faktoren schneller waren und zu allem noch um einiges 
günstiger. Da sollte man ja schon von etwas "Neuem" erwarten können, 
dass es wenigstens die gleiche Performance bringt wie ein 10 Jahre altes 
Display.

6. Was mich am allermeisten nervt. Man schafft es ohne Probleme, dass 
der Touch Button kurz invertiert wird (Grafisch), wenn man ihn berührt, 
aber kein Interrupt generiert wird. Er speichert aber den Up/Down Code 
im Buffer ab, nur generiert er halt keinen Interrupt. Was das für ein 
Menu bedeutet kann sich jeder selber ausdenken! Ich habe über eine Woche 
an einer Routine geschrieben die genau diesen, ich nenne es jetzt mal 
sehr charmant: Fehler, umgeht.

Das beste ist, wenn man weiss wie man diesen Zustand nicht erhält:

Dieser Zustand entsteht beim leichten Berühren des Touch. Also so fein, 
dass zwar die Taste invertiert, aber kein Interrupt ausgelöst wird. 
Hämmert man aber mit den Fingern oder einem Stift auf diesem Touch rum 
sind die Probleme gegessen!!!! Und hier klemme ich, wie kann das sein. 
Er schaut ja auch auf den Touch wenn ich nur leicht drücke, sosnt würde 
der Button ja nicht invertiert...

Wie ihr seht bin ich sehr enttäuscht von dem Teil und werde es auch 
nicht mehr einsetzen.

Gruss Guest

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hey gast ,-)

also das display, oder zumindest sein datenblatt, ist echt mehr als 
bescheiden. man sollte schon erfahren das gewisse befehle wie "lösche 
display" sehr zeitintensiv sind (glaub was von ca 100ms);

wegen des eingangsbuffers hab ich noch keine erfahrungen gemacht. also 
wegen geschwindigkeitsproblemen usw. steh aber auch noch recht am 
anfang. was genau machst du da? schickst du ihm 10 strings mit den 
messwerten oder wie genau? also 10 mal den befehl, oder 1 befehl mit den 
10strings oder oder oder?

zu 6.
also bei mir funktioniert der touch erst dann , und zwar genau dann ,enn 
ich es berühr und sich der taster sichtlich invertiert. also nicht aufs 
arme edip schieben ,-)

die baudrate hast du denk auf 115200 laufen?!
glaub ja ma nicht das die geschwindigkeiten schon was mit der 
schnittstelle zu tun haben. hab mein display an rs232.

naja, wenn du weiter interesse am edip hast. einer zusammenarbeit 
spricht nichts entgegen ,-)

gruß ken123

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also das mit dem Touch der zwar anspricht, aber keinen Interrupt 
generiert kann ich auf zwei Displays nachvollziehen. Hab hier zwei von 
diesen Dingern liegen. Am Code kanns nicht liegen, denn selbst ohne uP, 
also nur Display mit Oszi am Pin20 zeigt das gleiche Verhalten. Da kann 
mir jeder sagen was er will ;o))))) es wird einfach kein Interrupt 
ausgegeben. Werde mich wohl mal mit EA in Verbindung setzen müssen.

Jaja, das liebe Datasheet... Da bleibt einem echt die Spucke weg wenn 
man so etwas sieht. Ich behaupte immer noch mit halb so vielen Seiten 
ganz klipp und klar die Funktion des Displays aufzeigen zu können. Das 
was niemanden Interessiert ist bis zum Umfallen abgehandelt, dass 
Interessante ist entweder extrem dürftig, oder gar nicht beschrieben. 
:o( Nun denn, anscheinend ist das mti den Displays wie mit dem Drucken 
im Informatik Umfeld. Da denkt auch jeder es ist keine Sache, aber auch 
so ein Drucker kanns in sich haben ;o)

Gruss

Autor: Mirko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

habe sein langerem 3 von diesen Teilen im Einsatz, die drahtlos via 
RS232 angesteuert werden. Als komplette Touch-Bedieneinheit sind die 
eDips eigentlich recht kompakt und komfortabel einsetzbar, bei 
vergleichsweise guenstigem Preis. Zum Thema Speed muss man sagen das 
Hochgeschwindigkeits-Anwendungen hier nicht drin sind- dennoch ist das 
Display in jedem Falle schneller als man im durchschnittlichen 
Anwendungsfall schauen und Button pressen muss :-)
Was mir nach wie vor unklar ist: Was soll bloss der einstellbare Timeout 
in den Protokolleinstellungen? Diese Zeit muss abgewartet werden, bevor 
ein (nicht vollstaendig empfangenes) Datenpaket wiederholt werden kann. 
Natuerlich will man doch moeglichst schnell fertig werden! Deshalb 
stelle ich immer 0 ein, in der (nicht bewiesenen) Hoffnung, dass es so 
am schnellsten geht wenn mal ein ACK nicht zurueckkommt. Statt dieses in 
meinen Augen ueberfluessigen Features waer mir was anderes sehr viel 
lieber: Eine Leitung naemlich, die verbindlich Empfangsbereitschaft 
anzeigen wuerde. Denn absturzsicher ist das eDip leider nach wie vor 
nicht, insbesondere bei fehlerhaften und unterbrochenen 
Befehlssequenzen, wie sie im Programmiereralltag und insbesondere bei 
fehlertraechtiger drahtloser Ansteuerung nun mal vorkommen. Das ist dann 
auch in meinen Augen der groesste Mangel dieses Displays.

Gruss Mirko

Autor: Holger T. (holgert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
auch ich stehe vor der Entscheidung für ein Touch-Display. Entgegen der 
von EA in der Werbung für eDIPs gemachten Versprechen schrecken mich die 
Kommentare hier im Forum eher ab, es damit zu versuchen - die SW scheint 
ja noch tiefstes Beta zu sein. Und das Fehlen von Handshake-Leitungen 
bei Vorhandensein eines Puffers kann ich überhaupt nicht verstehen (-> 
@Mirko).

Welche Alternative stehen zur Verfügung (bekannt ist mir nur iLCD) und 
welche Erfahrungen habt ihr damit gemacht?

Danke und Gruß
-Holger

Autor: E. F. (e-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich war ein paar Tage so in Arbeit vertieft, dass ich ganz vergessen 
hatte mal hier reinzuschauen ;)

@Atmega_8

Das Problem tritt nur bei einem einzigen Befehl, der im eDIP-PDF (Seite 
8) als  „Inhalt des Sendepuffers anfordern“ beschrieben wird, auf.

Ich sende „BYTE cmd[4] = { DC2, 0x01, 'S',  0x66 };“ - 0x66 ist die 
Checksumme und für diesen Befehl „hart“ codiert – alle anderen Befehle 
benutzen eine entspr. Routine um diese zu errechnen. Als Antwort, so 
steht es in der Beschreibung, sollte ein „ACK DC1 len data... bcc“ 
kommen, es kommt aber ein „ACK len data... bcc“. Wie schon gesagt, 
witzigerweise beinhaltet in dem Fall das bcc auch das fehlende DC1 …



Also, bis auf das o.g. Problem funktioniert das Ganze jetzt recht 
passabel. Aber: eben nicht wirklich richt gut. Meine momentane 
Implementierung ist in C++ für den PC geschrieben da ich das Display an 
meiner Haussteuerung betreiben möchte. Am allermeisten fällt auf, dass 
das Teil quälend langsam ist. Weiterhin, wie mehrfach angemerkt, ist das 
Fehlen eines Handshake-Signales sehr kontraproduktiv. Dass die Daten aus 
dem Ausgangspuffer praktisch „gepollt“ werden müssen macht das Handling 
auf der einen Seite nicht wirklich einfach und ist außerdem auch 
langsam. Ich „polle“ im Moment mit ca. 6/sec.
Als Tipp für alle die sich mit dem Teil beschäftigen wollen: das 
Zusammenfassen von Befehlen (im PDF unter „DATENÜBERTRAGUNGSPROTOKOLL“ 
Seite 8 kurz bemerkt) hat bei mir erheblich zur Lösung beigetragen. Ich 
habe einen Screen, den ich auf dem eDIP darstelle, der Temperaturen 
anzeigt, die aller 5sec aktualisiert werden. Dabei entstehen so viele 
Befehle, dass wenn einzeln versendet, die Zeit gar nicht dafür reicht. 
Nachdem ich die Software entspr. Geändert hatte (um Befehle 
zusammenzufassen) war der Bildschirmaufbau in einem Bruchteil der Zeit 
erledigt. Ach ja, noch ein Tipp: für solche Screens ist es vorteilhaft, 
vor dem ändern des Bildschirminhaltes, diesen in das interne Clipboard 
zu übertragen, das Clipboard anschließend auf dem Screen anzuzeigen, 
seine Ausgaben erledigen (die dann im Hintergrund passieren) und dann 
wieder auf den „echten“ Screen zurückzuschalten. (Side-Note: diese 
Methode nennt man „double-buffering“ und kann bspw. unter Windows mit 
dem bekannten MemDC.h genau so verwendet werden um „flickering“ zu 
unterdrücken).

Die Software kurz beschrieben: Zuerst habe ich alle Befehle, die das 
eDIP verarbeiten kann, in einer Klasse definiert. Dann gibt es eine 
Basisklasse, die einen Screen definiert (z.B. aktiver Bereich, in dem 
„gezeichnet“ werden kann, Ausgaben im „Kopfbereich jeder Seite, wie z.B. 
Uhrzeit usw.) Davon habe ich dann die einzelnen Screens abgeleitet. Ein 
„eDipManager“ (als Singelton ausgebildet) kümmert sich dann um die 
Umschaltung der einzelnen Screens bei bestimmten Events (entweder vom 
eDIP selbst – also wegen eines Tastendrucks, oder aber von außen, z.B. 
bei Telefonanruf, Störung usw.).

Autor: E. F. (e-f)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Für alle, die sich damit beschäftigen, hier ein paar Bilder um Mut zu 
machen ;)

Autor: E. F. (e-f)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, vielleicht sollte ich die einzelnen Screens kurz kommentieren: 
das vorherige Bild ist sozusagen der "Einstiegsbildschirm" oder im 
angelsächsischen auch "Home" genannt ;)

Der nächste, also dieser hier, ist eine Verteilung auf die Funktionen 
rund ums Haus.

Autor: E. F. (e-f)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
... weiter geht es mit der Verteilung der einzelnen Etagen.

Autor: E. F. (e-f)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
... wir sind im Keller angelangt ...

Autor: E. F. (e-f)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
.. und hier das erste wirklich Highlight: mein Arbeitszimmer indem ich 
bereits über das eDIP die Beleuchtung steuern kann und - die kleinen 
"Glühlämpchen" reflektieren den entsprechenden Zustand übrigens auch, 
wenn am "normalen" Schalter neben der Tür Lichter ein-/ausgeschaltet 
werden.

Autor: E. F. (e-f)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier der erwähnte Screen für die Temperaturen, die von DS18S20 Sensoren 
kommen und in der letzten Ausbaustufe dann 32 an der Zahl sein werden - 
dann aufgeteit auf 2 Screens.

Autor: E. F. (e-f)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Diesen Screen hätte ich vielleicht vor dem vorherigen zeigen sollen, er 
ist für die Verteilung der einzelnen Infoscreens zuständig.

Autor: E. F. (e-f)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Der Screen ist auch recht interssant, hier kann ich online die aktuellen 
Verbrauchswerte ablesen. Da mein Arbeitgeber die Stromkosten für meine 
IT bezahlt, habe ich dafür einen extra Zähler.

Autor: E. F. (e-f)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Der Verteilungsscreen für die Garage.

Autor: E. F. (e-f)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Und als letztes Beispiel der, noch unvollständige, Screen für die 
Außenanlagen.

Autor: E. F. (e-f)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja, zu erwähnen vielleicht noch, daß die Buttons jetzt nach und nach 
gegen Symbole ausgetauscht werden, was eine Menge "Pixelarbeit" 
bedeutet. Die Symbole für den Screen der Info-Verteilung habe ich so 
weit schon mal fertig.

Autor: E. F. (e-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch was: das Teil, so wie auf den Bildern läuft jetzt Tagsüber (ca. 
16h) auf meinem Schreibtisch zur Probe - im Moment ohne Abstürze oder 
sonstige Probleme. Das erste Display kommt demnächst im Wohnzimmer in 
die Wand.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Respekt! Da krieg ich doch gleich nochmal mehr Lust, da dran weiter zu 
arbeiten. Auch Deine gezeichneten Icons gefallen mir sehr gut :-)

Mir ist übrigens aufgefallen, dass ich o.a. Probleme auch hatte (ich hab 
SPI-Verbindung). Sprich seeehr langsam, wirre Zeichen im Terminalmodus 
obwohl dieser aus war, etc.
Abhilfe schaffte jetzt bei mir (bei gleicher Software und gleichem 
Display) das Wechseln der Signalleitung. Ich verwende jetzt ein 
10poliges Flachbandkabel und das Ding werkelt im Dauerbetrieb ohne auch 
nur ein falsches Zeichen auszugeben oder eine erkennbare Verzögerung 
beim Ausgeben der Zeichen zu haben.

Bin mal gespannt, wie's mit der Touch-Funktionalität läuft. Da mach ich 
mich als nächstes ran :-)

Autor: Martin S. (keniff)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hier auch noch ein beweis dass das eDIP keine hexerei und teufelswerk 
ist ^^

gruß keniff

Autor: E. F. (e-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Supi ;)

Freu' mich, dass es noch mehr "Leidensgefährten" gibt. Ansonsten findet 
man nicht viele Foren o.ä. die sich mit dem Thema beschäftigen.

Die Touchfunktion war gar kein so großes Problem, ich polle in einem 
extra Thread die Größe des akt. Ausgangsbuffer und wenn er Zeichen 
enthält hole ich ihn ab, die Daten wandern dann durch einen Filter - 
hier würde dann der Filter für die Touchfunktion zuschlagen - und am 
Ende habe ich die für den Button (Up/Down) vergebenen Codes. Ich hab' 
das dann noch so gelöst, daß ich alle Button-Werte, die über 0x80 
liegen, direkt als Screen-Nummer ( minus die 0x80 ) interpretiere - so 
kann ich ganz leicht von einem Screen zum nächsten springen. Die 
"Zurück"-Funktion ist etwas schwieriger, dafür habe ich einen Stack, der 
die Screen-Nummern enhält.

Alles keine Hexerei – das wichtigste ist dass die Kommunikation als 
solche erst einmal verlässlich funktioniert – sonst sucht man sich "dumm 
und dusselig" ;)

Autor: E. F. (e-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe bis jetzt den "USB Programmer for EA .." für das Teil benutzt. 
Für alle die's nicht kennen: besteht im Prinzip aus einer Platine (etwas 
größer als das eDIP selbst) mit einem FT232 (USB<->RS232), einem Buzzer, 
einer USB-Buchse, einem Reset-Taster und einem Jumper (DPOM). So, jetzt 
wollte ich das eDIP auf eine eigene Platine bauen (mit RS485, 
zusätzlichem EEPROM, LED's usw.) und da fängt auch schon das nächste 
Problem an: die Steckverbinder, mit der das eDIP auf dem o.g. "USB 
Programmer ..." gesockelt ist, finde ich nirgends. Das Problem ist, dass 
die "Beinchen" des eDIP so dünn sind, dass sie in "normalen" 
Buchsenleisten keinen Halt (und auch keinen Kontakt) bekommen. Kennt 
einer von Euch diese Teile und weiß wo man sie herbekommt? (Reichelt, 
Segor, Conrad).

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hey jo,
meinst du ganz normale Kontakbuchsen?

bei reichelt:
SPL 64 :: IC-Fassung, 64-polig, einreihig, RM 2,54, gerade
oder SPL20 / 32

hoff du meintest die dinger, hab so zumindest das edip auf nem ganz 
normalen lochraster untergebracht!

gruß keniff

Autor: E. F. (e-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast Du's gelötet - oder gesteckt? Die ganz normalen Kontaktbuchsen, wie 
gesagt, halten die kleinen Beinchen des eDIP nicht richtig. Die Beinchen 
für die normalen Buchsenleisten haben 0.65mm - die vom eDIP 0.4mm. Die 
Buchsenleiste auf dem USB-Programmer hat 1.27mm Kontaktabstand - aber 
nur jedes zweite "Loch" trägt einen Kontakt.

Beste Grüße,

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hey nabend,

ehm gute, frage nächste frage?! ;-)

nee, denk ma das sinn normale steckleisten für ics! weiss jetzt aber 
auch nicht genau obs unterschiede gäb zwischen abstand usw. also 
sicherlich, aber dachte ma, dass sind die, die ich auch drauf hab! da es 
auch die einzigsten sind die bei reichelt im katalog stehn.
aber wenn du bis morgen warten kannst? frag da nochma ein kollegen auf 
der arbeit! der is profi in sowas ^^

gruß keniff

Autor: E. F. (e-f)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nabend ;)

ich hab' mal noch ein Bild gemacht, besser gings leider auf die Schnelle 
nicht. Vielen Dank für Dein Angebot - kann selbstverständlich bis morgen 
warten ;)

Beste Grüße,

Autor: E. F. (e-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Äääähm ach ja, sorry. Auf dem Bild ist rechts die "feine" Buchsenleiste 
vom USB-Programmer zu sehen - und links die "normale" Buchsenleiste (die 
"lehnt" praktisch nur so an der Platine).

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm die gedrehten IC-Sockelleisten:

http://www.reichelt.de/?;ACTION=3;LA=2;GROUP=C131;...


Peter

Autor: E. F. (e-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für den Tip und den Link, so etwas in der Art "schwebte" mir 
auch vor, wusste nur nicht dass es die Teile auch einreihig gibt. Man 
lernt nie aus ;)

Danke!!!

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm das wusste ich auch noch nicht. Ich hab einen normalen 40poligen 
IC-Sockel genommen und mit der Zange so bearbeitet, dass ich 2 einzelne 
20polige Buchsen hab. Das läuft perfekt und sitzt fest :-)

Autor: Gast (Florian) (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ALso hab das hier mal interessiert gelesen. Ich wollte nur mal in den 
Raum werfen, dass bei mir ein DC1 gesendet wird. Ich habe das genannte 
Problem also nicht.

Autor: Holger T. (holgert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast (Florian) wrote:
> ALso hab das hier mal interessiert gelesen. Ich wollte nur mal in den
> Raum werfen, dass bei mir ein DC1 gesendet wird. Ich habe das genannte
> Problem also nicht.

Könnten "E. F." und "Gast (Florian)" bitte mal die Firmware-Version 
auslesen (Befehl lt. Datenblatt ESC S V)? Vielleicht zeigt sich da ein 
Unterschied.
Danke und Gruß
HolgerT

Autor: E. F. (e-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also mein eDIP fördert auf Anfrage folgendes ans Tageslicht:

EA eDIP240-7 V1.4 Rev.B TP+

Autor: E. F. (e-f)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Holger

Du hast erwähnt, dass Du noch vor der Entscheidung stehst, welches 
Display Du verwenden wirst. Falls Du Dich immer noch nicht entschieden 
hast, würde ich mich der Entscheidungsfindung gern anschließen. Obwohl 
ich mit dem eDIP relativ weit gekommen bin - ganz glücklich bin ich 
damit nicht. Die Gründe dafür sind:

- relativ teuer (relativ ist hier wortwörtlich gemeint - in Bezug auf 
den Funktionsumfang)
- 1Bit Farbtiefe beschränkt den Designraum erheblich
- Auflösung (zu gering) behindert die eine oder andere Lösungsidee
- Stabilität

In der letzten elektor ist auf Seite 16 eine mögliche Alternative 
(www_eigergraphics_com) zu sehen. Zwar 50€ teurer als der günstigste 
Pres des eDIP, dafür aber eine ganz andere Liga. 6,4" mit 640x480 und 
3x5Bit Farbtiefe. Das Teil sieht echt gut aus. Es gibt aber (sicher) 
noch eine ganze Reihe anderer Möglichkeiten.

Autor: Martin S. (keniff)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hey E. F.,

>
>In der letzten elektor ist auf Seite 16 eine mögliche Alternative
>(www_eigergraphics_com) zu sehen.
>

hab mir das eben ma angeuckt... is das en witz oder is das ding wirklich 
so der hammer? im gegensatz dazu is das eDIP ja müll, im wahrsten sinne 
des wortes!!! hoff das die programmierung auch so einfach und sauber 
funktioniert wie in dem beispiel video! werd da morgen ma mit meim 
cheffe reden...
hast du da zufällig schon erfahrungen mit gemacht? oder auch noch am 
überlegen?!

die zweite frage die ich an dich hätt wäre folgende:
sitz hier immer noch am eDIP, hab lauter untermenüs usw geschrieben, da 
das eDIP als steuerung für eine maschine dienen soll. nur hab ich jetzt 
das problem, dass mir die idee fehlt wie ich werte/einstellungen in ner 
variable per touch ändern und an den µC weitergeben kann!
im moment löst jede touchberührung ein interrupt aus, auf welchen ich 
dann reagier und zB ein neues menue aufruf...
nur wie würd ich das machen wenn ich zB ne zahl von 0-100 per 
+/-touchtaste abändern will und den gewählten wert abspeichern? würd ja 
gern jeden wechsel der zahl am display angezeit bekommen usw usw
hoff du verstehst mein problem und kannst mir da weiterhelfen?!!!

vielen dank

gruß keniff

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle zusammen
da ich hier hoffentlich jemand gefunden hab der mir weiter helfen kann 
mit meinem Edip. Ich hab vollgendes Problem ich kommunizierer mit dem 
Edip über die SPI Schnittstelle. Die kommunikation läuft fehler frei und 
ich kann über die Schnittstelle Linien zeichnen, Bargrphen verändern 
bereiche löschen aber ich schaf es nicht einen Text auf das Display zu 
schreiben.
Wenn ich denn Befehl übermittle bekomm ich zwar nen ACK aber es tut sich 
nichts!
Ich verwende einen XC164CM hab davon mal das Prog reingestellt.
#include <XC164.h>


void berechnung_spi (void);
void analog_init (void);
void spi_init (void);
void senden (void);
void adwandlung (void);
int bar[]={0x0011,0x05,0x1B,0x42,0x41,0x01,0x2f,0x00,0xff};
int 
text[]={0x11,0x09,0x1b,0x5a,0x4C,130,40,0x31,0x32,0x33,0x00,0x00,0xff}; 
//Am display soll an die Stelle x 130 und y 40 1 und 2 stehen
unsigned long test;
int adwert=0;
int bcc;
/*-------------------Hauptprogramm------------------------------*/
void main (void)
{

analog_init ();
spi_init ();
while(1)
  {
  adwandlung();
  berechnung_spi();
  senden();
  }
}

/*--------------------Analog-Schnittstelle einstellen----------------*/
void analog_init (void)
{
P5DIDIS=0xFF;            //P5 von Digitaleingang auf Analogeingang 
umgestellt
ADC_CON=0x7017;              //AD Wandler definiert
ADC_CTR0=0x0017;          //AD Wandler eingestellt start mit Port 5.7
}

/*--------------------SPI-Schnittstele einstellen----------------*/
void spi_init (void)
{
  DP1H=0x0C;          //Ein- und Ausgänge auf DP1H einrichten
  ALTSEL0P1H=0x0F;        //Alternativ Port für DP1H auf SPI Modus 
einstellen
  DP1L=0xfb;          //DP1L auf Ausgang einstellen
  SSC1_CON_EN=0;          //SPI1 Register Schreibschutz entfernen
  SSC1_BR = 0x05ff;        //Baudrate defenieren
  SSC1_CON = 0xC057;        //SPI1 Register einstellen
  SSC1_CON_EN=1;          //SPI1 Register Schreibschutz aktivieren
  SSC1_TIC=0x0086;
  SSC1_TIC_IE=1;
  SSC1_RIC=0x0045;
  SSC1_RIC_IE=1;
}

/*---------------------AD-Wandlung---------------------------*/
void adwandlung (void)
{
   ADC_CON_ADST=1;          //AD-Wandlung starten
  while(ADC_CON_ADBSY==1)        //Warten bis AD-Wandlung fertig ist
  ADC_CTR0_ADST=0;        //AD-Wandlung stoppen
  adwert=ADC_DAT;          //AD Wert abspeichern
}

/*--------------------Berechnung-----------------------------*/
void berechnung_spi (void)
{

  int i=0;
  bcc=0;
  test=(adwert&0x03ff);
  test=test*48000;
  test=test/10000;        //Ergibt bei 5V umrechnung 5000 also 5V mit 3 
Komastellen
  test=test/50;          //erweiterung um Bargraphen zu testen 5V = 100


  bar[5]=1;
  bar[6]=test;

//__________________________        //BCC Byte berechnen
  bcc=0;
  for(i=0;i<(bar[1]+2);i++)
    bcc=bcc+bar[i];
  bcc=bcc%256;
  bar[bar[1]+2]=bcc;

  bcc=0;
  for(i=0;i<(text[1]+2);i++)
    bcc=bcc+text[i];
  bcc=bcc%256;
  text[text[1]+2]=bcc;


/*--------------------Daten über SPI 1 senden----------------*/
void senden (void)
{
  int i=0;
  int empfang;
        int t,len,u;
  int ver;

  ver=bar[1];
  P1L_P1=0;
  for(t=0;t<(ver+4);t++)        //Befehl für neuen Wert in den Bargraph 
n
    {          //eintragen und senden
    SSC1_TB =bar[t];
    for(u=0;u<0x000f;u++);
    while(SSC1_CON_BSY==1);
    }

    ver=text[1];
  for(t=0;t<(ver+4);t++)        //Befahl um 1 2 an die Position x y 
zuschreiben
    {          //eintragen und senden
    SSC1_TB =text[t];
    for(u=0;u<0x000f;u++);
    while(SSC1_CON_BSY==1);
    }
  empfang=SSC1_RB;
  if(empfang==0x01)
  P1H_P1=0;


  P1L_P1=1;

  if (SSC1_RB==0x0006)        //Empfangsregister auf ACK überprüfen
  {
    P1L_P7=1;        //Ausgabe an LED zur Empfangsbestätigung
    P1L_P6=0;
  }
  else
  {
    P1L_P7=0;
    P1L_P6=1;
  }

  if (SSC1_RB==0x0015)        //Empfangsregister auf NAK überprüfen
  {
    P1L_P5=1;        //Ausgabe an LED zur Empfangsbestätigung
  }
  else
  {
    P1L_P5=0;
  }
}

vielen Dank

gruss Michi

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat sich erledigt!
man man man so doof.
Wenn an versucht 320 oder 240 in 1 Byte zu bekommen dann kann das nicht 
gehen. Hab das Problem gelöst indem ich für die Übertragung der 
Koordinaten jeweils 2 Byte benutz!
Man man man gerade ist es mir eingefallen.

Gruss Michi

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.