Bestes 8051-Mikrocontroller-Modell für eine Tastatur?

- Cypress FX2 series
- AT89C5131A-M von Atmel
- CH558/9 von WCH

Das ist leider heutzutage so, der Fortschritt ist so krass das man nicht 
immer von NULL anfangen kann. Ehlich gesagt, fand ich das Assembler 
Gedöns in meiner Ausbildung stets zum Kotzen ;-)

Welche Klasse und Schule betrifft das denn?

P.Loetmichel schrieb:
> Periphere Geraete mit einem
>> USB Bootloader
> finde ich immer doof, wenn sie ihre Firmware aus dem Treiber ziehen.

Das hast Du falsch verstanden. Der wird einmal über den USB-Bootloader 
geflasht und ist dann programmiert und unabhängig.

Gruß
Jobst

Hier im Forumsmarkt verkauft doch Roger welche?
Beitrag "[V] 8St. 8051er Philips P89C51RC+IA PLCC44 (6€)"

Schnell verfügbar und eigentlich sogar günstig ;-)

73 55

Alex schrieb:
> und eine
> USB-Schnittstelle oder genügend Pins, um so ein externes USB-Ding zu
> verwenden (bin auch offen für Vorschläge dazu)

das ist schon eine "krasse" Anforderung! Soll die zu bauende Tastatur 
sich an einem PC als Tastatur ausgeben (und wie eine solchige verwendet 
werden)?

Wenn dem so ist, ist das schon sehr sehr sportlich für einen Schüler. 
Eine USB-Kommunikation zu implementieren selbst bei im Chip 
implementierter USB-Peripherie ist schon eine große Herausforderung.

Ich kann mir nicht vorstellen, dass ein Lehrer eine solchige Aufgabe 
verteilt (es sei denn, er hat selbst keine Ahnung davon, wie aufwändig 
das werden wird).

Alternativ hierfür, gäbe es "fertige" Programmbeispiele für 
Tastaturtreiber auf AVR-Basis, realisiert mit einem (eher unschönen, 
weil Spezifikation verletzendem) V-USB.

Da das ganze allerdings ein MCS51 System werden soll ist das schon sehr 
"krass"

OT:
P.Loetmichel schrieb:
> war der Kamerad schon ablebig. Abhilfe: Booten.

<doof>Ich habe dabei an einen Dienst namens "kamerad" denken müssen, und 
erst nach dem dritten Lesen ... Aahhhh! Das können die Linux Menschen 
bestimmt verstehen. (Ich brauch ne Mittagspause)</doof>

Steve schrieb:
> Die Technik hinter der schönen Fassade ist viel komplexer geworden.
> Sogar so komplex, dass so manches Projekt außer Kontrolle geraten ist.
JOAAH
:OT

Ralph S. schrieb:
> Da das ganze allerdings ein MCS51 System werden soll ist das schon sehr
> "krass"

Da sich da 2 Welten treffen (USB und MCS51), kann ich mir nur 
vorstellen, das der Tutor da was ganz bestimmtes im Auge hat - oder 
völlig weltfremd ist.

Matthias S. schrieb:
> Ralph S. schrieb:
>> Da das ganze allerdings ein MCS51 System werden soll ist das schon sehr
>> "krass"
>
> Da sich da 2 Welten treffen (USB und MCS51), kann ich mir nur
> vorstellen, das der Tutor da was ganz bestimmtes im Auge hat - oder
> völlig weltfremd ist.

Ich verstehe das mit den 2 Welten oder dass das krass sein soll nicht 
...
In vielen leistungsfähigen USB-Devices finden sich MCS51 wieder. z.B. in 
USB2 (HS) -> ATAPI Brücken. Die laufen dann z.B mit 30 MIPS. (bsp. 
TUSB6250 den man für dieses Projekt auch benutzen könnte.)
Die SI Bees sind noch flinker.
AVRs sind da weiter von weg ...

Gruß
Jobst

Ralph S. schrieb:
> Alternativ hierfür, gäbe es "fertige" Programmbeispiele für
> Tastaturtreiber auf AVR-Basis, realisiert mit einem (eher unschönen,
> weil Spezifikation verletzendem) V-USB.

Wobei die Verletzungen sich in diesem Falle noch in Grenzen halten, im 
Gegensatz zum Versuch Bulk-Transfers (z.B. serial Devices) über LowSpeed 
abzuwickeln.

Jobst M. schrieb:
> In vielen leistungsfähigen USB-Devices finden sich MCS51 wieder. z.B. in
> USB2 (HS) -> ATAPI Brücken. Die laufen dann z.B mit 30 MIPS.

Da wird wahrscheinlich aber eine Menge Hardware-Unterstützung dabei 
sein, mindestens DMA? Mit 30 MIPS die 60 MByte/s zu übertragen könnte 
doch etwas knapp werden?

Steve schrieb:
> Die Technik hinter der schönen Fassade ist viel komplexer geworden.
> Sogar so komplex, dass so manches Projekt außer Kontrolle geraten ist.

In der Tat, viel Projektarbeit besteht darin, verschiedene komplexe 
Komponenten unter einen Hut zu bringen. Früh damit anzufangen, sich mit 
fertigen Libraries (die natürlich immer mies dokumentiert, verbuggt, 
schlecht portabel, ineffizient sind) herumzuschlagen, ist vielleicht gar 
nicht so falsch.

Niklas G. schrieb:
> Früh damit anzufangen, sich mit
> fertigen Libraries [...] herumzuschlagen, ist vielleicht gar
> nicht so falsch.

Und sobald man sie beherrscht, sind sie wieder obsolete.
Oder DAS: https://www.golem.de/2209/168134.html
'Fürn Ar***'

Ralph S. schrieb:
> Ich kann mir nicht vorstellen, dass ein Lehrer eine solchige Aufgabe
> verteilt (es sei denn, er hat selbst keine Ahnung davon, wie aufwändig
> das werden wird).

Naja, Lehrer eben. Selbst wenn sich der Schüler die Aufgabe selbst 
ausgesucht hat, wird der Lehrer sie nicht einschätzen können ...

"Okay, ich verteile dann mal die Aufgabenstellungen für die Projekte.
Kevin: Gravitationsfreiheit in der Nähe von großen Massen.
Chantal: Gewinnung elektrischer Energie aus Umgebungstemperatur.
Justin: Reisen mit Überlichtgeschwindigkeit ohne negativen Zeitablauf.
Ihr habt 4 Wochen Zeit inklusive eines ansatzweise funktionierenden 
Versuchsaufbaus!"

Reaktionen der Schüler: Ein genervt, gelangweiltes "Okay"


Niklas G. schrieb:
> Jobst M. schrieb:
>> In vielen leistungsfähigen USB-Devices finden sich MCS51 wieder. z.B. in
>> USB2 (HS) -> ATAPI Brücken. Die laufen dann z.B mit 30 MIPS.
>
> Da wird wahrscheinlich aber eine Menge Hardware-Unterstützung dabei
> sein, mindestens DMA? Mit 30 MIPS die 60 MByte/s zu übertragen könnte
> doch etwas knapp werden?

Natürlich läuft da DMA. Wesentlich mehr als 30MB/s fließen dort dennoch 
nicht, da die 480MBit/s von USB HS für beide Richtungen zusammen gelten. 
IdR. schreibt oder liest man von der HDD, nicht jedoch gemischt. Das 
würde nicht nur bei mechanischen Platten länger dauern, als dies 
hintereinander zu tun.

Dennoch sollte die CPU recht flink reagieren.

Eigentlich ging es mir aber nur darum zu zeigen, dass USB und MCS51 
nicht zwei Welten sind.


Gruß
Jobst

Äh schrieb:
> Braucht kein usb host somit
> Ch552

ja aber wo nimmst du die Portpins Pins her die er haben will?

Jobst M. schrieb:
> Eigentlich ging es mir aber nur darum zu zeigen, dass USB und MCS51
> nicht zwei Welten sind.

Hey, das soll eine Aufgabe für Schüler/Azubis sein, und ich wette, das 
es zwar solche USB/MCS-51 Devices gibt, du aber selber auch keine Lust 
hättest, da ein HID Device drauf zu implementieren, wenn es keinen 
schlüsselfertigen HID Stack für gibt.
Das ist nicht mal eben so programmiert.

Matthias S. schrieb:
> Hey, das soll eine Aufgabe für Schüler/Azubis sein, und ich wette, das
> es zwar solche USB/MCS-51 Devices gibt, du aber selber auch keine Lust
> hättest, da ein HID Device drauf zu implementieren, wenn es keinen
> schlüsselfertigen HID Stack für gibt.
> Das ist nicht mal eben so programmiert.

Für eine Tastatur dürfte ein externer UART-to-USB Wandler ausreichend 
sein.
Den könnte eine andere Gruppe auf dem CH552 implementieren. Dunkel in 
meiner Erinnerung gibt es einen Hinweis darauf, daß es das schon gibt:
https://github.com/diodep/ch55x_dualserial
scheint das zu können.

Just my 2 cents

Klaus S. schrieb:
> Für eine Tastatur dürfte ein externer UART-to-USB Wandler ausreichend
> sein.
> Den könnte eine andere Gruppe auf dem CH552 implementieren.

es gibt von WCH fertigen HID Tastatur Code für die Chips. Die 
Erfindungshöhe wäre dann nur noch eine 70Zeichen Tastenmatrix 
anzuflanschen. Deshalb hatte ich auch den CH559 vorgeschlagen der auch 
genug Pins mitbringt.

Matthias S. schrieb:
> Hey, das soll eine Aufgabe für Schüler/Azubis sein, und ich wette, das
> es zwar solche USB/MCS-51 Devices gibt, du aber selber auch keine Lust
> hättest, da ein HID Device drauf zu implementieren, wenn es keinen
> schlüsselfertigen HID Stack für gibt.
> Das ist nicht mal eben so programmiert.

Da es USB-8051-Devices gibt, wird es auch HID Stacks dafür geben.

Und Du schätzt mich falsch ein: Ich würde es selber schreiben. Auch weil 
ich in dem Bereich schon SW geschrieben habe und nicht zuletzt, weil man 
nie weiß, welche Qualität der fremde Code hat.


Gruß
Jobst

Lothar schrieb:
> Das sind nur ein paar Codezeilen.

ROFL

Ja, das sind nur ein paar Zeilen Code, wenn man schon den gesamten 
Protokollstack hat. Also den grundsätzlichen USB-Device Stack und dann 
oben drauf den für HID.

Die Aufgabe ist ziemlich blödsinnig.

Entweder sitzt man da mindestens ein halbes Jahr dran und schreibt alles 
selber, oder man nimmt den Samplecode des Chipherstellers für eine 
Tastatur und passt das nur noch etwas an.

Lothar schrieb:
> Du würdest also einen USB device protocol stack selbst schreiben?

Du wirst lachen aber sowas hab ich schon gemacht, weil mir die 
Herstellerlösung nicht so gut gefallen hat. (natürlich mit Anleihen vom 
Originalcode)

> Du weisst aber schon, das macht niemand, der Hersteller vom uC muss den
> USB device protocol stack kostenfrei liefern.
erzähl das mal Atmel. Da sind die Herstellerbeispiele wirklich dünn 
gesät.
Bei TI gibts code oft nur unter NDA

Lothar schrieb:
> Du würdest also einen USB device protocol stack selbst schreiben?

Das habe ich auch schon mehrmals selbst getan, allerdings vor etwas 
längerer Zeit.

> Du weisst aber schon, das macht niemand, der Hersteller vom uC muss den
> USB device protocol stack kostenfrei liefern.

Alternativ kann man natürlich auch einen kommerziellen USB-Stack von 
einem Hersteller wie z.B. Thesycon erwerben.

Günni schrieb:
> Wenn man für die Rückmeldeleitung der Tastatur einen Baustein 74HC244
> nimmt, der direkt auf den Datenbus geht, reichen selbst einfache 8051
> Prozessoren für diese Aufgabe aus.

Na, da kannste mal sehen :-P Falls es nicht angekommen ist, der 
Keyboard-Matrix-Job ist nicht das Problem, auch nicht von der Pinanzahl. 
Der USB Anschluss ist das Problem. Da hilft kein '244er.
Ich habe sowas mal für ADB gebaut, aber nie für USB.