uP Board, welche Bauteile

Technik Elektronik & Elektrotechnik
1

Hallo,

Ich bin gerade dabei, ein uP-Board zusammenzustellen.
Das letzte Mal, dass ich sowas gemacht hab, war vor über 10 Jahren…

So, welcher uP sollte man denn heut verwenden? Sollte schon die üblichen Konfigurationen haben. Spontan fallen mir hierzu genügend IOs, CPU nicht belastende Taktausgänge, RS232 Schnittstelle usw ein.
Hab an einen 16 Bitter gedacht…

Desweiteren, gibt es eigentlich TreiberIC für USB, welche bereits das gesammte Protokoll integrieren? Oder müsste man das dann komplett neu programmieren???

Hab bereits bei Conrad ein RS232-USB Adapter Modul gefunden, doch das kann dann doch wohl nicht 100% die USB-Möglichkeiten umsetzen, oder doch? Der Nutzen der Schnittstelle soll nähmlich ein doppelter sein:
a) PC Anschluss zur Programmierung/Auswertung/Debug
b) Externer Speicher in Memory-Sticks in FAT16 oder sogar NTFS

Danke für alle Anregungen
Tgellan

2

Hi!

So, welcher uP sollte man denn heut verwenden? Sollte schon
die üblichen Konfigurationen haben. Spontan fallen mir hierzu
genügend IOs, CPU nicht belastende Taktausgänge, RS232
Schnittstelle usw ein.
Hab an einen 16 Bitter gedacht…

Desweiteren, gibt es eigentlich TreiberIC für USB, welche
bereits das gesammte Protokoll integrieren? Oder müsste man
das dann komplett neu programmieren???

Für USB kann ich sehr die EZ-USB Bausteine von Cypress empfehlen. Ich selbst verwende schon öfter den AN2131. Es gibt auch noch verwandte Ausführungen mit weniger RAM. Verschiedene Gehäuse (mit verschiedener IO-Anzahl / zusätzlichem externem RAM) gibts auch.

Diese Chips haben 4-8kB RAM eingebaut, einen 8051 Derivat (also nur 8 Bit) (beschleunigt, aber 100% Opcode-komaptibel) und den USB-Core. Der Chip kann selbständig (ohne jemals eine Firmware gesehen zu haben) via USB die Firmware runterladen (ins eingebaute oder externe RAM) und legt dann gleich los mit der Ausführung. Man kann ihm auch ein kleines serielles EEPROM zur Seite Stellen, aus dem er dann die USB-IDs nimmt. Von dort kann er auch eine Firmware laden. Oder halt von einem externen EPROM. Der USB-Core selbst steht dann der Software zur Verfügung, damit man sehr sehr einfach USB-Packete verschicken und empfangen kann.

Von Cypress gibts auch neuere USB 2.0 Chips, die ähnlich aufgebaut sind.

Schau auch mal bei Texas Instruments nach der MSP430 Serie. Das sind 16-Bit RISC Chips, extrem Strom-sparend und (teilweise?) mit eingebautem Flash. Davon gibts (oder wirds bald geben) auch Varianten mit USB-Anschluss. Auch Infineon mit der XC166-Serie hat 16-Bit-Microcontroller, obs USB gibt, weiß ich nicht. Wenns Dich interessiert, frag ich mal nach, ich sitze hier praktisch neben dem zuständigen Herren. :smile:

Als High-End-Lösung würde ich den Infineon TriCore TC1130 vorschlagen, der hat USB 1.1 und Ethernet 10/100MBit eingebaut, ist aber 32 Bit. Sehr mächtiges Ding.

Ein weiterer Chip mit Ethernet ist der DS80C400 von Maxim/Dallas. Der hat auch einen 8051er eingebaut, allerdings mit aufgebohrtem Adress-Raum (16MByte). Außerdem ist der gesamte TCP/IP-Stack schon als ROM im Chip eingebaut, den man direkt von der eigenen Firmware benutze kann. Die Entwicklung eines eigenen TCP/IP-Stacks entfällt also. Außerdem kann dieser Chip direkt übers Netzwerk gebootet werden, ohne EPROM oder Flash.

Schau auch mal bei Analog Devices, die bieten einige DSPs an, die eventuell auch Deine Anforderungen erfüllen. Es gibt auch neurere Chips von denen, die einen ARM Prozessor eingebaut haben. Obs da auch USB gibt, musst mal suchen.

Bye
Hansi

3

Hallöchen

Auf [url]www.sprut.de[/url] findest du vieles zum Thema µC, die verschiedenen Typen und einige Beispiele, die dir den Einstieg erleichtern.
Gruß
Gley

4

Super Link!!!
Bin fast schons versucht PICs zu kaufen!

Muss aber noch kucken, wie es jetzt mit USB steht…

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

5

´n Abend…

Für USB kann ich sehr die EZ-USB Bausteine von Cypress
empfehlen. Ich selbst verwende schon öfter den AN2131. Es gibt
auch noch verwandte Ausführungen mit weniger RAM. Verschiedene
Gehäuse (mit verschiedener IO-Anzahl / zusätzlichem externem
RAM) gibts auch.

Diese Chips haben 4-8kB RAM eingebaut, einen 8051 Derivat
(also nur 8 Bit) (beschleunigt, aber 100% Opcode-komaptibel)
und den USB-Core. Der Chip kann selbständig (ohne jemals eine
Firmware gesehen zu haben) via USB die Firmware runterladen
(ins eingebaute oder externe RAM) und legt dann gleich los mit
der Ausführung. Man kann ihm auch ein kleines serielles EEPROM
zur Seite Stellen, aus dem er dann die USB-IDs nimmt. Von dort
kann er auch eine Firmware laden. Oder halt von einem externen
EPROM. Der USB-Core selbst steht dann der Software zur
Verfügung, damit man sehr sehr einfach USB-Packete verschicken
und empfangen kann.

Du hast doch bestimmt ein paar gute Links zu speziell diesen Chips? Wenn möglich auch Testboards, Entwicklungssoft usw. Sowas in der Art des oberen Beitrags zu „Spruts“
Hab zwar schons Cypress reingekuckt, doch der Wulst an Informationen dort ist nicht so recht das Richtige um einen groben Überblick zu erhalten :wink:

Momentan tendier ich zu PICs in Kombination zu „deinen“ EZ-USBs, muss aber noch kucken ob das realisierbar/sinnvoll ist :smile:)

Vorerst schons mal danke
Tgellan

6

Super Link!!!
Bin fast schons versucht PICs zu kaufen!

Hallo Tgellan,
wie Du schon richtig sagst, baut man sich die Umgebung eigentlich nicht mehr selber, sondern sucht sich ein Entwicklungskit. Ein Beispiel ist unter
http://www.glyn.de/content.asp?sid=0&lid=1&font_flg=…
zu finden, aber es gibt beliebig viele, je nachdem wo man sucht.

PICs programmiere ich auch sehr viel und recht gerne, aber m.E. ist das was für Bastler oder wenn es auf den Preis/Platz für einen Controller ankommt. Du wirst auch bei den größten PICs nie einen „richtigen“ Compiler bekommen, mit dem Du z.B. beliebige Pointer-Function-Indirektionen ausführen kannst. Das liegt zum Teil daran, dass es keinen wirklichen Stack gibt und Compiler bei dessen Emulation so ihre Probleme mitbringen.

Wenn Du aber Assembler programmieren willst, oder nur einfaches C verwendest, dann ist ein PIC durchaus O.K.!

Der Vorteil bei gängigen 16/32-Bittern mit EEPROM oder entsprechendem externen RAM ist z.B. der, dass komfortable Debugger mitgeliefert werden, wo beliebig viele Breakpoints möglich sind, und die einfach über die serielle Schnittstelle Funktionieren (ROM-Monitor).

Gruß
achim

7

Super Link!!!
Bin fast schons versucht PICs zu kaufen!

Ich tendiere eher zu MSP430. Leichter zu Programmieren, kein Paging.
http://www.my-japan.de/electronics/

Muss aber noch kucken, wie es jetzt mit USB steht…

PIC16C74x-Serie

8

Hi!

Du hast doch bestimmt ein paar gute Links zu speziell diesen
Chips? Wenn möglich auch Testboards, Entwicklungssoft usw.
Sowas in der Art des oberen Beitrags zu „Spruts“
Hab zwar schons Cypress reingekuckt, doch der Wulst an
Informationen dort ist nicht so recht das Richtige um einen
groben Überblick zu erhalten :wink:

Puh, Links habe ich da keine. Ich schau halt immer auf den Web-Seiten der Hersteller, vergleiche die Daten der angebotenen Bauteile, lad mir die Datenblätter runter, guck mir dort die jeweiligen Spezifika an, usw. Wenn du eh schon vor 10 Jahren mit µC zu tun hattest, wird dir das sicher auch jetzt noch sehr leicht fallen.

Momentan tendier ich zu PICs in Kombination zu „deinen“
EZ-USBs, muss aber noch kucken ob das realisierbar/sinnvoll
ist :smile:)

Das ist ein bisschen umständlich, weil du dann eine eigene Kommunikation zwischen dem PIC und dem EZ-USB machen musst, und das ist umständig, fehler-anfällig, viel Arbeitsaufwand, du brauchst dann auch Synchronisierung, … Da ist es gscheiter, du besorgst dir einen eigenen USB-Schnittstellen-IC ohne integrierter CPU. Cypress hat auch solche ICs, damit habe ich mich aber nicht beschäftigt.

Am Besten ist wirklich entweder nur den EZ-USB zu verwenden oder wenn du wirklich die 16-Bit-Leistung und das Memory brauchst einen 16-Bitter mit integriertem USB zu verwenden. Oder, falls es für dich in Frage kommt, statt USB auf Ethernet zu setzen. Leider find ich jetzt aber im Moment auch nix derartiges bei Infineon oder TI.

Bye
Hansi

9

Super Link!!!
Bin fast schons versucht PICs zu kaufen!

Hallo Tgellan,
wie Du schon richtig sagst, baut man sich die Umgebung
eigentlich nicht mehr selber, sondern sucht sich ein
Entwicklungskit. Ein Beispiel ist unter
http://www.glyn.de/content.asp?sid=0&lid=1&font_flg=…
zu finden, aber es gibt beliebig viele, je nachdem wo man
sucht.

Hm, also eigentlich wollte ich damit sagen, dass ich möglicherweise PICs, also die Chips kauf… Und dann wahrscheinlich den Brenner nach struts nachbau… Mit ein Hauptgrund hierfür ist halt der niedrige Preis.
Dabei ist schon klar dass ich damit das mir gestellte Endziel (USB-Stick ansprechen) wohl nicht realisieren kann. Doch zu mindest der (Wieder-)Einstieg wär dann schons gegeben. Nachträglich werd ich dann wohl auf was leistungsfähigeres umsteigen…

PICs programmiere ich auch sehr viel und recht gerne, aber
m.E. ist das was für Bastler oder wenn es auf den Preis/Platz
für einen Controller ankommt.

Naja, an den professionellen Einsatz hatt ich nicht gedacht :smile:
Und in punkto Platz, das ist in der Tat eins meiner grössten Probleme…

Du wirst auch bei den größten
PICs nie einen „richtigen“ Compiler bekommen, mit dem Du z.B.
beliebige Pointer-Function-Indirektionen ausführen kannst. Das
liegt zum Teil daran, dass es keinen wirklichen Stack gibt und
Compiler bei dessen Emulation so ihre Probleme mitbringen.

Das ist schon ein Problem, vor allem in hinsicht auf das Endziel… Also zB Linux Kernel kastriert auf das wesentliche, dann mittels entsprechendem Kompiler auf den Chip aufgespielt… Naja, zukunftsmusik :smile:

Wenn Du aber Assembler programmieren willst, oder nur
einfaches C verwendest, dann ist ein PIC durchaus O.K.!

Wird wohl in erster Instanz darauf hinauslaufen…

Der Vorteil bei gängigen 16/32-Bittern mit EEPROM oder
entsprechendem externen RAM ist z.B. der, dass komfortable
Debugger mitgeliefert werden, wo beliebig viele Breakpoints
möglich sind, und die einfach über die serielle Schnittstelle
Funktionieren (ROM-Monitor).

Hier seh ich momentan den Kontext nicht?
Meinst du bei einer gekauften Entwicklungsumgebung, oder eine bestimmte Firma, etc.?

Gruß
achim

Gruss zurück…:smile:
Tgellan

10

Du hast doch bestimmt ein paar gute Links zu speziell diesen
Chips? Wenn möglich auch Testboards, Entwicklungssoft usw.

Puh, Links habe ich da keine. Ich schau halt immer auf den
Web-Seiten der Hersteller, vergleiche die Daten der
angebotenen Bauteile, lad mir die Datenblätter runter, guck
mir dort die jeweiligen Spezifika an, usw. Wenn du eh schon
vor 10 Jahren mit µC zu tun hattest, wird dir das sicher auch
jetzt noch sehr leicht fallen.

Grins, klar passt schons… Ging mir ja nur um eine Richtung, um halt schons von vornherein 90% ausschliessen zu können…
Dennoch, um auf Cypress / EZ-USB zurückzukommen, was benutzt du denn an Entwicklungsumgebung? Hast ja eventuell was ganz einfaches, um die Chips zu brennen/kennen zu lernen, und dann auch was professionnelleres mit Debug/Compilern was-weiss-ich?

Bedankt

11

Hi!

Grins, klar passt schons… Ging mir ja nur um eine Richtung,
um halt schons von vornherein 90% ausschliessen zu können…
Dennoch, um auf Cypress / EZ-USB zurückzukommen, was benutzt
du denn an Entwicklungsumgebung? Hast ja eventuell was ganz
einfaches, um die Chips zu brennen/kennen zu lernen, und dann
auch was professionnelleres mit Debug/Compilern was-weiss-ich?

Ok, noch a bissi Infos zu Cypress. Die machen ziemlich viele verschiedene USB-Chips. Unter anderem haben sie auch welche mit eingebautem EPROM, die sind dann aber OTP, also „One Time Programmable“ ohne Fenster zum Löschen. Außerdem ist da ein eher seltener 8-Bit-Prozessor (M8) drin, also nix mit bekanntem 8051er. Assembler/Compiler? Weiß ich nix, wahrscheinlich teuer bei Cypress zu erstehen.

Direkt auf der Cypress-Hauptseite klicke auf „USB Full-Speed Peripherals“ (USB 1.1). Die EZ-USB Chips (alle AN21… weil diese Familie von Anchor Chip gekauft wurde) sind jene von denen ich das letzte Mal gesprochen habe. Es gibt auch eine Weiterentwicklung EZ-USB FX.

Die „USB High-Speed Peripherals“ sind für USB 2.0 gedacht. Die EZ-USB FX2 Chips sind den EZ-USB (FX) sehr ähnlich. Vielleicht gefällt dir auch der CY7C68001 aus der EZ-USB SX2 Serie. Das ist ein reiner USB-Interface Chip ohne eingebautem Prozessor. Den kannst Du dann zB von einem MSP430 oder XC166 aus für die USB-Kommunikation benutzen. Genauer habe ich mich damit aber nicht auseinandergesetzt.

Als Entwicklungsumgebung verwendet ich SDCC (http://sdcc.sourceforge.net/) da es diese Tools auch für Linux gibt. Zum Editieren verwende ich SetEdit (http://setedit.sourceforge.net/). So viel ich weiß hat auch Keil eine sehr gute Implementierung und Unterstützung all dieser Chips von Cypress.

Die erwähnten Microcontroller werden nie „gebrannt“, sie haben nur ein SRAM drin. Das ist ja gerade das bestechende daran. Sie erhalten die Firmware erst, sobald sie am USB-Bus angesteckt sind. Dadurch kann man vom PC ganz einfach via USB die Firmware runterladen. Nach jedem Entwicklungsschritt einfach nochmal. Kein PROM-Programmer notwendig, kein mühsames einstecken/ausstecken des Chips. Prinzipiell ist es nicht einmal notwendig, den USB-Bus abzustecken, da das SRAM via USB einfach überschrieben werden kann.

BTW: Die Treiberentwicklung ist unter Linux um einiges einfacher und für „normale“ Leute auch zugänglicher. Für Windows muss man ziemlich teure Tools kaufen damit man überhaupt die Erlaubnis bekommt, Treiber zu stricken. In Linux sind alle Tools und die gesamte Doku gleich dabei.

Bye
Hansi

12

Die „USB High-Speed Peripherals“ sind für USB 2.0 gedacht. Die
EZ-USB FX2 Chips sind den EZ-USB (FX) sehr ähnlich. Vielleicht
gefällt dir auch der CY7C68001 aus der EZ-USB SX2 Serie. Das
ist ein reiner USB-Interface Chip ohne eingebautem Prozessor.
Den kannst Du dann zB von einem MSP430 oder XC166 aus für die
USB-Kommunikation benutzen. Genauer habe ich mich damit aber
nicht auseinandergesetzt.

Sieht nicht schlecht aus :wink: Eventuell auch das ISD-300A1 Teil, bin noch dabei die Docu genauer zu kucken, hauptsächlich was die folgende Stelle angeht:
„Standard 8- or 16-bit external master interface
—Glueless interface to most standard microprocessors
DSPs, ASICs, and FPGAs
—Synchronous or Asynchronous interface“

Die erwähnten Microcontroller werden nie „gebrannt“, sie haben
nur ein SRAM drin. Das ist ja gerade das bestechende daran.
Sie erhalten die Firmware erst, sobald sie am USB-Bus
angesteckt sind. Dadurch kann man vom PC ganz einfach via USB
die Firmware runterladen. Nach jedem Entwicklungsschritt
einfach nochmal. Kein PROM-Programmer notwendig, kein mühsames
einstecken/ausstecken des Chips. Prinzipiell ist es nicht
einmal notwendig, den USB-Bus abzustecken, da das SRAM via USB
einfach überschrieben werden kann.

Em, ok…
Doch das bedeutet doch dann auch, dass sobald ich den Saft abdreh das Teil wieder leer ist?! Sprich das Programm=Treiber wird jedesmal neu runtergeladen?
Das ist ja in Ordnung bei Computer Hardware, doch als StandAlone? Oder überseh ich da was? Klar man kanns auch puffern…

… In Linux
sind alle Tools und die gesamte Doku gleich dabei.

Du meinst jetzt doch nicht wohl in den Distributionen, oder? Wohl doch eher die Entwicklungsumgebung unter Linux? Bitte um Berichtigung, falls ich falsch liege…:smile:

13

Hallo Tgellan

Der Vorteil bei gängigen 16/32-Bittern mit EEPROM oder
entsprechendem externen RAM ist z.B. der, dass komfortable
Debugger mitgeliefert werden, wo beliebig viele Breakpoints
möglich sind, und die einfach über die serielle Schnittstelle
Funktionieren (ROM-Monitor).

Hier seh ich momentan den Kontext nicht?
Meinst du bei einer gekauften Entwicklungsumgebung, oder eine
bestimmte Firma, etc.?

Ein Typisches Starter-Kit sieht so aus, dass Du im Prinzip eine mini-Platine mit Prozessor, inverter für eine Sio, Quarz, evt. externes Ram/Flash hast, also eigentlich einen „nakten“ Prozessor. Und dazu ein Nullmodem-Kabel, und irgendwie eine Spannungsversorgung.

Einen Emulator / Programmmer brauchst Du bei diesen Paketen nicht, da die Programmme per serieller Schnittstelle geladen werden. Da das Programm im Flash oder Ram läuft, und ein sogenannter ROM-Monitor mitgeliefert wird, kannst Du auch Step-für Step debuggen, breakpoints setzen, variablen angucken. Und das alles auf C-Ebene, inclusive dem Auflösen von Strukturen, pointerreferenzen etc. Du kannst als Den Inhalt des (fiktigen) pointers MyStruct.myLimits.mypointer[4] ansehen.

Das alles bieten PICs nicht, bzw. nur sehr unzureichend (ICD2, MPLAB). Wer etwas anderes kennt, kann mir gene schreiben.

Vor 5 Jahren hatte ich ein TOPAS-Board von Toshiba, dass all die oben genannte Features bot. Heute ist das Standard, unter dem sollte man nur anfangen, wenn man Basteln will, nicht wenn man mit Microcontrollern arbeiten möchte.

Ein Starterkit kostet meist ca. 200DM - 200Euro, aber oft gibts die auch kostenlos, wenn man denen irgendwas blödes erzählt (Ausbildung, alle Programmieren hier und für Testzwecke…).

Wenn Du nachher eine eigene Lösung bauen willst, kannst Du die Schaltpläne meist 1zu1 übernehmen, oder noch einfacher, du kannst die Kern-Platine (meist ~ 5x5cm) mit Steckerleisten in eine eigene Peripherie setzen. Jedenfalls kanns Du in der Endhardware debuggen.

PICs sind m.E. nur dann toll, wenn man von vornherein nichts weiter will als klein/klein basteln, oder wenn man große Systeme kennt und für Minianwendungen Preis/Stromaufnahme/Größe kalkuliert hat.

Gruß
achim

14

Nachtrag
IDE, Compiler (meist ohne praktische Limitierungen), Debugger (auf c-Sourcecode-Ebene, Variablen, Breakpoints, …), Datenblätter, Schaltpläne … sind bei diesen Sätzen natürlich alle auf CD dabei.

Gruß
achim

15

Hi!

Sieht nicht schlecht aus :wink: Eventuell auch das ISD-300A1
Teil, bin noch dabei die Docu genauer zu kucken, hauptsächlich
was die folgende Stelle angeht:
„Standard 8- or 16-bit external master interface
—Glueless interface to most standard microprocessors
DSPs, ASICs, and FPGAs
—Synchronous or Asynchronous interface“

Lass dich davon mal nicht täuschen, das sind einfach 3 Stück 8-Bit-Ports. Standardmäßige Hardware-Unterstützung für die vielen genannten Interfaces musst du per Software herstellen. Das einzige was „Standard“ ist, sind die Memory-Zugriffe mit #WR, #RD, ALE, D0-7, A0-15.

Em, ok…
Doch das bedeutet doch dann auch, dass sobald ich den Saft
abdreh das Teil wieder leer ist?! Sprich das Programm=Treiber
wird jedesmal neu runtergeladen?
Das ist ja in Ordnung bei Computer Hardware, doch als
StandAlone? Oder überseh ich da was? Klar man kanns auch
puffern…

Genau. Wenn du ein Gerät baust, das sowieso nur in Zusammenarbeit mit einem PC funktioniert (zB ein Oszilloskop oder Messgerät das kein eigenes Display hat sondern die Messwerte am PC anzeigt) dann ist das ok. Wenn du ein Gerät baust, das nur hin und wieder mit dem PC verbunden wird (Service, Datenaustausch, …) dann funktioniert das natürlich nicht wie beschrieben. Aber, die EZ-USB Chips suchen nach einem Reset selbständig nach einem externen seriellen EEPROM. Daraus lesen sie erstens die USB-IDs oder zweitens die Firmware. Alternativ kannst du auch ein externes EPROM mit dem „#EA“ Pin aktivieren.

… In Linux
sind alle Tools und die gesamte Doku gleich dabei.

Du meinst jetzt doch nicht wohl in den Distributionen, oder?
Wohl doch eher die Entwicklungsumgebung unter Linux? Bitte um
Berichtigung, falls ich falsch liege…:smile:

Sicher! Bei Debian habe ich alle Tools dabei. SuSE Professional liefert auch alle mit. Selbiges gilt bestimmt auch für Fedora, Mandrake, … Und wenn nicht, kannst du sie sehr einfach herunterladen. Es ist ja alles Open Source.

Bye
Hansi