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.
Angehängte Dateien:
-
eDIP-pdf.jpg
120 KB
Ähhhm, wegen der Vorschau ist der Dateianhang wieder "rausgeflogen". Hier ist er.
Ach ja, interessanterweise funktioniert das mit dem DC1 wenn ich die Puffergrößen anfordere.
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 ... ;))
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
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
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
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
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
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
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
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
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.).
Angehängte Dateien:
-
IMG_0003.JPG
54 KB
Für alle, die sich damit beschäftigen, hier ein paar Bilder um Mut zu machen ;)
Angehängte Dateien:
-
IMG_0004.JPG
56 KB
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.
Angehängte Dateien:
-
IMG_0007.JPG
55 KB
.. 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.
Angehängte Dateien:
-
IMG_0010.JPG
63 KB
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.
Angehängte Dateien:
-
IMG_0011.JPG
60 KB
Diesen Screen hätte ich vielleicht vor dem vorherigen zeigen sollen, er ist für die Verteilung der einzelnen Infoscreens zuständig.
Angehängte Dateien:
-
IMG_0016.JPG
59 KB
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.
Angehängte Dateien:
-
IMG_0018.JPG
58 KB
Und als letztes Beispiel der, noch unvollständige, Screen für die Außenanlagen.
Angehängte Dateien:
-
Symbols.jpg
9,2 KB
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.
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.
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 :-)
Angehängte Dateien:
-
IMG_0274-small.JPG
36 KB
hier auch noch ein beweis dass das eDIP keine hexerei und teufelswerk ist ^^ gruß keniff
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" ;)
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).
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
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,
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
Angehängte Dateien:
-
Buchsenleiste.jpg
51 KB
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,
Ääää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).
Nimm die gedrehten IC-Sockelleisten: http://www.reichelt.de/?;ACTION=3;LA=2;GROUP=C131;GROUPID=3215;ARTICLE=19400;START=0;SORT=artnr;OFFSET=100;SID=22GhRAMX8AAAIAACsiPYQ040218c60ad08b99eb988a5f0fdb54bb Peter
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!!!
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 :-)
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.
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
Also mein eDIP fördert auf Anfrage folgendes ans Tageslicht: EA eDIP240-7 V1.4 Rev.B TP+
@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.
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
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
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.