RS232 nach I2C Konverter

Will man mal ein neues I2C-Device schnell ausprobieren, dann hilft dieses kleine Microcontroller-Tool:

formatting link

Kann man sowohl interaktiv von einem Terminal-Programm verwenden, wie Minicom unter Linux, oder Hyperterminal unter Windows, als auch von Programmen aus ansteuern.

Was haltet ihr von dem Interface? Könnte man wohl noch kompakter gestalten, aber so kann man auch Fehler simulieren, wie z.B. nach einem Restart eine andere Slave-Adresse senden.

Ich werde bei Gelegenheit damit mal den SI570 Oszillator ausprobieren, den mir Cypress als Muster zugeschickt hat. Ist nicht ganz so leicht zu programmieren, aber gibt zumindest eine Application Note mit Quelltext dazu.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss
Loading thread data ...

Frank Buss schrieb:

Aha. Du schreitest voran :-)

Du hast wirklich den Controller per Hand initialisiert?! Vermutlich kann dann aber das Projekt nicht mehr vollständig geklont werden, also auf einen anderen Controllertyp portiert werden. Bin mir aber nicht sicher. Ich benutze immer den Designer.

Von der Bootsequenz solltes du allerdings die Finger lassen. Da sind ne Menge Feinheiten drin, die man besser Cypress überläßt.

Eine blöde Sache ist z.B. wenn man auf externes Quarz mit PLL einstellt, und dann kein Quarz bzw. ein defektes dran hat. Der Controller kommt damit nicht zurecht. Andere Firmen haben das geschickter gelöst.

Aber bald kommt ja PSoC3.

- Henry

--
www.ehydra.dyndns.info
Reply to
Henry Kiefer

Ja, so schwierig ist das nicht. Ein Tag lang das TRM von Cypress lesen und probieren und es läuft. Wenn das TRM nicht so redundant und mit vielen Querverweisen wäre, dann wäre ich da auch früher mit fertig gewesen. Und dann sind wichtige Dinge, wie eine Statemachine bei I2C, nur per Textbeschreibung enthalten, die man sich aus verschiedenen Stellen zusammensuchen muss. Oder die Diagramme sind missverständlich: So suggeriert z.B. Figure 28-3, daß man erst ein Start per I2C_MCR triggern muß und dann die I2C-Adresse in I2C_DR schreibt, was aber genau umgekehrt ist. Gibt aber schlimmere technische Beschreibungen, im Prinzip ist alles drin.

Was mir nicht so gefällt, sind die umständlichen und eingeschränkten Routing-Möglichkeiten mit den Global Inputs und Global Outputs. Spart vielleicht ein paar Gatter, aber mehrere universellere Routing-Matrizen fände ich besser. Und warum kann man das I2C-Modul nicht beliebig routen oder mit beliebigen Takten versorgen?

Und da ich schonmal am nörgeln bin: Bei Ausführgeschwindigkeit mit 4 bis zu

15 Takten pro Befehl ist der M8C Core auch nicht gerade der schnellste (lcall braucht z.B. 13 Takte). Silicon Laboratories demonstriert, daß das besser geht: Die meisten Befehle werden in zwei Takten ausgeführt, einige auch in einem, relalisiert durch eine Pipeline-Architektur.

Schön an den PSoC Chips ist, daß die relativ einfach zu programmieren sind im Vergleich zu FPGAs, insbesondere auch zur Laufzeit leicht Teile des Chips umschaltbar sind, was bei FPGAs erst in Ansätzen möglich ist und dann auch nur bei den größeren Modellen. Und die Cypress Chips sind festverdrahtetes und gut getestetes Silizium (gehe ich zumindest mal von aus), da kann man dann weniger Fehler machen. Aber wenn FPGAs oder CPLDs noch ein wenig billiger werden und auch Analogfunktionen bekommen, dann könnte diese Reihe ganz schnell aussterben.

Sollte eigentlich schon möglich sein, da die grundsätzliche Architektur bei allen PSoC-Chips dieselbe ist. Gibt allerdings teilweise mehr Rows und andere Digital- und Analogelemente, sodaß man da wohl schon ein wenig umprogrammieren müsste.

Die Bootsequenz habe ich erstmal belassen, aber ein externer Quarz sollte ja sowieso nicht defekt sein, sonst bringt der ja nix :-)

Was gibt es denn da neues?

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Hut ab. Einen Tag, hoffentlich mit Kaffee. Andere schauen wohl Fußball.

i2c ist in mehreren Varianten implementiert. Bislang habe ich die Software-Version benutzt und es ging problemlos. An anderer Stelle wird berichtet, das es Fehler geben soll.

So nebenbei: Das UART-Modul hat massive Schwierigkeiten zu resynchronisieren wenn das Eingangssignal stark verrauscht ist. Ein PC-UART macht wesentlich weniger Zicken. Ich meine damit nicht deine Software, sondern das Cypress-Modul.

Welche i2c-Variante meinst du? Es gibt Software-only und Hardwareunterstützte.

Die PSoC-Matrix ist leider an vielen Ecken nicht sonderlich universell. Es geht auch nicht Pull-Up-Rs und ein Usermodul gleichzeitig an einen Pin zu hängen. Ist mir auch von deren Support bestätigt worden. Eine Eigenschaft, die man bei i2c gut brauchen könnte. Oder man schaltet halt zwei Pins zusammen.

Schau mal in die Groups. Dazu habe ich bereits einiges geschrieben. Auch in Englisch. Mit PSoC Generation 3 soll es auch einen ARM core geben. Ist aber bereits mehrmals um Jahre verschoben worden...

Ich hatte allerdings noch nie ein Geschwindigkeitsproblem. Ist vermutlich eher akademisch. Der Flash ist sowieso nur max. 32K groß. Was will man da sonderlich viel Funktion unterbringen. Ich lande meist bei 10K ROM und 100B RAM ;-)

Die analogen FPGAs sind fast alle vom Markt verschwunden! Die PSoCs sind mehrmals revidiert worden und es gibt auch Erratas zu den Chips.

Ich dachte der Modul Placer brauch die Daten des vorherigen Laufs? Aber nie probiert.

Manche Chips erkennen mithilfe des internen Hilfsoszillators einen defekten Quarz und schalten dann auf den internen um. Macht PSoC aber offensichtlich nicht. Zumindest bei mir nicht. Quarze sterben in stressigen Umgebungen schonmal einfach so. Und dann steht die Kiste!

Google einfach mal. Bei psocdeveloper.com gibts auch ne Menge dazu.

- Henry

--
www.ehydra.dyndns.info
Reply to
Henry Kiefer

Fußball interessiert mich nicht so sehr, es sei denn es ist ein RoboCup Turnier :-)

Der Master-Betrieb scheint gut zu laufen.

Das wundert mich nicht, da in der Doku was davon steht, daß in der Mitte eines Bits gesampelt wird. Nichts von Oversampling oder Glitch-Unterdrückung für die Startbiterkennung usw. In meiner relativ EMV-sauberen Umgebung hier läuft es aber fehlerfrei.

Die hardwareunterstützte. Software-only wird wohl nicht gehen, wenn man z.B. 400 kHz nehmen will und die Zeiten laut Philipps Spezifikation sauber einhalten will und auch bei 100 kHz könnte es knapp werden (die Hardwareimplementierung verwendet ein 8-fach Oversampling).

Zwei externe Widerstände kosten ja auch nicht die Welt :-) Vielleicht sollte man so eine PSoC-Architektur mal in einem FPGA implementieren. Man muß ja nicht die LUTs des FPGAs selbst dynamisch konfigurieren, sondern kann Matrizen und LUTs mittels LUTs simulieren. Wird zwar nicht mega-schnell sein, aber da könnte ich mir einiges vorstellen. Habe schonmal an einem System per FPGA mitgearbeitet, was serielle Audiodaten in Echtzeit geroutet hat (24 Bit, 96 KHz, eine ganze Menge an Kanälen). Wenn man nicht sehr kurze Latenzzeiten und parallele Abarbeitung braucht, dann kann man mit relativ wenig Aufwand und einem internen BRAM viele Ein- und Ausgangskanäle beliebig routen und auch mit internen Funktionen verschalten.

Kommt ganz drauf an, was man damit so machen will. Wenn man irgendwelchen rechenintensiveren Auswertungen wie FFT o.ä. damit machen will, wird es knapp, aber da würde wohl auch die Silabs-Architektur an die Grenzen stoßen. Der ARM-Core ist schon eine schöne Sache und von Atmel die Microcontroller sind ja mittlerweile auch kaum teurer.

Vielleicht sollte man analog und digital lieber ganz trennen. Im Prinzip könnte man mit einem schnellen FPGA viel an Analogschaltungen mit ein paar externen schnellen Comparatoren, analogen Multiplexern und OPs aufbauen.

Module habe ich ja keine plaziert, kann also nichts schieflaufen.

Sieht gut aus: PSoC5 mit ARM und PSoC3 mit 8051:

formatting link

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

Ein Hardliner :-)

Bislang auch nur so verwendet.

Ich hatte es für Funkverbindungen mißbraucht ;-)

i2c spezifiziert keine Mindestfrequenz, deswegen geht auch Bit-Banging so gut. SMBus spezifiziert 10kHz.

Das i2c-Hardwaremodul geht auf die Clock-Anschlüsse, an denen der Controller auch sein Programmierkabel sehen will. Bei den größeren PSoC-Varianten habe ich auch ein weiteres Pinpaar sichten können. Im Pin Designer kann man schauen, welche Pins welche Sonderfunktion haben können. Chips mit mehr als 28 Pins habe ich bislang nicht benutzt. Die PSoC gibt es ja mit 100 Pins. Es sind aber nur wenige unterschiedliche Dies! Deswegen kann man I/O-Bits, die stillliegen, durchaus als Datenspeicher benutzen.

Ich hoffe du hast nicht zu viel getrunken :-) So Fieberträume habe ich manchmal auch.

Man ist halt hin- under hergerissen und natürlich hat jeder Microcontrolle seine eigene Entwicklungsumgebung.

Das ist richtig. Jetzt noch die Schlagwörter SC-Filter und Sigma-Delta-Modulatoren.

Ja, habe es mir angesehen. Eine Superfunktion für unbekannte Busdevices zu finden ist ein Address-Scan. Geht bei i2c ja problemlos mit dem Address-Ack. Manche Hersteller geben nämlich die heimatliche i2c Adresse schief an. Der Si570 soll auch so ein Kandidat sein.

formatting link

Du bekommst nur unter vorgehaltener Hand irgendwelche Infos. Momentan kann man es einfach vergessen. Der wievielte Herbst soll das sein? Es sind bereits einige vergangen. Ist sozusagen der genaue Gegensatz zu Maxim. Das mit dem 8051-Kern kann man wohl kippen. Es wird eine superschnelles Update der bisherigen CPU geben und dann eben den ARM-core. Was mir versprochen wurde sind auch Varianten in normalen DIP-Gehäusen. Das finde ich sehr angenehm.

Dein obiger Artikel ist für die bisherige Cypress Policy jedenfalls sehr offenherzig. Wundert mich.

- Henry

--
www.ehydra.dyndns.info
Reply to
Henry Kiefer

Ich nehm' dafür immer das hier:

formatting link

Und dann reicht ein open() auf /dev/i2c-0.

Gruß Henning

Reply to
Henning Paul

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.