Hallo! Heute möchte ich mein neues Projekt uBoard vorstellen. Das uBoard ist ein minimalistisches AVR-Mikrocontroller Board. Es hat eine sehr geringe Größe (22.64mm x 12.06mm) und ist deshalb immer in der Tasche zuhaben. Wir entwickeln eine Vielzahl von Betriebsprogrammen die dein uBoard in ein Multi-Gerät verwandeln. Somit ist das Board vielseitig einsetzbar und der Umsetzung von neuen Ideen sind keine Grenzen gesetzt. Es befindet sich zurzeit in der Anfangsentwicklungsphase. Mehr Informationen unter http://www.mikroboards.de/uBoard Ich würde mich freuen wenn ihr ein paar Ideen, Vorschläge, Bewertungen oder sogar eine Teilnahme an der Umfrage - Runde 1 hinterlasst! Danke, Gruß Martin!
:
Bearbeitet durch User
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.
Martin Fischer schrieb: > Hallo! Heute möchte ich mein neues Projekt uBoard vorstellen. > > Das uBoard ist ein minimalistisches AVR-Mikrocontroller Board. > Es hat eine sehr geringe Größe (22.64mm x 12.06mm) und ist deshalb immer > in der Tasche zuhaben. > Wir entwickeln eine Vielzahl von Betriebsprogrammen die dein uBoard in > ein Multi-Gerät verwandeln. > Somit ist das Board vielseitig einsetzbar und der Umsetzung von neuen > Ideen sind keine Grenzen gesetzt. > > Es befindet sich zurzeit in der Anfangsentwicklungsphase. > > Mehr Informationen unter http://www.mikroboards.de/uBoard > > Ich würde mich freuen wenn ihr ein paar Ideen, Vorschläge, Bewertungen > oder sogar eine Teilnahme an der Umfrage - Runde 1 hinterlasst! > > Danke, Gruß Martin! ziemlicher müll den du da vertreiben willst ^^
und was kann man damit machen? es sind ja gar keine ein bz ausgänge frei??
(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!
Martin Fischer schrieb: > (2) - Dieses Board dient NICHT der Nutzung der IO Pins, sondern eher > sowas wie Passwortgenerator oder ähnliches! OTP-Generator wäre mir spontan auch eingefallen. Was gedenkst du, an sonstigen Funktionen für dein Board zu implementieren? Zumal ein Soft-USB ala V-USB eben auch nicht so das wahre ist...
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 ;)
Da dein Board dem PC keinerlei zusätzliche IO Möglichkeiten gibt, kann es ja nur noch zur Erweiterung der Rechenleistung dienen. Die vielleicht nutzbaren 1% der Rechenleistung des ATtiny (die restlichen 99% gehen ja für Software-USB drauf) sollen also den Treiber-Overhead auf PC-Seite wett machen und die Leistung zusätzlich zur Multi-GHz-CPU signifikant erhöhen? Ob dieser Rechnung habe in ja meine Zweifel. Passwort-Generatoren und OTP-Generatoren kann man übrigens problemlos auf PC's laufen lassen, die haben dafür genug Rechenleistung, da braucht's keinen ATtiny zur Unterstützung. Außerdem hat der PC gleich viel bessere Zufallszahlen-Generatoren...
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!
Martin Fischer schrieb: > oder dieses kleine Board was ich reinstecke und mir ein PW ausgibt und > fertig ists! Und natürlich noch eine CD oder normalen Stick mit Treibern und Benutzer-Software die man natürlich auch nur mit Admin/root Rechten installieren kann. Einfach nur deinen Stick anschließen bewirkt noch keine Anzeige eines generierten Passworts... Passwort Generatoren für den PC kann man auch aus dem Internet herunterladen, da braucht man gar nichts für mitschleppen. Das erscheint mir wesentlich einfacher. Einen solchen von einem normalen Stick zu starten ist auch unkomplizierter als erstmal Admin/root Rechte zu bekommen und dann Treiber zu installieren und dann eine GUI die die Anfragen an deinen Stick umleitet...
PS: Wenn du schon USB haben willst, nimm doch einen USB-fähigen Mikrocontroller, zB einen STM32F072CBT6. Das hat folgende Vorteile: * Viel Rechenleistungstechnisch für die eigentliche Anwendung übrig * USB-Spezifikation-konform (Spannungen) * USB Full Speed * 0 zusätzliche Komponenten für USB (kein Quarz, keine Dioden, keine Widerstände) * Hast allgemein genug Rechenleistung um USB ordentlich zu verarbeiten
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
Man könnte es höchstens als Tastatur nutzen und per Knopfdruck eine von der Länge voreingestelle Zufallszahlenkombination ausgeben lassen...ob das alerdings soviel Sinn hat... Gerade wenn man das "Gerät" als MULTI-Gerät tituliert
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!
Martin Fischer schrieb: > MIchaela schrieb: >> Länge voreingestelle Zufallszahlenkombination > > so ein Quatsch! Länge ist zufällig aber mind. 10 Zeichen oder so! lies genauer!
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
>Viele Betriebsprogramme! Ich sehe nicht ein einziges. >Bootloader demnächst verfügbar Also nicht vorhanden. Alles was ich sehe ist heisse Luft. Mit dem Board kann man nichts anfangen.
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.
:
Bearbeitet durch User
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.
Also soll ich PIC auch noch lernen/Wissen aneignen oder gleich ARM, was ist das beste für mich? AVR, PIC, ARM?
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.
:
Bearbeitet durch User
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.