Beiträge von synvox

    Als 24-Kanal-Typen mit 12 Bit PWM kannst du dir ja mal den TLC5951 anschauen. Der sollte so ziemlich alle Anforderungen erfüllen. Allerdings ist seine Strom-Ausgabe bei 40 mA pro Kanal begrenzt. Etwas mehr Power können die 16-Kanaligen 12 - 16 Bit Typen der TLC5940er Serie abliefern. Diese eignen sich aber nicht so nicht so gut für 8x8-RGB-Anordnungen, sondern dann eher für 16x8-RGB, wie sie im Übrigen auch Pepe_1981 verwendet.


    Mein persönlicher Favorit (für meine Zwecke) ist der TLC5971 (12 Kanal, 16 Bit), wie ich schon mal geschrieben habe. Damit plane ich momentan 16x16-RGB-Module (4 TLC5971 pro Modul), wobei ich 'nur' 9 Bit PWM nutze (ergibt sich aus der Art, wie der TLC5971 die PWM erzeugt: Stichwort ES-PWM). Damit mache ich eine 7 Bit auf 9 Bit Gamma-Korrektur mit dem 'alten' Apple Mac Gamma von 1,8. Allerdings sind meine Module für eine komplett andere Anwendung vorgesehen, als das reine Streamen und Anzeigen von RGB-Daten (e.g. Video-Display). Bei mir ist dann auch eine sehr hohe Bildwiederholfrequenz deutlich wichtiger als die Bittiefe der PWM.


    Wie auch immer, your mileage may vary, je nach Anwendung und Zweck.


    PS (auch Pesi): Die verwendete Bittiefe beim TLC5947 beeinflusst schon die Zeilen- und Bildwiederholfrequenz, eben weil man mittels XLAT und BLANK die PWM zum Bsp. bei verwendeten 11 Bit (untere Bits) schon nach (zeitmässig etwas mehr als) 2048 Clocks rücksetzen und dann schon die nächste Zeile darstellen kann (vorausgesetzt die Daten für die nächste Zeile können in einer Zeilendauer übertragen werden). Der Vorteil dabei ist eben, dass man so den ungenauen Zeitpunkt der automatischen Zykluswiederholung vermeidet bzw. auslässt und relativ sicher einen vollständigen 11-Bit Zyklus (und nur diesen einen; der Rest bis zum Rücksetzen und Zeilenumschaltung ist einfach low bzw. Ausgänge abgeschaltet) pro Zeile hat. Aber wie schon gesagt, bei mehr Zeilen kommt man mit dem TLC5947 und seinen maximalen 4 MHz GS-Clock sowieso schnell an seine Grenzen.

    Erstmal vielen Dank für das Lob Pesi und leddie :) .


    Naja, mit 10 oder 11 Bit sollte das ja nicht unbedingt auf 100Hz runterkommen oder? Wenn ja, hat es natürlich kein Sinn.


    Nein, das nicht. Aber du solltest bedenken, dass bei mehr Zeilen auch die Bildwiederholfrequenz wiederum sinkt. Und bei 'nur' drei Zeilen würde ich kein Multiplexing einsetzen, denn die Kosten für zwei zusätzliche TLC5947 sind wirklich nicht so hoch, dass sich Multiplexing da noch lohnen würde. Erst wenn du mehrere 64 RGB-LED-Module ( 8x8 ) planen würdest, würde ich mir Multiplexing überlegen, aber da würde ich dann ganz andere Treiber als den TLC5947 nehmen.


    Gruss
    Neni

    Hallo leddie,


    das Problem ist, dass du die GS-Clock bzw. den PWM-Zyklus beim TLC5947 nicht mit der Zeilenumschaltung beim Multiplexing synchronisieren kannst. Der interne Oszi des TLC5947 ist ein RC-Oszi, d.h. er wird nie allzu genau bei den angegebenen 4 MHz liegen. Wenn du nun mit XLAT und BLANK (vor einem Zeilenwechsel) die PWM abbrichst, wird das immer mitten während eines laufenden PWM-Zyklus geschehen, da eben keine Synchronisation möglich ist.
    Wenn die PWM-Frequenz nun so hoch wäre, dass pro Zeile sehr viele komplette Zyklen durchlaufen werden, würde ein einzelner unterbrochener Zyklus nicht allzu stark ins Gewicht fallen. Bei einer GS-Clock von ca. 4 MHz und einer 12 Bit PWM ist die PWM-Frequenz aber 'lediglich' ca. 977 Hz. Bei drei Zeilen (3 x 8 = 24 RGB-LEDs) musst du eine Zeilenumschaltfrequenz von mindestens 300 Hz haben, damit die Bildwiederholfrequenz >= 100 Hz ist (das absolute minimum). D.h. du hättest maximal drei volle PWM-Zyklen pro Zeile. Wenn einer davon dann nicht vollständig ist bzw. der vierte bereits angefangen hat beim Abbruch, kann das durchaus zu deutlich sichtbaren Artefakten in der Darstellung führen.


    Eine Möglichkeit, das Problem etwas zu entschärfen, wäre, nicht die vollen 12 Bit für die PWM zu nutzen, sondern nur die unteren 11 Bit (das oberste Bit MUSS dann immer 0 sein). Dann kannst du eine Zeilenanzeigezeit wählen, welche genügend oberhalb der theoretischen Zeit für die 11 Bit (2048 GS-Clocks) liegt, dass sie sich über der maximalen Dauer (bei laut Datenbalatt niedrigster Clock-Frequenz) inerhalb der Variationsbreite des RC-Oszis und deutlich unterhalb der Dauer für 12 Bit befindet. Da so nach den 2048 GS-Clocks alle Ausgänge abgeschaltet werden und für die Dauer der Zeile abgeschaltet bleiben, bleibt die Zeilen-Anzeige linear zum PWM-Wert. Die Variationbreite zwischen dem Ende der 2048 GS-Clocks und der erfolgten Zeilenumschaltung beeinflusst dann lediglich die Gesamthelligkeit leicht.


    Gruss
    Neni

    Ich habe keine Pegelanpassungen machen müssen, da ich's ja eben via Sparkfun-USB-Adapterboard (eigentlich für die Xbees gedacht) am PC konfiguriert und getestet habe. Ich denke aber, Spannungsteiler in die eine Richtung müsste reichen. Ob der Spannungshub in die andere Richung für nen AVR-Input-Pin @5V in der Praxis ausreicht, muss man testen. Der AVR hat theoretisch CMOS-Pegel-Anforderungen, also max. 30% bzw. min. 70% VDD, aber eben, man muss es ausprobieren.


    Gruss
    Neni

    Auch wenn es nicht 'nur' mit LED-Licht zu tun hat, sondern auch mit ferngesteuerter Bewegung, es weckt das Kind im Manne und das "Haben muss"-Gefühl wird übermächtig :D :
    -> SPHERO


    Gruss
    Neni

    Ja, das (250 kbps) sollte man können, denn es gibt neben dem Befehl "set uart baud ..." auch den Befehl "set uart raw ...", mit welchem man die 'rohe' Bitrate angeben kann. Der Teiler im Chip wird dann wohl auf den bestmöglichen Wert für den gewünschten kbps-Wert gesetzt.


    Gruss
    Neni

    Hmmm, leider scheint bei diesem Modulen die SPI-Schnittstelle in der aktuellen Firmware NOCH nicht unterstützt zu werden.

    Zumindest ist SPI in der Hardware vorhanden, also ist die Unterstützung 'nur' eine Frage der Firmware.


    Sorry Pesi, falls ich dich da zum Kauf verleitet haben sollte. Aber ich war auf den UART und die transparente Übertragung konzentriert und hatte gar nicht mitbekommen, dass für dich SPI wegen der max. Geschwindigkeit so wichtig ist.


    Gruss
    Neni

    Ich werfe mal noch den Galep5 ins Rennen. Mit dem erschlägst du für knapp 500 € fast alles mögliche (von Atmel sowieso praktisch alle µCs). Nicht aufgelistete Chips, welche aber ein JTAG-Interface haben, kannst du oft via JTAG-Player/Programmer trotzdem auch noch programmieren. ISP hat er übrigens auch.


    Gruss
    Neni

    Hallo Pesi, ich weiss nicht ob dein Modul schon angekommen ist und du es schon testen konntest. Jedenfalls habe ich einen Tag nach dir auch gleich zwei Module bestellt. Mittlerweile habe ich auch schon erste Tests machen können und kann hier von den Ergebnissen berichten.


    Da das RN-XV pinkompatibel mit den Xbee-Modulen ist, konnte ich sie einfach auf die Xbee-Adapterplatinen mit USB-Anschluss (via FTDI-Chip) von Sparkfun (welche ich schon für die Xbee-Tests gekauft hatte) stecken. Hier musste aber schon eine erste, kleine Fehlerquelle umschifft werden. Man durfte nämlich das Modul nicht ganz in den Sockel runterdrücken, weil sonst die Metallhülle des WiFi-Moduls die metallene USB-Buchse der Adapterplatine berührte. Und anscheinend liegt die WiFi-Modul-Hülle nicht auf Masse-Pegel wie die Ummantelung der USB-Buchse, denn bei Berührung ging gar nix mehr. Glücklicherweise hat es weder das Modul noch den Adapter beschädigt.


    Also nahm ich mein Terminal Program und fing an, das Modul via USB (bzw. via serielle Schnittstelle) nach Manual zu konfigurieren. Aber was ich auch einstellte, das Modul konnte sich mit meinem AP einfach nicht assoziieren. Ich bekam ständig einen AUTH-ERR (authentication error) angezeigt. SSID, Passphrase, etc., alles war korrekt. Beim wlan scan konnte das modul meinen AP aber 'sehen', und da konnte ich lesen, dass mein AP den Verschlüsselungstyp WPA1 meldet. Ok, jetzt wird's etwas theoretisch... ;) . WPA1 (bzw. WPA1-PSK) unterstützt standardmässig nur den Verschlüsselungsalgorithmus TKIP. Der neuere Typ WPA2 (bzw. WPA2-PSK) verwendet dafür AES. Nun gibt es aber APs (oft etwas ältere), welche zwar WPA1-kompatibel sind (WPA2 können sie meist auch, melden aber in der Kompatibilitätseinstellung eben WPA1 an den Client), aber trotzdem AES verwenden. Mit den meisten Wireless-Devices ist das kein Problem. Die ignorieren die Info des AP und melden sich mit WPA2 und AES an. Das WiFly-Modul nimmt es hingegen sowohl mit dem Standard (WPA1 nur mit TKIP und WPA2 nur mit AES) als auch mit der Info-Meldung des AP (WPA1-Meldung heisst für den WiFly, der AP könne nur WPA1) sehr ernst. Puuuh, soweit also zur Theorie. Das wäre alles kein Problem gewesen, hätte ich meinen AP umkonfigurieren und die WPA1-Kompatibilität ausschalten können. Nun ist das Ding aber ein älteres Modell, ein VDSL-Router mit WLAN-AP, welchen ich vor x Jahren von meinem Internet-Provider mit dem Abo-Abschluss zur Verfügung gestellt bekommen hatte. Un dieser hatte das Ding per Firmware so zugesperrt, dass man kaum was an den WLAN-Parametern ändern konnte (ein Router für Dummies sozusagen :D ).


    Nun, da ich den AP-Router sowieso mal ersetzen wollte (auch weil ich endlich auch Wireless N haben wollte), warum also nicht jetzt ;) . So bin ich dann heute Abend flugs zum nächsten Computer-Händler gedüst und habe mir nen aktuellen VDSL-Router mit WLAN-AP (b,g,n) besorgt. Angeschlossen, konfiguriert, WLAN-Netz explizit auf WPA2-PSK mit AES gestellt, beim WiFly die Konfiguration auch entsprechend angepasst, und schwupps hatte ich in nullkommanix ne stabile WLAN-Verbindung zwischen dem WiFly RN-XV und meinem neuen AP augebaut. IP-Adresse, Gateway etc. wurden auch auf Anhieb via DHCP geholt, so dass ich am Modul nur noch das UDP-Listening einschalten musste (als Standardeinstellung ist nur TCP eingestellt), und schon konnten die Pakete kommen ;) .


    Zum Test habe ich das TouchOSC-App für mein Android-Phone verwendet. Das App wurde hier auch schon mal von michuneo vorgestellt und sendet Button-, Fader- etc. -Informationen als OSC-Messages (OSC = open sound control) in UDP-Paketen übers WLAN. Da es zum Teil binäre Daten sind, musste ich ein Terminalproggi mit der Möglichkeit einer Hex-Anzeige wählen (Termite bietet sich da an).
    Ein paar Ergebnisse möchte ich hier nun zeigen, will aber das OSC-Protokoll nicht auch noch erklären (man kann die Spezifikation ja im WWW nachlesen). Zuerst wird in der App auf dem Phone ein Toggle-Button zweimal berührt, dann wird ein Fader etwas bewegt:


    Man sieht also schön die Inhalte der UDP-Pakete über die serielle Schnittstelle des Moduls, es arbeitet also wirklich absolut transparent. Ich habe für meine Tests eine Baudrate von 115200 bps verwendet, das Modul kann aber auch schneller. Ich habe schon einiges rumgesendet und damit jetzt rumgespielt und konnte bisher keine Fehlerbytes bzw. Aussetzer feststellen. Die Distanz zum AP betrug ca. 8 m Luftlinie durch eine Zimmerwand bzw. 12 m ums Eck durch die offene Zimmertüre.


    Als Fazit kann ich nur sagen, dass ich nach kleinen Anfangsschwierigkeiten mit der Performance dieser Module absolut zufrieden bin. :thumbup:


    Gruss
    Neni

    Hallo Pesi, danke für die netten Worte :) . Letztes Jahr (ab Frühling bis Anfang Herbst) war ein sehr schwieriges Jahr für mich. Ich habe eine schwere Depressionsepisode mit Angststörung durchleben müssen. Es war nicht das erste mal, dass ich sowas habe (das dritte mal in 15 Jahren), aber diesmal hatte es mich so schlimm erwischt, dass ich während des Sommers 2 Monate stationär in einer Klinik in Behandlung war. Dass während so einer Episode jegliche Lebensfreude und alle Interessen praktisch auf Null schrumpfen und nur noch die dunkle Wolke im Kopf existiert, dürften all jene gut verstehen, die auch schon mal sowas durchleben mussten. Da hatte ich natürlich dann 'gar keinen Bock' mehr auf irgendwelche Hobbies, Foren etc. Glücklicherweise bin ich bisher jedes mal auch wieder gestärkt aus dem Tal herausgekommen (akute Phase dauert bei mir so ca. 6 Monate), und so auch diesmal. Jetzt habe ich zum Glück wieder die Freude und den Elan, mein Grossprojekt wieder in Angriff zu nehmen. Immerhin resultierte die Zwangspause darin, dass ich meine Entwicklung überdenken konnte und jetzt, wie ich meine, eine technisch deutlich bessere und zudem auch günstigere Lösung für meine Module in Planung habe.


    Doch nun zum eigentlichen Thema, sorry also für's O.T. Geschwafel:
    Ja, transparent bedeutet in diesem Sinne genau das, was du auch vermutest. Der TCP/IP-Stack, die WEP- oder WPA-PSK-Verschlüsselung und generell die gesamte Integration in ein WLAN-Netz übernimmt das Modul. Man muss natürlich die IP, Gateway, DNS, WPA-PSK-Security-Passphrase etc. via UART im Command-Modus zuerst konfigurieren (es kann sich auch per DHCP IP, Gateway und DNS zuweisen lassen, wenn man einen DHCP-Server im Netz hat; die meisten WLAN-Router haben so einen ja). Danach funzt es dann eben transparent als TCP- oder UDP-nach-Seriell-Wandler, ähnlich also einem Xbee, nur eben in einem Standard-WLAN-Netz. Solche Module gab es eigentlich schon länger, nur waren sie bisher recht teuer. Man kann übrigens auch nur das Modul an sich WiFly RN-171 nehmen, aber für 5 $ mehr hat man eben noch ein paar Status-LEDs drauf, einen Xbee-konformen Footprint und eine kleine Antenne.


    Gruss
    Neni

    Das Gainspan-WiFi-Modul ist zwar interessant, jedoch bekommt man die notwendige Dokumentation zur Software-Entwicklung und Programmierung des ARM7-Application-µCs nur, wenn man ein NDA (Non Disclosure Agreement) der Herstellerfirma unterzeichnet und deren SDK kauft (wie man aus den Kommentaren zum Produkt erfährt).


    Andererseits sind die verfügbaren WiFi-Module heutzutage so einfach zu konfigurieren und zu betreiben, dass man gar keines mit einem integrierten, user-programmierbaren µC benötigt. Man kann auch einfach eines mit UART, SPI oder einer anderen seriellen Schnittstelle wählen, welches praktisch einen Wrapper um das WiFi-TCP/IP-Protokoll bildet. Das Gainspan macht das zwar auch (man muss nicht den ARM verwenden), mir persönlich gefällt zum Bsp. aber das RN-XV WiFly Modul (bzw. das darin verbaute Teil WiFly RN-171) beim gleichen Anbieter (Sparkfun) besser.
    Es lässt sich wirklich einfach über den UART-Port konfigurieren (Command-Modus) und in eine bestehende WiFi-Infrastruktur einbinden. Aber auch der Adhoc-Modus wird unterstützt. nach der Konfiguration werden im transparenten Modus die eingehenden TCP- oder UDP-Pakete (bzw. deren Inhalt) über den UART mit max. 460 kbps ausgegeben. Über den UART eingehende Daten werden mit einem konfigurierbaren Packalgorithmus (Datenpaket-Endzeichen, Timeout etc.) zu TCP- oder UDP-Paketen verschnürt und versendet. Da eben auch UDP empfangen wird, kann man es sehr gut als ARTNET- oder OSC-Empfangsknoten verwenden. Via UDP sind dann auch Multicast-Bereiche oder auch Broadcast (vorzugsweise nur in einem lokalen, verschlüsselten WiFi-Netz) möglich.


    So ein Modul kann man dann mit einem praktisch beliebig kleinen µC (auch AVR) betreiben, da ja nur UART-Kommunikation betrieben werden muss. Der ganze Rest wird vom Modul erledigt (korrekte Konfiguration vorausgesetzt).


    Gruss
    Neni

    Die schnellsten linearen KSQs, die ich kenne, sind die in einzelnen TLC-Chips von TI auf dem Wafer integrierten. Der TLC5971 zum Bsp. kann Pulse von minimal 50 ns an den Konstantstromausgängen erzeugen, der TLC59116 sogar minimal 40 ns. Laut Oszi-Bild in Datenblatt vom TLC5971 sehen die Pulse auch bei 50 ns und Maximalstrom von 60 mA noch gut genug aus. Allerdings sind alle diese chipinternen KSQs ja eher für kleine Ströme ausgelegt. Im High-Power-Bereich wird man ziemlich Probleme haben, solche Schaltfrequenzen ohne Artefakte zu erreichen. 5 - 10 MHz sollte man allerdings mit einem schnellen Power-MOSFET gepaart mit einem leistungsfähigen und schnellen MOSFET-Treiber schon erreichen, allerdings dann am ehesten mit einfachem Widerstand als Strombegrenzer (KSQ), nur bitte keinen gewickelten Drahtwiderstand ;) .


    Gruss
    Neni

    Hallo Pesi,


    der TLC5971 nimmt die interne GS-Clock (ca. 10 MHz typ. mit Variantionsbreite 6...12 MHz) als Referenz und bestimmt damit grob die Länge des letzten SPI-Clockzyklus vor der Pause. Damit ergibt sich, dass auch bei 20 MHz SPI-Clock die Zeit vor dem Latch-Impuls minimal 660ns (eher typ. 800ns) beträgt. Bei langsamerer SPI-Clock ist diese Zeit dann auch proportional länger, wie du richtig vermutet hast. Es gibt auch ne maximale Länge, welche aber nur bei sehr sehr langsamer SPI-Clock greifen würde; die beträgt so 16000-irgendwas GS-Clock-Zyklen, also irgendwas im ms-Bereich.


    Gruss
    Neni

    So, ich melde mich auch mal wieder ;) .


    Mein aktueller Favorit für RGB-Kachel-Boards ist der TLC5971. Dieser hat zwar 'nur' 12 Kanäle (für 4 RGB-LEDs), dafür aber bis zu 16 Bit PWM und in einem sehr platzsparenden Gehäuse (TSSOP20). Gut ist auch die 7-Bit Stromeinstellung für jede Farbgruppe (3 Gruppen zu je 4 Kanälen) getrennt. Damit kann man beispielsweise den Weissabgleich für die jeweilige Selektion RGB-LEDs allein in Software machen, ohne dass man an der Hardware (Widerstände etc.) auf dem Board was ändern muss, wenn man nicht immer die gleiche Selektion bekommen kann. Das ist auch bei Qualitätsleds oft so, dass man zwar pro Reel nur eine bestimmte Selektion hat, aber eben nicht genau eine spezifische Selektion bestellen kann (oder nur gegen Aufpreis), sondern versch. Reels aus einem mehr oder weniger grossen Selektionsbereich bekommt.


    Angesteuert wird der TLC5971 ähnlich wie der WS2801, also Standard-SPI bis 20 MHz und theoretisch 'unendlich' kaskadierbar. Allerdings generieren die TLCs den internen Latch-Puls jeweils schon nach einer Clock-Pause von 'nur' 8xClock-Periode. Da ist man fast schon auf Hardware-SPI angewiesen und muss schauen, dass mann das SPI-Datenregister auch jeweils zügig füllt.


    Gruss
    Neni

    Geeignet wären da auf jeden Fall die F-Typen der üblichen TLC-Verdächtigen (i2C), also TLC59108F oder TLC59116F (die sind Open Drain). Alternativ gibt's noch den PCA9634 von NXP. Allerdings muss man beachten, dass die erwähnten Chips alle eine sehr hohe PWM-Frequenz von fast 100 kHz haben (kürzeste PWM-Pulsbreite nur 40 ns), was besondere Anforderungen an die externen Schaltstufen stellt.


    Ansosnsten kann man natürlich die Sache auch mit den Chips mit KSQ lösen, also praktisch auch alle chinesischen: WSxxxx, TMxxxx, LPDxxxx, MYxxxx (insbesondere MY9221).


    Gruss
    Neni

    Ja, das sehe ich auch so. MY9941 und MY9942 sind durchaus interessante Chips für DMX-steuerbare Standalone-Lampen (RGB-Spots, RGB-Röhren etc.), welche man dann in ein DMX-Setup einbeziehen kann. Dass man keinen µC zu programmieren braucht, um eben eine RGB-Leuchte DMX-fähig zu machen, ist sicherlich für viele Bastler auch recht interessant.


    Für eine Pixel-Matrix (wo die einzelnen Pixel ja nicht allzu weit voneinander entfernt sind) finde ich, dass DMX mit seinen 250 kbps als Bus zwischen den einzelnen Pixeln schon grundsätzlich eher ungeeignet ist. Da haben die synchronen, seriellen Übertragungsverfahren (mit Clock und Data) mit Daisy-Chain-Pufferung eindeutig Vorteile.


    Auf der MY-Semi Website habe ich bisher noch keine Informationen (auch keine Ankündigung) zu den beiden, neuen Chips gefunden.


    Gruss
    Neni

    Hallo Andre,


    das Problem kann auch daher rühren dass du 'nur' mit einem Datenpuffer (DmxRxField) als Sende- und Empfangspuffer arbeitest und dabei der Empfangs- und Sendevorgang für die Frames asynchron abläuft. Das kann dazu führen, dass während die Ausgabe eines Frames per SPI läuft, gerade auch der Puffer via DMX-Empfang beschrieben wird. Das kann dann dazu führen, dass Daten des 'alten' und des 'neuen' Frames gemischt in die WS2801 gelangen und erst beim nächsten SPI-Durchlauf dann wieder alle Pixel die neuen Daten haben (wenn die SPI-Übertragungen häufiger stattfinden als die DMX-Framerate). Das kann dann eben u.U. zu Flackereffekten führen.


    Du kannst das für den Fall von relativ geringem DMX-Daten-Aufkommen (eher kürzere DMX-Frames und nicht so hohe Frameraten) pro Modul relativ einfach mit dem Einfügen eines zusätzlichen Flags für das Frame-Ende lösen. Dabei wird die SPI-Übertragung jeweils immer nur nach dem Empfang eines vollständigen DMX-Frames (für das jeweilige Modul) gestartet und hat dann im Prinzip genügend Zeit für die SPI-Ausgabe zur Verfügung bis zum Empfangsstart des nächsten DMX-Frames, ohne dass es zu Überlappungen kommt. Das gilt wie gesagt für die oben erwähnten Voraussetzungen. Hier mal als Beispiel die entsprechenden Einträge in deinen Code:


    Für Fälle wo ein Modul jeweils ein grosses DMX-Datenframe bei höheren Frameraten empfangen und ausgeben muss, empfiehlt es sich, einen doppelt so grossen Datenpuffer einzurichten, und dann im Ping-Pong-Verfahren jeweils die Puffer-Teile (z.Bsp. via Index-Offset) für Empfang und Ausgabe alternierend umzuschalten.


    Gruss
    Neni

    jetzt bin ich verwirrt! mein bascom mit aktuellen updates zeigt mir 1.12.4.0


    Hallo tauruz,


    dann wirst du wahrscheinlich auch ein Problem haben. Denn meines Wissens hat es eine Version 1.12.4.0 nie gegeben. Nach 1.12.0.0 kam direkt 2.0.0.0, dann 2.0.1.0 etc. bis 2.0.4.0.


    Geh mal auf der MCSELEC-Seite ins Registration/Update-Interface (einloggen) und lade dir das aktuelle LIC-File und am Besten auch noch gleich den aktuellen Update Wizard (1.0.0.19) runter. Probiere dann mit diesem, ein Update zu machen. Bei veralteten UpdateWizards kann es eben auch zu Problemen beim Update kommen. Normalerweise werden die zwar auch automatisch upgedatet, sobald ne neue Version verfügbar ist, aber naja, es kann ja vielleicht auch mal schief gehen. Bei deiner BASCOM-Versionsnummer (1.12.4.0) scheint es eben irgendwie auch ein unvollständiges Update gegeben zu haben. Falls LIC-File und neuester UpdateWiz nix bringen, dann am Besten auch gleich einen clean install mit der neuesten VollVersion (auch via Registration/Update downloadbar) machen.


    Übrigens musste ich beim Wechsel 1.x auf 2.x nichts besonderes unternehmen. Das ist bei mir wie immer problemlos auch via UpdateWiz abgelaufen.


    Gruss
    Neni

    Hallo Florian,


    ich habe dir mal 'mein' m1280def.dat (umbenannt nach m1280def.txt zum Hochladen; du must es also wieder nach .dat umbenennen, damit du es nutzen kannst) hochgeladen:
    m1280def.txt


    Allerdings glaube ich ehrlich gesagt nicht, dass dir das weiter hilft, denn das dat-File wurde zuletzt am 22.7.2010 geändert, und auch der TIMSK-Eintrag ist nicht drin, was sich allerdings beim Minimal-Config-Code nicht auswirkt, da dabei keine Interrupts freigegeben werden müssen (somit kein Zugriff auf TIMSK).


    Dein Fehler mit TCC53A (wobei es sich eben um einen Schreibfehler im BASCOM-Compiler-Code handelt; es muss ja TCCR5A oder TCCR3A heissen) ist meiner Meinung nach auf eine veraltete BASCOM-Version zurückzuführen (ich meine, mich wage an so eine Fehlermeldung im MCSelec-Forum erinnern zu können), welcher mittlerweile in den neuen Versionen schon längst korrigiert wurde.


    Falls du dir dennoch ganz sicher bist, die neueste Version von BASCOM zu haben (die ist übrigens 2.0.4.0), würde ich dir vorschlagen, einen clean install von BASCOM (neueste Version) zu versuchen. Es könnte nämlich sein, dass irgendein Update mal nicht vollständig durchgelaufen ist und deine Installation irgendwie korrumpiert hat.


    Gruss
    Neni