uBoard - USB Multi-Gerät

Nur am Rande bemerkt: Informiere Dich mal über die Impressumspflicht 
gewerblicher Internetauftritte und die Konsequenzen des Nichteinhaltens. 
Das (deutsche) Internet ist voll von Abmahnanwälten, die davon leben, 
Dir derlei Dinge gegen heftige Abmahngebühren "beizubringen".

Ja: Das ist ein gewerblicher Internetauftritt.

(1) - Habe Impressum hinzugefügt, hoffe das ist so richtig. Danke für 
die Warnung!

(2) - Dieses Board dient NICHT der Nutzung der IO Pins, sondern eher 
sowas wie Passwortgenerator oder ähnliches!

Gruß Martin!

Ja gut zunächst möchte ich erstmal diese Einfache Idee umsetzen und ein 
paar nützliche Firmwares machen die dann auch einen Sinn haben. 
Passwortgenerator oder so halt.

Was später kommt weiß ich noch nicht, du kannst ja bei der Umfrage was 
vorschlagen ;)

Geschmackssache ob ich nen Stick mit mir rumschleppe mit ner Software 
drauf oder dieses kleine Board was ich reinstecke und mir ein PW ausgibt 
und fertig ists!

Ich hätte hier einen PIC16F1455 eingesetzt. Billig, klein (14 Pin), hat 
aber Hardware USB 2.0 und ist damit voll USB 2.0 standardkonform 
(zertifiziert), und Hardware UART/SPI/I2C/AD etc sind auch mit dabei. 
Den fertigen USB-Stack gibts bei Microchip, und den darf man auch für 
kommerzielle Produkte kostenlos einsetzen.

fchk

Hallo Martin,

für mich ähnelt das Ganze von der Hardware her ziemlich dem "AVR Stick" 
von Sparkfun.

https://www.sparkfun.com/products/9147

Viele Grüße

Christoph

Multi bezieht sich auf die Nutzung verschiedener Firmwares und

MIchaela schrieb:
> Länge voreingestelle Zufallszahlenkombination

so ein Quatsch! Länge ist zufällig aber mind. 10 Zeichen oder so!

Ist ja auch egal denn:

BIG EDIT

Aufgrund von Unzufriedenheiten und Anregungen von euch allen habe ich 
mich entschieden dem Board noch die SPI-Schnittstelle zur Verfügung zu 
stellen!

Seht genaueres unter http://www.mikroboards.de/uBoard

Es ist auch zurzeit in der Entwicklungsphase und würdest du aufmerksam 
die Seite lesen wärst du auf die Umfrage gestoßen und hättest alles 
begriffen!

Bitte hört auf Kommentare zu schreiben wenn ihr nichts ordentlich 
durchlest!

Mit so etwas würdest Du hier ernst genommen werden, nicht mit der x-ten 
Variation einer vusb-Applikation eines Anfängers.

http://inversepath.com/usbarmory

fchk

Ich bin 16 Jahre alt und sogesehen Anfänger und freue mich wenn ich 
sowas mache, also kritisiere nicht mit deinem Projekt was ja viel besser 
ist und von Profis gebaut und entwickelt wird, sondern freue dich dass 
die Nachkommende Generation interesse zeit und auch Willen etwas zu 
machen!

Wenn es dich glücklich macht klatsche ich in der nächsten Version einen 
atmega32u4 rauf, der echtes USB hat und sowieso viel besser ist oder 
gleich nen xmega oder arm prozessor, das ist dann blos nicht mehr die 
idee von dem board!

Martin Fischer schrieb:
> Ich bin 16 Jahre alt und sogesehen Anfänger und freue mich wenn ich
> sowas mache, also kritisiere nicht mit deinem Projekt was ja viel besser
> ist und von Profis gebaut und entwickelt wird, sondern freue dich dass
> die Nachkommende Generation interesse zeit und auch Willen etwas zu
> machen!
>
> Wenn es dich glücklich macht klatsche ich in der nächsten Version einen
> atmega32u4 rauf, der echtes USB hat und sowieso viel besser ist oder
> gleich nen xmega oder arm prozessor, das ist dann blos nicht mehr die
> idee von dem board!

Komm mal runter. Und hör einfach nicht auf negative Stimmen. Wer etwas 
macht MUSS damit rechnen das Gegenstimmen aufkommen. Und es natürlich 
auch aushalten können. Lass dir von denen nichts vorschreiben, mach dein 
Ding!

JEDER im Internet denkt er wäre der Mittelpunkt. Und so verhält sich 
auch jeder.

Ok danke. Ich freue mich einfach über das was ich amche und demonstriere 
es anderen auch - diskussionen trete ich gerne bei - aber wenn mir eine 
kritik nicht gefällt werd ich mich einfach nicht aufregen, danke!

Ich könnte so etwas mit großem STM32F4 gebrauchen. Teensy hat mir zu 
wenig Flash. Hintergrund ist ein Sicherheitsbedürfnis, ähnlich wie Du es 
für Deinen Stick motivierst. Allerdings muss die Anwendung schon auf dem 
Board laufen und da geht mit attiny nicht viel. Der Attiny schränkt auch 
Deine Möglichkeiten ein, etwas zu realisieren und anzubieten, was 
wiederum jemanden überhaupt veranlassen könnte, Deine Boards (dazu) zu 
kaufen.

Bzgl. der USB-Key-Stick-Anwendung ergibt sich gegenüber einem 
USB-Flashstick kaum ein sicherheitsrelevanter Vorteil. Bei anderen 
Anwendungen kommt es nicht auf ein paar Quadratzentimeter an.

Da Du beidseitig bestückst, brauchst Du das Board für ein 100er Package 
kaum größer machen. Mit 100er package hast Du vermutlich viele 
Bestückungsoptionen für STM32Fx.

Vorschläge:
. SPI braucht SS.
. Pinout RM1.27. Für 2.54 jeden Zweiten oder über 1.27Kabel auf 
2.54-doppelreihig.
. Pinout als Pads oder halbe Vias.
. Eine USB-Buchse vereinfacht den Standalone-Betrieb. An fremden PCs 
würdest Du einen USB-Key-Stick aus Sicherheitsgründen ohnehin nicht 
jederzeit überall anschließen und in deiner Notebooktasche ist Platz für 
ein kurzes Kabel. Für einen USB-Key-Stick wäre gerade der 
PCB-USB-Stecker sehr ungeeignet.
. Wenn es zu klein ist, lässt es sich nicht gut abziehen.
. Distanz Bauelement<->USB-Kontakt? (wegen Steckverbindung)

Von großen Stückzahlen kannst Du erstmal nicht ausgehen. Und mit großen 
Stückzahlen nimmt auch der Preis für den uC ab.

Lars R. schrieb:
> . SPI braucht SS.

Stimmt, daran hatte ich gar nicht gedacht! Naja ohne kann man halt nur 
ein Erweiterungsmodul nutzen außer wenn man ein Shift-Register als SS 
nimmt.

Lars R. schrieb:
> . Pinout RM1.27. Für 2.54 jeden Zweiten oder über 1.27Kabel auf
> 2.54-doppelreihig.

Das Verstehe ich grade nicht so wirklich.

Martin Fischer schrieb:

> Lars R. schrieb:
>> . Pinout RM1.27. Für 2.54 jeden Zweiten oder über 1.27Kabel auf
>> 2.54-doppelreihig.
>
> Das Verstehe ich grade nicht so wirklich.

Ich schlage 1.27RM vor und zeige 2 Opionen für RM2.54 vor, die mit einem 
1.27RM genutzt werden können.

1.27mm Flachbandkabel geht auf 2.54RM-doppelreihige Stecker

Ach du meinst statt die Pinheaders(2.45) soll ich Lötpads drauf bringen 
für ein Flachbandkabel(1.27)?

1.27 statt 2.54: ja

Ob für direktes Anlöten des Kabels oder single-row-Pinheader, sei dahin 
gestellt. Weiterhin kannst Du die through-hole-pads an den Rand bringen, 
so dass die Hälfte der Pads ausserhalb des Boards liegt. Dann kann man 
SMD oder through-hole anlöten. <- Muss mit der PCB-Fertigung passen. <- 
Probieren.

Martin Fischer schrieb:
> Ich bin 16 Jahre alt und sogesehen Anfänger

Aha, war meine Einschätzung richtig.

> Wenn es dich glücklich macht klatsche ich in der nächsten Version einen
> atmega32u4 rauf, der echtes USB hat und sowieso viel besser ist oder
> gleich nen xmega oder arm prozessor, das ist dann blos nicht mehr die
> idee von dem board!

Es geht um Deine Kundschaft. VUSB ist aus meiner Sicht Pfusch. Zwar gut 
gemachter Pfusch, aber dennoch. Eine USB-Konformitätsprüfung hat das nie 
bestanden und wird es sehr wahrscheinlich auch nie, und ohne das darfst 
Du das genau genommen gar nicht USB nennen. Im geschäftlichen Verkehr 
(in den begibst Du Dich mit Deiner Webseite gerade) ist so etwas 
wichtig: das nennt sich in der Juristerei "zugesicherte Eigenschaft".
Und dabei ist es ja nicht so, dass Du keine Alternativen hast. Der von 
mir genannte PIC16F1455 ist so eine - wenn Du Analog nicht brauchst, ist 
der PIC16F1454 noch ein wenig billiger. Und er hat zertifiziertes USB 
2.0, auch sonst einiges an Peripherie und ist dabei gar nicht mal 
teurer, wie ich eben bei digikey gesehen habe. Und wenn Du TSSOP nimmst, 
bleibt es von der Bauform gleich trotz 6 Pins mehr. Das wäre eine 
technisch saubere Lösung, die man auch an einen USB-Testplatz hängen 
könnte, ohne vor Scham rot zu werden.
Natürlich gibts auch von anderen Herstellern Alternativen, da musst Du 
eben Deine AVR-Scheuklappen mal runternehmen (ja, ich weiß, das ist 
schwer und macht Arbeit) und schauen, was so geht.

fchk

Naja mal shen, eigl beschäftige ich mich nur mit AVR und nicht mit PIC 
o.A.

Ich baue jetzt erstmal noch paar Vorschläge ein und demonstriere diese 
morgen, vielleicht findest du es dann ja auch nützlicher, bis Morgen!!

Martin Fischer schrieb:
> Naja mal shen, eigl beschäftige ich mich nur mit AVR und nicht mit PIC
> o.A.

wie so viele andere auch. Deswegen hast Du ja auch ganz laut "Aua" 
geschrien, als ich Dich etwas provokant gepiekst habe.

Denke immer an den Kunden! Dem ist egal, was drin steckt. Es muss 
reproduzierbar funktionieren und den Spezifikationen genügen. Da musst 
Du als Entwickler eben flexibel sein. Dümmer wirst Du dadurch nicht.

Durch die Beschränkung auf AVR kommt eben manchmal nur Suboptimales 
raus.

fchk

Frank K. schrieb:

> Denke immer an den Kunden! Dem ist egal, was drin steckt. Es muss
> reproduzierbar funktionieren und den Spezifikationen genügen.

Weiterhin:
a. Nutzen für den Kunden
b. Vorteile gegenüber bereits Verfügbarem
c. Preisleistungsverhältnis (Stückzahlen, stückzahl-abhänige 
Stückkosten)
d. Aufwandsminimierung für zukünftige Entwicklungen/Produkte

Spricht alles gegen 8Bit für ein neues uC-Board. Zumal er sich bereits 
0603 zutraut.

Frank K. schrieb:
> Martin Fischer schrieb:
>> Naja mal shen, eigl beschäftige ich mich nur mit AVR und nicht mit PIC
>> o.A.
>
> wie so viele andere auch.

...vielleicht liegt das an der Ausbildung.

Martin Fischer schrieb:
> Also soll ich PIC auch noch lernen/Wissen aneignen oder gleich ARM, was
> ist das beste für mich? AVR, PIC, ARM?

ARM. Du brauchst nicht alles können, was mit ARMs möglich ist. Es geht 
um die Performanz und um die Möglichkeit, verschiedenste Anwendungen 
zukünftig realisieren zu können. Aufgrund Deines vorgestellten AVR-PCBs 
schätze ich, dass ARM-ICs bis Cortex M4 (und zukünftig vielleicht bis 
M7) hinsichtlich PCB-layouten und PCB-bestücken genau das Richtige für 
Dich sind.

Ein Design könntest Du wieder im Forum vorstellen. (Wichtig sind die 
Kondensatoren in der Nähe der Power-Pins). Ebenso einfach Fragen, wenn 
Du ein Problem hast. Die Handhabung von ARM könntest Du mit Eval-Boards 
für ein paar Euro probieren. z.B. STM32F4 Discovery, falls Du ARM von ST 
nimmst. Es gibt Tutorials, Minimalbeispiele, Youtube-Videos...

Martin Fischer schrieb:
> Also soll ich PIC auch noch lernen/Wissen aneignen oder gleich ARM, was
> ist das beste für mich? AVR, PIC, ARM?

Dem Produkt würde es gut tun, ja.

Ich habe etwa 20 Jahre vor Deiner Geburt mit dem Z80 angefangen. Da habe 
ich etwa ein Jahr gebraucht, bis ich alles so weit konnte, dass ich im 
Kopf assemblieren und nur noch Hexcodes eintippen konnte. Ich hatte 
damals nur einen Disassembler, aber keinen Assembler. Für den 6502 habe 
ich dann nur noch 6 Wochen gebraucht, wobei der zugegebenermaßen auch 
einfacher war.

Also: Kennst Du einen, kennst Du sie alle. Vor allem, da Du in C 
programmierst und das prozessorübergreifend verfügbar ist. Voraussetzung 
ist, dass Du das Ganze wirklich verstanden hast und nicht nur Copy&Waste 
machst und Dinge wie Lateinvokabeln auswendig lernst.

Bei Microchip hast Du den Vorteil, dass Du in einer Umgebung mit einem 
PICKit3 vom kleinen 6-Pinner bis hoch zum 200 MHz 32 Bit PIC32MZ alles 
programmieren und debuggen kannst und eine im Vergleich zu Atmel größere 
Peripherieauswahl vorfindest, wobei die Peripherie selber 
leistungsfähiger ist, zB: Ethernet MAC+PHY eingebaut, CAN in kleinen 
Prozessoren, LIN, USB in kleinen Chips. Aktuell sind 900 PIC-Varianten 
erhältlich, und Microchip hat seit 1992 nie eine abgekündigt. Und: Du 
hast auch 16 und 32 Bit Prozessoren im DIL-Gehäuse.

ARM ist von den Kernen her natürlich führend. Aber: Wenn Du Dir die 
Chips verschiedener Hersteller anschaust, haben die eben nur den nackten 
Prozessorkern gemein, und das ist recht wenig. Die gesamte Peripherie 
ist total unterschiedlich, das Flash wird von Hersteller zu Hersteller 
unterschiedlich programmiert, etc etc. Es ist zB einfacher, Code von 
einem Atmel SAM3irgendwas auf einen AVR32 zu portieren als auf einen 
STM32F3 zB. Warum? SAM3 und AVR32 haben zu großen Teilen identische 
Peripherie, und die unterschiedlichen Prozessorkerne werden zum großen 
Teil von den Compilern verdeckt. Ob Du nun den gcc-arm oder den 
gcc-avr32 benutzt, ist Dir im wesentlichen egal, die Optionen sind 
dieselben. Das nutzt Atmel beim AVR-Studio aus, und aus dem Grund 
investiert Atmel auch nicht mehr so viel in AVR32. Es rechnet sich 
nicht, und sie haben nicht die Finanzen, beides gleichzeitig mit voller 
Kraft zu machen.
Also lass Dich von der ARM-Übermacht nicht blenden.

Die Antwort lautet also: alle. Was eben für Dein jeweiliges Projekt am 
besten passt. Du bist ja noch jung, Du hast noch Zeit.

fchk

Martin Fischer schrieb:
> Kannst du mir ein minimal Beispiel oder tutorial empfehlen?

Ich komme aus einer anderen Ecke und habe nur in einem anderen 
Zusammenhang Cortex-M3-Erfahrung.

Anhand folgender Einstiegspunkte würde ich mit GCC und Eclipse anfangen:
ARM
STM32 (Tutorials, Demos, usw)
STM32F4-Discovery
STM32 Eclipse Installation
http://www.youtube.com/watch?v=HKX12hJApZM
http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF252419


Die Einarbeitungszeit in Prozessorarchitekturen und 
Entwicklungsumgebungen ist erheblich. Ich bevorzuge, soweit möglich, mit 
Hersteller-übergreifende Tools. Beispielsweise lieber Eclipse als eine 
komplett anders zu bedienende, Hersteller-spezifische IDE. Weil man 
nicht weiß, wann man doch mal wechseln muss und der Support im Netz 
sowie Weiterentwicklung besser ist.

Hinsichtlich der Prozessor-Architektur könnte man so wählen, dass man 
mit möglichst geringem Aufwand den Chip-Anbieter wechseln kann. Für ARM 
gibt es derzeit 3 (oder 4?) Anbieter.

Die ARM-Übermacht muss man nicht gut finden. Aber wenn man ohne 
Notwendigkeit auf ein Nischenprodukt setzt, schadet man sich selbst.

Ich sehe keinen Grund, für jedes Projekt den Chipanbieter (z.B. 
Atmel/Microchip) oder die Prozessorarchitektur zu wechseln. Wichtiger 
ist meiner Ansicht nach, dass man von LED-an-aus bis FreeRTOS und ggf. 
uCLinux gut aufgestellt ist. Dies ist mit ARM-Architekturen gut möglich.

> Die Antwort lautet also: alle. Was eben für Dein jeweiliges Projekt am
> besten passt. Du bist ja noch jung, Du hast noch Zeit.

Diesen Hinweis finde ich kontrakroduktiv und nicht ok. Die Zeiten ändern 
sich. Die eigenen, zeitlichen Ressourcen sind begrenzt.

Ausserdem möchte er bereits im Alter von 16 Jahren Kondensatoren 
verbauen, die kürzer sind als ein DIL-Beinchen. Die langfristige 
Richtung ist BGA und DDR-Speicherinterfaces und nicht 16Bit-uCs im 
DIL-package.

Lars R. schrieb:
> Martin Fischer schrieb:

> Die Einarbeitungszeit in Prozessorarchitekturen und
> Entwicklungsumgebungen ist erheblich. Ich bevorzuge, soweit möglich, mit
> Hersteller-übergreifende Tools. Beispielsweise lieber Eclipse als eine
> komplett anders zu bedienende, Hersteller-spezifische IDE. Weil man
> nicht weiß, wann man doch mal wechseln muss und der Support im Netz
> sowie Weiterentwicklung besser ist.

Sehe ich anders. Ich habe seit Ende der 70'er/Anfang der 80'ern so 
vieles kommen und gehen gesehen. Produktwissen hat halt eine gewisse 
Halbwertszeit, das muss man akzeptieren. Egal, was es ist. Man lernt zu 
lernen. Das ist der Trick.

> Ausserdem möchte er bereits im Alter von 16 Jahren Kondensatoren
> verbauen, die kürzer sind als ein DIL-Beinchen. Die langfristige
> Richtung ist BGA und DDR-Speicherinterfaces und nicht 16Bit-uCs im
> DIL-package.

Aber BGA und DDR3 macht man nicht eben mal so zuhause. Da hört es dann 
langsam auf. Die wenigsten Leute haben die Messtechnik vorrätig, um ein 
DDR3-Interface zu debuggen. Das ist dann nämlich alles andere als 
billig. Und eine Leiterplatte mit 8 Lagen sprengt auch ganz schnell das 
Budget, erst recht als Einzelstück.

Ich denke auch nicht, dass die kleinen Controller verschwinden werden. 
Es werden immer noch gigantische Mengen an 4-Bit (!) Controllern 
verbaut, in Uhren, Zahnbürsten, Thermometern und anderen Geräten, wo man 
es einfach nicht sieht. So lange es Kosten spart, wird es gemacht.

fchk

Frank K. schrieb:
> Lars R. schrieb:
>> Martin Fischer schrieb:
>
>> Die Einarbeitungszeit in Prozessorarchitekturen und
>> Entwicklungsumgebungen ist erheblich. Ich bevorzuge, soweit möglich, mit
>> Hersteller-übergreifende Tools. Beispielsweise lieber Eclipse als eine
>> komplett anders zu bedienende, Hersteller-spezifische IDE. Weil man
>> nicht weiß, wann man doch mal wechseln muss und der Support im Netz
>> sowie Weiterentwicklung besser ist.
>
> Sehe ich anders.

Vielleicht nicht, weil:

> Ich habe seit Ende der 70'er/Anfang der 80'ern so
> vieles kommen und gehen gesehen. Produktwissen hat halt eine gewisse
> Halbwertszeit, das muss man akzeptieren. Egal, was es ist. Man lernt zu
> lernen. Das ist der Trick.

Zustimmung. Deshalb mein Vorschlag, sich möglichst 
Hersteller-übergreifend aufzustellen. Und der Vorschlag, sich nicht mit 
allem möglichen zu beschäftigen, das veraltet, ohne das man es wirklich 
mal gebraucht hat.

>> Ausserdem möchte er bereits im Alter von 16 Jahren Kondensatoren
>> verbauen, die kürzer sind als ein DIL-Beinchen. Die langfristige
>> Richtung ist BGA und DDR-Speicherinterfaces und nicht 16Bit-uCs im
>> DIL-package.
>
> Aber BGA und DDR3 macht man nicht eben mal so zuhause. Da hört es dann
> langsam auf. Die wenigsten Leute haben die Messtechnik vorrätig, um ein
> DDR3-Interface zu debuggen. Das ist dann nämlich alles andere als
> billig. Und eine Leiterplatte mit 8 Lagen sprengt auch ganz schnell das
> Budget, erst recht als Einzelstück.

Das geht schon mit überschaubaren Kosten, wenn man nicht gleich mit DDR3 
anfängt. Ich habe auch eine zukünftige Orientierung aufzeigen wollen.

> Ich denke auch nicht, dass die kleinen Controller verschwinden werden.
> Es werden immer noch gigantische Mengen an 4-Bit (!) Controllern
> verbaut, in Uhren, Zahnbürsten, Thermometern und anderen Geräten, wo man
> es einfach nicht sieht. So lange es Kosten spart, wird es gemacht.

Das sind alte Projekte und keine Zukünftigen. uCs mit wenigen Bits 
werden als SoC-Komponenten erhalten bleiben; integriert in 
Temperatursensoren und Spannungsüberwachungen mit sehr großen 
Stückzahlen. Teils auch aus historischen Gründen, weil es sich nicht 
lohnt, etwas Altes entwicklungstechnisch nochmal "anzufassen".

Aber deutsche Freiberufler und KMU machen (zukünftig) keine Projekte 
mehr, bei denen der Preisunterschied aufgrund der Wortbreite bis 32Bit 
hinsichtlich der Stückkosten des Boards oder Produktes eine Rolle 
spielt. Andere Kritieren sind wesentlich. Folglich bekommst Du auch den 
höheren Entwicklungsaufwand bei Verwendung eines uCs mit kleiner 
Wortbreite nicht amortisiert.

Ach du gute Güte, nimm bloß deine Handynummer aus dem Internet. Auch die 
Haustelefonnummer würde ich nicht im Klartext angeben.

Ach wieso? Ich habe da kein Bedenken

Um mal etwas konstruktives beizutragen: Das hier hätte Dein Projekt sein 
können. Ich habe es eben mal in der letzten halben Stunde so 
hingeworfen, was ich im Kopf hatte. Kannst Du Dir anschauen oder auch 
nicht. Es ist nicht besonders auf Größe etc optimiert.

fchk

Martin Fischer schrieb:

> sondern eher
> sowas wie Passwortgenerator oder ähnliches!

Implementier ne Firmware die unsignierte Bitcoin-Transaktionen signieren 
kann ohne daß dazu der PC jemals mit dem privaten Schlüssel in Kontakt 
kommt (kommen kann). Und das auf nem 8 bit Atmel.

PIC's scheinen tatsächlich sinnvoller zu sein als AVR's.

Nichts desto Trotz habe ich mich entschieden mir ARM (STM32 um genau zu 
sein) vorzunehmen.