Hallo zusammen, ich bin auf der Suche nach einem lieferbaren IC, das A/B-Encodersignale und das Indexsignal in einem Auf-Ab-Zähler zählt, der dann über irgendein Interface vom Microncontroller ausgelesen werden kann. Die scheints heutzutage alle nicht mehr wirklich zu geben, wer langsame Signale hat, macht's in Software, wer's schnell braucht, nimmt einen STM32. Hier haben wir so ein Mittelding: Als Controller ist vorerst der Exot AT90USB1287 gesetzt, weil unser Programmierer damit schon viel gemacht hat und die Platine mit dem Ding drauf existiert ja auch schon und soll nur weiterentwickelt werden. Es wird sehr schwierig sein, die beiden Entwickler von der Notwendigkeit zu überzeugen, auf einen STM32 umzuschwenken. Der auszuwertende Drehgeber hat 1400 counts pro Umdrehung und arbeitet mit einem AEDR8712, von dem ich gerade nicht weiß, inwieweit dort die interne Taktvervielfachung von 2, 4, 8 oder 16 eingeschaltet ist. Für das Berechnen der maximalen Frequenz sind also momentan so viele Irrtumsquellen drin, daß ich lieber den Takt mit einem Oszi messen werde und das Ergebnis nachliefere. Dem Programmierer ist das Aulesen per Interrupt oder Polling jedenfalls unsympathisch (mir gefühlsmäßig auch). Nun also ein externes IC. Wir haben sogar noch einige HCTL-2032 (2-Kanal, unnötig) hier, die sind aber vom Footprint etwas groß. Seine kleineren (1-Kanal) Brüder sind genausowenig lieferbar. Auch der LS7366 taucht beim Googeln auf, aber scheint auch nicht mehr lieferbar zu sein. Habt Ihr noch Ideen? fragt und grüßt der Tom.
TomH schrieb: > Habt Ihr noch Ideen? Sowas kann man in einem kleinen Mikrocontroller nachbauen, der dann per UART oder I2C die Daten zur Verfügung stellt. Beitrag "Re: Versetzte Rechtecksignale auswerten, kein drehgeber" http://www.mino-elektronik.de/mt12_iic/mt12_iic.htm#qcnt_tiny25
Falk B. schrieb: > Sowas kann man in einem kleinen Mikrocontroller nachbauen, der dann per > UART oder I2C die Daten zur Verfügung stellt. Dafür sind z.B. die dsPIC-Mikrocontroller sehr gut geeignet, da sie einen Quadratur-Decoder in Hardware besitzen. Damit habe ich schon mehrfach Projekte mit Drehgebern realisiert. Die dsPICs gibt's in verschiendenen Gehäuseformaten und Pincounts, sogar bastlerfreundlich in DIP. Einige PIC24EP-Typen haben dieses Feature auch, kann man hier leicht herausfiltern: https://www.microchip.com/maps/Microcontroller.aspx
Falk B. schrieb: > Sowas kann man in einem kleinen Mikrocontroller nachbauen, der dann per > UART oder I2C die Daten zur Verfügung stellt. Das kommt wohl auf die (noch unbekannte) maximale Drehzahl an.
> Das kommt wohl auf die (noch unbekannte) maximale Drehzahl an. Das wuerde ich auch so sagen. So macht es keinen Sinn ueber sowas nachzudenken. > Dafür sind z.B. die dsPIC-Mikrocontroller sehr gut geeignet, da sie > einen Quadratur-Decoder in Hardware besitzen. Es duerfte kaum eine MCU Familie geben wo es sowas nicht gibt. Olaf
TomH schrieb: > Als Controller ist vorerst der Exot AT90USB1287 gesetzt Es gibt auch AVRs mit Quadrature Encoder Eingängen (Xmega-E5) bzw. die neueren AVRs mit Configurable Custom Logic (CCL) können so programmiert werden. http://ww1.microchip.com/downloads/en/AppNotes/00002434A.pdf
Was soll das Ding denn machen? Ansonsten Drehgeber zu USB gibt es fertig: https://www.codemercs.com/de/drehgeber
Einen kleinen ATXmega für den Encoder verwenden und per SPI mit dem Atmega verbinden. Oder gleich auf ATXmega umschwenken. Habe ich gemacht und möchte eigentlich keinen Atmega mehr verwenden.
Der Hersteller der LS... Typen existiert noch https://www.lsicsi.com/products/Incremental-Encoder-Interface Status "full production", aber die Preise ? Die Firma wurde 1969 gegründet.
So, ein paar Salamischeiben bin ich ja noch schuldig... Hab ein Oszi aufgetrieben. Frequenz an einem der beiden Encoder-Ausgänge A oder B: max. 300Hz. Hertz, nicht kHz! Lächerlich niedrig. Das soll der Programmierer mal schön in Software machen. Das kann ich ihm als proof-of-concept sogar in Arduino vorlegen. Die interne Interpolation des AEDR8712 ist auf 8fach gestellt. Die Frequenz könnte sich also noch höchstens verdoppeln, immer noch lächerlich niedrig. Tut mir leid, daß ich die Frage nach dem externen IC überhaupt gestellt habe. Viele Grüße Tom.
TomH schrieb: > Frequenz an einem der beiden Encoder-Ausgänge A oder B: max. 300Hz. Das macht dann 1,2kHz je Phasenwechsel. Sollte mit Pin-Change Interrupt zu schaffen sein.
Peter D. schrieb: > Das macht dann 1,2kHz je Phasenwechsel. Sollte mit Pin-Change Interrupt > zu schaffen sein. NEIN! NICHT SCHON WIEDER! Auch DU Brutus? (Ähh Peter) Siehe Drehgeber
TomH schrieb: > So, ein paar Salamischeiben bin ich ja noch schuldig... > > Hab ein Oszi aufgetrieben. > Frequenz an einem der beiden Encoder-Ausgänge A oder B: max. 300Hz. > Hertz, nicht kHz! > Lächerlich niedrig. Was hängt denn an dem Drehgeber dran? Wenn der 1400 Pulse/U bei 300Hz macht, sind das ~0,25U/s. Klingt nach einem Stellantrieb.
TomH schrieb: > wer's schnell braucht, nimmt einen > STM32. Aber nur dann, wenn er Scheuklappen trägt und sich nicht dafür interessiert, daß die Chips von anderen Herstellern ebenfalls sowas gelegentlich eingebaut haben. W.S.
TomH schrieb: > das A/B-Encodersignale > und das Indexsignal in einem Auf-Ab-Zähler zählt Das kommt sehr auf den Verwendungszweck an, es gibt im Wesentlichen 2 Sorten: 1. Eingabelement als Potentiometer-Ersatz - niedrige Auflösung, Zähl-Frequenz im kHz-Bereich, Zuverlässigkeit ziemlich egal 2. Positionserfassung für NC/CNC-Maschinen - hohe Auflösung, Frequenz bis MHz, Schrittverluste dürfen nicht passieren Mit hier empfohlenen Zählern für max 25 kHz kann man keine Bearbeitungsmaschine betreiben. Für manuelle Eingaben sind andrerseits 1400 Schritte stark übertrieben. Es ist also nicht klar was der TO will und braucht. Georg
Georg schrieb: > Mit hier empfohlenen Zählern für max 25 kHz kann man keine > Bearbeitungsmaschine betreiben. ... Es sind max. 300 Hz (dreihundert Hertz). Nix mit "... bis MHz" - kannst dich wieder hinlegen ;-)
Ich will die Diskussion nicht verlängern oder erst richtig lostreten - andererseits möchte ich die fehlenden Salamischeiben nicht schuldig bleiben und beschreibe die Anwendung. Es ist keine Privat-Bastelei, sondern ein Neben-Produkt in unserer Firma. Die Firma ist sehr klein, das Entwicklungsteam auch: Einer, der die Elektronik designt, einer, der programmiert, und ich, der die Mechanik designt und das Gesamtkonzept verbrochen hat. Das Produkt hat auch schon Entwicklungsstufen hinter sich, und es müssen Aufträge in gewissem Zeitrahmen erfüllt werden. Vorschläge wie "laß es bleiben" oder "fang das doch ganz anders an" werde ich nicht umsetzen können. Es handelt sich um einen Stellantrieb. Eine Art "Zeiger" mit einer 3mm-Scheibe vorndran bewegt sich knapp über der lichtempfindlichen Fläche von 64x64mm einer Kamera an einem Elektronenmikroskop. Die Scheibe fängt den Nullstrahl bei Beugungsaufnahmen. Sie soll aus dem Bild gefahren werden können, aber auch wiederholgenau in die Bildmitte zurückgefahren werden können. Wie wiederholgenau? Naja, so 0,1mm... Der Zeiger ist ca. 60mm lang, seine Achse muß deutlich außerhalb des Bildes sein, und nach einer ca.45°-Drehung dürfen weder Scheibe noch Zeiger das Bild stören. Das diktieren die Platzverhältnisse. Die momentane Lösung: Ein Schneckenantrieb, dessen Lagerspiel überall durch Federdruck rausgenommen ist. Wirklich am Endabtrieb, auf dem Schneckenrad, sitzt die Encoderscheibe mit 1400CPR, und wird von der AEDR8712 abgetastet. Dieser Endantrieb bewegt sich mit geschätzten 2-3 Sekunden für die Vierteldrehung. Wie gesagt, max. Frequenz eines Encoder-Kanals 300Hz. Wie schon von jemand anders bemerkt, das sind 1,2kHz, mit denen Phasenwechsel zu verarbeiten sind. Nun noch einige Erkenntnisse aus den Diskussionen hier in der Firma: - Der Programmierer, jetzt nochmal auf die Software-Lösung angesprochen, verwehrt sich heftig dagegen. Das hätte er in der Vergangenheit schon probiert, und es kam nur Sch...e dabei raus. Der Controller hat auch mit der USB-Kommunikation einiges zu tun. Ich weiß jetzt natürlich nicht, ob Interrupt oder Polling oder irgendwas... - Der weiter oben erwähnte IC LS7366 scheint doch lieferbar zu sein. Der Preis von gut 5€ schockt uns nicht. - Ich hab natürlich doch gleich mal mit dem Arduino rumgestöpselt. Aber so trivial ist es nicht. Hatte sofort mit Schrittverlust zu kämpfen. Aber da kann ich noch ein bißchen weiterspielen, und eigentlich möchte ich niemanden die x-te Diskussion um die Programmierprinzipien für Drehgeber-Auswertung zumuten... So, morgen hab ich erstmal Urlaub und bin zuhause auch mit dem Geburtstag meiner kleinen Tochter beschäftigt. Werde also wohl den ganzen Tag hier nicht reinschauen und antworten. Also bis übermorgen! Tom.
TomH schrieb: > Hatte sofort mit Schrittverlust zu kämpfen Das kann bei 300 Hz einfach nicht sein. Ein Timer, der die Eingänge alle ms oder etwas weniger abfragt muss absolut zuverlässig zählen. TomH schrieb: > Das hätte er in der Vergangenheit schon > probiert, und es kam nur Sch...e dabei raus Das sehe ich als Problem eurer Firma, nicht als technische Undurchführbarkeit. Aber was richtig ist: wenn ihr etwas einfach nicht beherrscht solltet ihr tatsächlich die Finger davon lassen, da gibt es mit einem externen Zähler-IC weniger Fehlermöglichkeiten, das kann man ja höchstens falsch auslesen, Verzählen passiert nicht. Ich habe solche ICs angefangen beim 74LS2000 bei hundert mal höheren Frequenzen für Messmaschinen in der Autoindustrie eingesetzt und die haben den ganzen Arbeitstag lang korrekt gezählt. Georg
Machts doch ganz anders: Magnet auf die Achse, und dann mit sowas abtasten: https://ams.com/as5048a Gibts auch als b-Version mit I2C statt SPI. Das Ding gibt einen absoluten Drehwinkel raus, d.h. da könnt ihr keine Schritte verlieren. Ansonsten einfach ein kleines FPGA für den Zähler und die Logik nehmen, z.B.: https://www.digikey.de/product-detail/de/lattice-semiconductor-corporation/LCMXO2-256HC-5SG32C/220-2640-ND/3232670 Das sollte reichen. fchk
> Das soll der Programmierer mal schön in Software machen. DAs wuerde ich ja wohl auch so sehen. Ich hab im Mega8 mal eine komplette Achsensteuerung (Geschwindigkeit, Position, Rampen) eines Motors gemacht. TimerIRQ fuer die Abstastung lief mit 40khz. Wobei mir deine 300Hz etwas niedrig vorkommen. Wenn das die Frequenz eines A oder B Kanals ist dann brauchst du 1.2khz im Timer. Also alles vollkommen lachhaft. Kacke an den AVRs in dem Zusammenhang ist aber das man keine Interruptprioritaeten vergeben kann. Da muss man sich dann je nach dem was da sonst noch drin laeuft schonmal einen abbrechen. Olaf
Ich rate entweder uC mit Quadratur Peripherie (STM32, DSPIC, etz.) zu verwenden oder die LS7166 Zähler o.ä. Den STM32 Quadraturmodus verwendeten wir früher einmal in der Firma und das funktionierte wie gewünscht. Die LS7x66 funktionierten in früheren Projekten auch sehr gut. Mit einem LS7183/4 als Frontend kann man übrigens einen normalen Timerzähler mit U/D Steuerung fabrizieren um Quadraturzählen mit uC Timern ohne QE zu emulieren. Der LS7183 übernimmt die Filterung und Dekodierung und erzeugt je nach Modell U/D und den Takt. Damit lässt sich auch allerhand anstellen.
Z.B. TMC424 von Trinamic: https://www.trinamic.com/products/integrated-circuits/details/tmc424/. Verfügbar aber teuer.
TomH schrieb: > rausgenommen ist. Wirklich am Endabtrieb, auf dem Schneckenrad, sitzt > - Der Programmierer, jetzt nochmal auf die Software-Lösung angesprochen, > verwehrt sich heftig dagegen. Das hätte er in der Vergangenheit schon > probiert, und es kam nur Sch...e dabei raus. Jaja, die Softwerker. Immer am Jammern, geht alles nicht, CPU viiiiiieell zu langsam, vieeeeelll zu wenig RAM. > Der Controller hat auch mit > der USB-Kommunikation einiges zu tun. Ich weiß jetzt natürlich nicht, ob > Interrupt oder Polling oder irgendwas... Mag sein, aber für die solide Auswertung dieses Encoders braucht man hier einen Timer-Interrupt mit ca. 3-5kHz. Der sollte durch die USB-Kommunikation nicht ausgebremst werden, geringfügiger Jitter ist sicher OK. Dann läuft das. Mit minimalem Aufwand kann man auch Interruptprioritäten per Software nachbilden. > - Der weiter oben erwähnte IC LS7366 scheint doch lieferbar zu sein. Der > Preis von gut 5€ schockt uns nicht. Dann nimm ihn. > - Ich hab natürlich doch gleich mal mit dem Arduino rumgestöpselt. Aber > so trivial ist es nicht. Hatte sofort mit Schrittverlust zu kämpfen. Dann machst auch du grundlegend was falsch. Möglicherweise sogar schon auf der Hardwareebene. > Aber da kann ich noch ein bißchen weiterspielen, Wenn ich das Wort "weiterspielen" höre, werde ich allergisch. Das klingt genau danach, was es beschreibt. Planloses Rumspielen ohne Know How.
TomH schrieb: > Hatte sofort mit Schrittverlust zu kämpfen. Ich vermute mal der Schrittverlust kommt durch Polling in der Mainloop. Das geht natürlich nicht. Da der Chip ja schon prellfreie Signale liefert, ist der Pin-Change Interrupt die beste Lösung. Schrittverlust bekommt man auch, wenn andere Interrupts den Pin-Change Interrupt solange blockieren, bis schon der nächste Phasenwechsel erfolgt. Falls es der USB-Interrupt ist, der nicht aus die Puschen kommt, kann man ihn ja bei Eintritt disablen und mit sei() die eiligen Interrupts wieder freigeben.
Falk B. schrieb: > Jaja, die Softwerker. Immer am Jammern, geht alles nicht, CPU > viiiiiieell zu langsam, vieeeeelll zu wenig RAM. Ja, das kenne ich auch nur zu gut. Es ist vollkommen egal, ob Du Takt und RAM verdoppelst, es bleibt immer zu wenig. Ich kann da oft nur mit dem Kopf schütteln, mit welch gewaltigen Ressourcen auf simpelste Steuerungsabläufe geschossen wird.
TomH schrieb: > Frequenz an einem der beiden Encoder-Ausgänge A oder B: max. 300Hz. Das ist ja schnarchlangsam. Das kann man ja fast von Hand mitschreiben... TomH schrieb: > Dem Programmierer ist das Aulesen per Interrupt oder Polling jedenfalls > unsympathisch (mir gefühlsmäßig auch). 1. es gibt auch schlechte Programmierer (der von meinem DVD-Player ist auch so einer) und 2. in der Technik sollte man sich nicht auf Gefühle verlassen (auf jeden Fall nicht, so lange die nicht vollständig und belastbar ausgeprägt sind) TomH schrieb: > - Der Programmierer, jetzt nochmal auf die Software-Lösung angesprochen, > verwehrt sich heftig dagegen. Das hätte er in der Vergangenheit schon > probiert, und es kam nur Sch...e dabei raus. Da muss man nichts "probieren". Das kann man analysieren und sicherstellen. > Der Controller hat auch mit der USB-Kommunikation einiges zu tun. Ja, Ausrede eben. > Ich weiß jetzt natürlich nicht, ob Interrupt oder Polling oder > irgendwas... Ich bin auch nur deshalb zu spät gekommen, weil ich den Bus verpasst habe, weil die Großmutter meiner Nachbarin ihre Katze im dunklen Keller ohne Licht... Verdammt, Faden verloren... Ausrede eben. > - Der weiter oben erwähnte IC LS7366 scheint doch lieferbar zu sein. Die haben da echt eine Nische gefunden: https://lsicsi.com/products/Counters/LS7366R-S_LS7366R-TS_LS7366R > Der Preis von gut 5€ schockt uns nicht. Ihr sitzt da wohl auf einer Insel der Glückseligen. TomH schrieb: > Nun also ein externes IC. Sieh dir den Beitrag "Re: Auswertung mehrerer Drehencoder" auch mal an.
:
Bearbeitet durch Moderator
TomH schrieb: > - Der Programmierer, jetzt nochmal auf die Software-Lösung angesprochen, > verwehrt sich heftig dagegen. Das hätte er in der Vergangenheit schon > probiert, und es kam nur Sch...e dabei raus. Dann handelt es sich wohl um einen Sch...-Programmierer. Vielleicht sollte der mal bei Drehgeber (siehe Link) nachlesen. Bei der von Dir geforderten hohen Präzision sollte auf jeden Fall eine Zustands- auswertung und keine Interruptauswertung gemacht werden. Inter- ruptauswertung ist höchstens bei handbetätigten Drehgebern sinnvoll.
:
Bearbeitet durch User
Harald W. schrieb: > Bei der von > Dir geforderten hohen Präzision sollte auf jeden Fall eine Zustands- > auswertung und keine Interruptauswertung gemacht werden Da kommt man sich hier im Forum vor wie ein Prediger in der Wüste, der die Felswände überzeugen will. Forum für alternative Elektronik eben, natürlich auch LEDs ohne Vorwiderstand, Busse ohne GND usw. usw. Georg
Harald W. schrieb: > Dir geforderten hohen Präzision sollte auf jeden Fall eine Zustands- > auswertung und keine Interruptauswertung gemacht werden. Der Pin-Change Interrupt erkennt nur, daß ein Phasenwechsel auf einer der beiden Leitungen erfolgte. Die Auswertung muß natürlich der Interrupthandler machen (z.B. Graycode zu binär).
Angehängte Dateien:
-
UPDN.png
19 KB
TomH schrieb: > ich bin auf der Suche nach einem lieferbaren IC, das A/B-Encodersignale > und das Indexsignal in einem Auf-Ab-Zähler zählt, der dann über > irgendein Interface vom Microncontroller ausgelesen werden kann. Das könnte z.B. so aussehen. Ungefähr wie Mode x1 von LS7084N. Dafür braucht man nicht unbedingt besondere IC. 74HC132 paßt auch. Will man x2-Mode, kann man das mit zwei 4093 oder HC132 machen. Auch 4x-Mode ist so möglich.
:
Bearbeitet durch User
Peter D. schrieb: > Der Pin-Change Interrupt erkennt nur, daß ein Phasenwechsel auf einer > der beiden Leitungen erfolgte Der erkennt genauso, wenn das Signal an der Taktflanke "prellt" oder der Encoder am Übergang rumeiert.
Axel G. schrieb: > Um mal auf die Anfangsfrage zurück zu kommen. Git es schon: > > https://www.ichaus.de/product/iC-MD Der Link ist ein schönes Beispiel dafür, die Anforderungen des TO überhaupt nicht beachtet oder verstanden zu haben. Warum soll er denn LVDS oder 40 MHz bezahlen, mit welchen Lieferzeiten, zu welchem Preis? Sofern es der hausinterne Programmierer nicht in Software gebacken bekommt, reicht doch ein kleiner 8-pol. µC (ATtiny, s.o.), um eine externe Zählerlösung zu erhalten. Kosten < 1 Euro, Aufwand für Platinenlayout minimal.
Sprachlos schrieb: > Kosten < 1 Euro, Aufwand für > Platinenlayout minimal. Entwicklungskosten 99,9% der Gesamtkosten.
Ich will mal nochmal abrunden und versuchen, die Gemüter zu beruhigen. Wird nicht gelingen, es gibt immer welche, die sich streiten wollen. 1. Externer IC Danke für die Vorschläge. Wir werden zunächst versuchen, den LS7366 in SSOP zu bekommen. Der hat handliche 14 Beine. Selbst wenn wir nur auf abenteuerlichen Wegen einmalig ca. 20 Stück davon beschaffen können, das beschriebene Produkt ist ein absolutes Nischen-Ding, das reicht uns. Die beiden anderen Vorschläge sind deutlich komplexer, man kann sagen Overkill. Selbst wenn das Argument "teuer" bei uns nicht so schlimm wäre... Kleine Anekdote am Rande: Das Vorgängerprodukt arbeitete mit dem Avago HCTL-2032. Weil der vor Jahren auch schon schwierig zu beschaffen war, wurde panisch ein Vorrat beschafft. Leider irrtümlich in DIL-40 statt in SSOP... davon haben wir jetzt ca. 40 Stück herumliegen... können wir irgendwann handverlesen auf ebay vergolden... 2. Programmierer Hört auf, auf dem herumzuhacken. Der Umgang mit ihm ist ganz normaler Umgang mit Kollegen. Ich muß ihm ja die Aufgabenstellung nahebringen, er macht sich seinen Reim drauf. Der macht sein Zeug super, und ich kann nicht beurteilen, ob er mit den negativen Erfahrungen mit Polling/Interrupt in seinem Gesamt-Setting recht hat oder einem Irtum aufgesessen ist. Nur wenn man alles selber macht, hat man die Schnittstelle zwischen den Kollegen nicht, aber man ist trotzdem nicht gegen Holzwege und Irrtümer gefeit. 3. Arduino-Spielerei Bitte keine Pickel bekommen, es ist ja nur eine "Demo", die ich da für den Programmierer zusammenstöpsle. Übrigens funktioniert es mittlerweile ziemlich gut. Problematisch ist bei mir sicher die Rückmeldung der Position über die serielle Schnittstelle. Vor allem bei Erreichen des Index-Signals wurde zunächst ständig das Wort "Index" rausgerattert, in der vollen Frequenz der Main Loop. Das hat alles gestaut und durcheinandergebracht. Seit ich nur noch ein bescheidenes "I" neben der gelegentlichen Positionsmeldung anzeige, ist es ziemlich fehlerfrei geworden. Das Konstrukt ist ungefähr so:
1 | void loop() |
2 | {
|
3 | static int encoderTimeout; |
4 | |
5 | Position_alt = Position; |
6 | Position = Position + encoderImpuls(); |
7 | |
8 | if (Position == Position_alt) encoderTimeout++; |
9 | |
10 | if (encoderTimeout > 1000) |
11 | {
|
12 | encoderTimeout = 0; |
13 | Serial.print(Position); |
14 | if (digitalRead(ENC_I) == HIGH) Serial.print(" I"); |
15 | Serial.println(); |
16 | }
|
17 | |
18 | MotorSteuern(JoystickLesen()); |
19 | }
|
20 | |
21 | int encoderImpuls() |
22 | {
|
23 | static byte state=0; |
24 | state= state<<2; // Bits um zwei Stellen nach links schieben |
25 | if (digitalRead(ENC_A)) bitSet(state,1); // Eingang A abfragen und Bit1 setzen |
26 | if (digitalRead(ENC_B)) bitSet(state,0); // Eingang B abfragen und Bit0 setzen |
27 | state= state & 0xF; // Nur die unteren 4 Bits behalten |
28 | switch(state) |
29 | {
|
30 | case 0b0000: |
31 | case 0b0101: |
32 | case 0b1010: |
33 | case 0b1111: return 0; // keine Änderung an den Eingängen |
34 | case 0b0001: |
35 | case 0b0111: |
36 | case 0b1110: |
37 | case 0b1000: return 1; // links Impuls an den Eingängen |
38 | case 0b0010: |
39 | case 0b1011: |
40 | case 0b1101: |
41 | case 0b0100: return -1; // rechts Impuls an den Eingängen |
42 | }
|
43 | }
|
Die Sache mit dem Timeout ist natürlich unsauber (und eigentlich eher für das Auswerten von handbetätigten Drehgebern gedacht). Es wird immer irgendeinen Moment geben, in dem die Taktsignale langsam genug kommen, um die serielle Ausgabe zuzulassen, und dennoch so schnell, daß während der seriellen Ausgabe was verschluckt wird. Aber tatsächlich funktioniert es so schon ganz gut.
> Das Vorgängerprodukt arbeitete mit dem Avago HCTL-2032. Weil der vor > Jahren auch schon schwierig zu beschaffen war, wurde panisch ein Vorrat > beschafft. Hm..ich hab noch eine Handvoll HCTL-2000. Bin ich jetzt reich? :-) Olaf
TomH schrieb: > Die beiden anderen Vorschläge sind deutlich komplexer, man kann sagen > Overkill. Was ist denn an einem ATtiny25 oder 202 komplex oder Overkill? Das Programm dafür muß nur aufgespielt werden. AVR wird bei euch ja schon verwendet. TomH schrieb: > Selbst wenn wir nur auf abenteuerlichen Wegen > einmalig ca. 20 Stück davon beschaffen können, Kurz gesucht. ATtiny25/45/85 gibt es bei Reichelt; ATtiny212 zum Beispiel bei Farnell 835 Stk. ab Lager < 50 ct.
Neueste Erkenntnis: LS7366 ist tatsächlich nur auf extrem abenteuerlichen Wegen beschaffbar. Eigentlich gar nicht. Ein Punkt mehr für die Software-Lösung. Oder meinetwegen, wenns gar nicht anders geht, ja, einen ATtiny.
Falk B. schrieb: > Entwicklungskosten 99,9% der Gesamtkosten. Du tust so, als ob man da irgendetwas neu erfinden müsste. Auch bei einem Chip, der von sich aus zählen kann, muss Layout und Softwareanbindung umgesetzt werden.
Selbst wenn man einen µC nimmt, der einen Encoder-Eingang in Hardware hat, muss der Programmiert werden. Und zwar so, dass der eine brauchbare Schnittstelle für den bereits verbauten Mastercontroller bekommt. Das ist kein Hexenwerk, aber für den o.g. Programmierer scheinbar zu schwierig. Der ganze Overhead, der da drann hängt (Doku, Produktionsprozess,...), ist auch nicht zu unterschätzen. @Tom: Wenn ihr das nicht hinbekommen solltet, melde dich gerne per Mail bei mir. Vielleicht kann ich euch da dann weiterhelfen. Mit freundlichen Grüßen Thorsten Ostermann
Wir nutzen einen der LSICSI ICs (SPI interface) in einem Serienprodukt mit Linux, bisher keine Probleme, weder Funktion noch Beschaffbarkeit.. Aber wir kaufen auch direkt ganze Rollen.. Und für uns war es besser als eine Softwarelösung da die Softwarepflege + Programmierung + Softwareentwicklungskosten entfallen sind.. Reicht wenn wir das Linux pflegen müssen..
TomH schrieb: > Ein Punkt mehr für die Software-Lösung. > Oder meinetwegen, wenns gar nicht anders geht, ja, einen ATtiny. Als ob man den nicht programmieren müsste. Wer das mit einem AT90 nicht hinkriegt, schafft das auch nicht mit einem ATtiny - eher noch weniger. Und Geld ist wohl auch nicht dafür verfügbar. Georg
I.MX7 hat interne Decoder aber mit anderem nützlichen "vermuxt" daher ist es dann auch bei uns extern geworden..
Georg schrieb: > Als ob man den nicht programmieren müsste. SPI-Prommer für AVRs gibt es doch wie Sand am Meer und ist wohl schon längst vorhanden. Die paar Byte sind doch in 2 s im Chip.
Sprachlos schrieb: > SPI-Prommer für AVRs gibt es doch wie Sand am Meer und ist wohl schon > längst vorhanden. > Die paar Byte sind doch in 2 s im Chip. Er meinte mit "programmieren" wohl eher die Erstellung und den Test des Programms, nicht das Brennen der Firmware.
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.