Ich bin immer mal wieder in der Situation für ein neues Projekt den "besten" Mikrocontroller zu finden. Das einfachste ist natürlich eine Variante des persönlichen Lieblingschips zu nehmen, also in einer Chip Familie zu bleiben. Aber natürlich ist das nicht immer die "beste" Wahl. Wenn man wirklich den ganzen Markt betrachten will habe ich bisher nur Digikey, Mouser,.. gefunden. Also in deren Produkt Suche die Parameter einstellen die man braucht dann nach Preis suchen und mit dem billigsten Chip anfangen zu schauen ob das was gefunden wurde wirklich nutzbar ist. Das Problem ist das wenn man (nur als Beispiel) 2 SPI und 3 I2Cs braucht dann Chips findet die das zwar können aber halt nicht gleichzeitig (Pinmux) oder Chips nicht findet die das könnten (weil ein UART auch als SPI oder I2C genutzt werden kann). Manchmal denkt man auch man hat einen Chip in der gewohnten Chip Familie gefunden, merkt dann aber bei Betrachtung des Datenblatts das da nur der Name ähnlich ist und "unter der Haube" die Unterschiede doch großer sind als gedacht. Meine Frage ist also gibt es eine Datenbank/WebSeite/Wiki/.. die genauere Informationen zu möglichst vielen Mikrocontrollern hat? Ich weiß das das eine große Menge an Daten ist. Aber bei manchen Debuggern kann man ja auch aus einer verdammt langen Liste von Chips auswählen und die Software weiß dann sofort wie viel Flash, RAM und so weiter der Chip hat. Vielleicht haben die Hersteller ja jeweils Listen Ihrer Chips? Bin ich der einzige der dieses Problem hat? Mache ich was falsch? Gibt es vielleicht eine bessere Lösung als so eine Datenbank?
Eine allgemeine Antwort gibt es so eigentlich nicht. Lars P. schrieb: > Gibt es vielleicht eine bessere Lösung als so eine Datenbank? Distris abklappern und deren parametrische Suche benutzen. Selbst eine Liste der Kandidaten erstellen und daraus auswählen. Wenn professionell => Die Einkaufsabteilung fragen oder Distri kontaktieren So eine Entscheidung ist natürlich immer voreingenommen nach bereits existierenden Tools und Bekanntheit der Plattform bei Entwicklern. Wenn professionell => Alle nötigen Tools mit in die Betrachtung einbeziehen (z.B. Unit-Testing on-Target mit Unterstützung debug-Hardware) mfg mf
PS Lars P. schrieb: > Vielleicht haben die Hersteller ja jeweils Listen Ihrer Chips? Das ist doch ein prima Anlaufpunkt. Auch die haben parametrische Suchen und Vorschläge für geplante Einsatzzwecke.
Lars P. schrieb: > Bin ich der einzige der dieses Problem hat? Fang einfach an, so eine Datenbank zu erstellen, dann finden sich schon Interessenten. Die Nutzung muss natürlich kostenlos sein, auch wenn du Jahre dafür brauchst. Georg
Lars P. schrieb: > Bin ich der einzige der dieses Problem hat? Sicherlich nicht, es gibt viele uC die gänzlich unbekannt sind aus Asien, vermutlich gibt es mehr uC Typen als Transistoren. Aber es kommt halt auf so viel mehr an, als SPI Ports, und wenn es uC das nötige nicht hat, wie EEPROM oder Hochstromports, wird es halt drangebaut. Die Kosten der Entwicklungsumgebung, der Stromverbrauch nicht in sleep sondern z.B. während LCD Ansteuerung, lieferbare Stückzahlen und extreme RadHard oder Umgebungstemperaturen, alles nicht in der Datenbank, daher sind die nutzlos.
MaWin schrieb: > Die Kosten der Entwicklungsumgebung, der Stromverbrauch nicht in sleep > sondern z.B. während LCD Ansteuerung, lieferbare Stückzahlen und extreme > RadHard oder Umgebungstemperaturen, alles nicht in der Datenbank, daher > sind die nutzlos. GELD darf in so einer Datenbank KEINE Rolle spielen. Der Wartungsaufwand wäre viel zu hoch. Man muss sich einfach auf die Felder/Parameter einigen vorher. Dann die Datenblätter eintragen und ein bisschen Abfrage-Programm dafür. Im Prinzip eigentlich nur eine Fleißaufgabe. Hinterher die Parameter die man braucht abfragen. Und das Ergebnis bei den Dealer seiner Wahl nach den Preis suchen. Gruß Pucki
Alexander K. schrieb: > GELD darf in so einer Datenbank KEINE Rolle spielen. Der Wartungsaufwand > wäre viel zu hoch. Man muss sich einfach auf die Felder/Parameter > einigen vorher. Dann die Datenblätter eintragen und ein bisschen > Abfrage-Programm dafür. Scheinbar ist der Konsens das so eine Datenbank toll wäre, es sie noch nicht gibt, sie kostenlos sei muss und besser sein sollte (also mehr Details enthalten) als was Distries und Hersteller so an parametrischer Suche anbieten. Und das es "nur eine Fleißaufgabe" ist mit der einfach jemand anfangen muss. Dann frage ich mal anders: Hat wer Lust mir dabei zu helfen? Ganz alleine einige ich mich bestimmt viel zu schnell "auf die Felder/Parameter" und das wäre ja dann ein Fehler. Wer jetzt noch nicht überzeugt ist: Ich würde für Unterstützung auch kein Geld anbieten! ;-)
Lars P. schrieb: > Das Problem ist das wenn man (nur als Beispiel) 2 SPI und 3 I2Cs braucht > dann Chips findet die das zwar können aber halt nicht gleichzeitig > (Pinmux) oder Chips nicht findet die das könnten (weil ein UART auch als > SPI oder I2C genutzt werden kann). Ich sehe keine Chance alle solche Einschränkungen zu erfassen und sinnvoll auswertbar zu machen. Es gibt alleine 1070 verschiedene STM32 und das ist nur eine von 6 Familien eines einzigen Herstellers.
Blechbieger schrieb: > Ich sehe keine Chance alle solche Einschränkungen zu erfassen und > sinnvoll auswertbar zu machen. Das wäre noch das kleinere Problem. Bei der Vielzahl an Daten ist das eine Lebensaufgabe. Dazu kämmen noch Copyright-Geschichten. Wenn jemand ein Unternehmen gründen würde, und dann den Zugriff auf so eine Datenbank gegen Kohle machen würde, könnte aus den Projekt was werden. Ich habe z.b. heute eine Datenbank gefunden mit ca. 32.000 Produkten zum Thema Homeautomation. Die kostet auch Geld. Und die stehen erst am Anfang. Gruß Pucki
Lars P. schrieb: > Dann frage ich mal anders: Hat wer Lust mir dabei zu helfen? Irgendwie erinnerte mich das Vorhaben an Don Quijote, habe es zur Sicherheit noch einmal gegoggelt, aber JA, die Geschichte passt genau. Brauchst Du nur noch genau einen treuen Gefolgen. Nix für Ungut, aber das kann nichts werden. Der Aufwand für eine halbwegs brauchbare Lösung wäre gigantisch, da es endlose Abhängigkeiten der Peripherals gibt. Zum Teil wird ja auch Peripheral A durch Peripheral B eingeschränkt, wenn man es mit der Methode C nutzt - sonst aber nicht. Du bräuchtest schon pro (ARM-) Controller zig Tage oder gar Wochen, um das sauber auseinander zu dröseln. Daneben kommen noch so Parameter wie Beschaffbarkeit (womöglich noch abhängig von der Stückzahl) usw. usw.
Mir ist auch klar das nicht das ganze tausend seitige Datenblatt für jeden Prozessor hinterlegt werden kann. Und manuell für jeden Prozessor diese Daten raus zu schreiben und dann ab zu tippen macht auch keinen Sinn. Meine Erfahrung ist das die Filter beim Distrie schlechter sind als die Product Selection Seiten beim Hersteller. Aber beim Hersteller hat man halt nur dessen Chips, und nicht die Konkurrenz. Ich habe gerade bei ST geschaut und deren Chip Vergleicher kann das Ergebnis als Excel exportieren. (Habe ich bei anderen Herstellern auch schon gesehen.) Da hat man dann eine Zeile pro Chip. Mit ein paar Zeilen Python bekommt man so eine Excel Tabelle zu einer Datenbank hinzugefügt. Wenn man das jetzt für jede Familie und jeden Hersteller macht ist das ein Haufen Arbeit aber wohl noch beherrschbar. Dann muss man aber auch noch eine Web Seite stricken mit Suchfunktion,.. ARM hat auch diese XPacks mit SVD Dateien spezifiziert. Die SVD Dateien sind XML und enthalten noch sehr viel detailliertere Informationen zum Chip. Das wäre also auch eine Überlegung wert diese einzusammeln und zu importieren. Selbst mit nur den Excel Imports wäre das für mich schon besser brauchbar als das was es jetzt gibt. So "gigantisch" das das deswegen nciht funktionieren kann finde ich den Aufwand nicht. Das ganze müsste halt eher so in Richtung Wikipedia gehen. Die ist auch nie fertig und keiner Beschwert sich. Aber ja es ist deutlich mehr Aufwand als das man das gerade mal so alleine hoch ziehen kann.
Wenn man das Projekt wirklich durchziehen will, würde ich mal die Hersteller anschreiben. Viele haben "Datenbanken" rumliegen. Einfach nur um ihren Kunden den richtigen Chip zu empfehlen. Ob sie die raus rücken ist eine andere Sache. Gruß Pucki
minifloat schrieb: > So eine Entscheidung ist natürlich immer voreingenommen nach bereits > existierenden Tools und Bekanntheit der Plattform bei Entwicklern. Was ich auch sinnvoll finde. Der Aufwand, sich mit neuen Arbeitsmitteln vertraut zu machen, sollte nicht unterschätzt werden.
Lars P. schrieb: > Hat wer Lust mir dabei zu helfen? Ich nicht, aber ich würde sie gerne benutzen :-) Das Problem ist, dass die Hersteller so schnell neue Chips auf den Markt werfen, dass man kaum nachkommt. Und wenn du ein paar neue Suchkriterien hinzufügst, musst du alle alten Datensätze entsprechend erweitern (=Datenblätter erneut lesen). Wer macht macht freiwillig über Jahrzehnte hinweg?
Microchip bietet eine parametrische Suche auf der Homepage an - ist zwar herstellerbeschränkt, man kann aber nach allen möglichen Kriterien nach MCUs suchen, also ARM, PIC, AVR, 8051, I2C, UART, Pinzahl, Speicher, Preis, eigentlich alles was es gibt. Man kann sich das ganze auch als eine Excel-Datei runterladen - dann hast du bereits alle MCUs von Microchip und kannst sie nach Lust und Laune filtern. https://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1005
>Ich habe gerade bei ST geschaut und deren Chip Vergleicher kann das >Ergebnis als Excel exportieren. (Habe ich bei anderen Herstellern auch >schon gesehen.) Da hat man dann eine Zeile pro Chip. Mit ein paar Zeilen >Python bekommt man so eine Excel Tabelle zu einer Datenbank hinzugefügt. Die Frage wäre aber, ob die Hersteller dieses Verfahren einfach so erlauben. Also daß Du einfach deren Zusammenfassungen dann auf Deiner Webseite veröffentlichst, und dann noch so tust, als wäre das Deine Arbeit gewesen.
Bitte neben den üblichen Verdächtigen auch folgende Hersteller mit berücksichtigen, denn die haben auch sehr interessante Sachen: ABOV ADI CMSEMICO ELAN EASTSOFT FORTIOR GIGADEVICE HITRENDTECH MDT MEGAWIN SOC SONIX STC SYNWIT MINDOTION und SINOWEALTH aber unbedingt und vorrangig: HOLTEK NUVOTON PADAUK und WCH Gerade NUVOTON kann man unmöglich auslassen.
Sorry, habe noch übersehen: Bojuxing Industry Puolop Aptchip Sinomicon Shenzhen Better Life Elec Rockchip General Plus HDSC Ixys Ironchip Renergy Generalplus Die hier auch, unbedingt, die machen auch sehr gute Sachen: http://www.zh-jieli.com/
Ah, sorry, zh-jieli.com muss ich zurücknehmen, da bin ich mir nicht ganz sicher, ob die uCs machen. Das sind mehr so ASICs. Na ja, alle kann man nicht berücksichtigen...
Jens G. schrieb: >>Ich habe gerade bei ST geschaut und deren Chip Vergleicher kann das >>Ergebnis als Excel exportieren. (Habe ich bei anderen Herstellern auch >>schon gesehen.) Da hat man dann eine Zeile pro Chip. Mit ein paar Zeilen >>Python bekommt man so eine Excel Tabelle zu einer Datenbank hinzugefügt. > > Die Frage wäre aber, ob die Hersteller dieses Verfahren einfach so > erlauben. > Also daß Du einfach deren Zusammenfassungen dann auf Deiner Webseite > veröffentlichst, und dann noch so tust, als wäre das Deine Arbeit > gewesen. Eine Web Seite nur mit den von ST generierten Excel Dateien macht doch gar keinen Sinn. Der Sinn diese Teils der ST Web Seite aber ist es doch gerade Informationen über Ihre Chips herauszugeben. ST will ja das man sich informiert welche Chips sie haben. Was ich vorgeschlagen habe ist ja nur nicht nur die zur Verfügung gestellten Informationen zu nutzen um von verschiedenen Herstellern die Informationen zusammen zuführen um dann suchen zu ermöglichen. Das heißt doch wohl das etwas anderes angeboten wird als das was auf der ST Seite gibt. Bevor man das macht sollte man aber noch mal schauen ob da nicht was kleingedrucktes auf er Homepage steht. Manche Hersteller lassen einen ja auch nur das Datenblatt herunter laden nach einem Login. In solchen Situationen könnte es durchaus sein das man das nicht so direkt nutzen kann und erst mal Nachfragen sollte, so wie von Pucki vorgeschlagen. Außerdem denke ich das es eh sinnvoll wäre zu den Suchergebnissen Links zum Hersteller anzugeben. Wenn man nach langem suchen den passenden Chip gefunden hat will man ja beim Hersteller die noch fehlenden Informationen (Datenblätter, Application Notes,...) einholen. Links zu den Distries damit man den tagesaktuellen Preis bekommt wären bestimmt auch sinnvoll. Und beides ist ja quasi Werbung. Da sollten Hersteller und Distries eigentlich glücklich sein drüber. Aber wir leben schon in einer komischen Welt manchmal.
Harald schrieb: > Bitte neben den üblichen Verdächtigen auch folgende Hersteller mit > berücksichtigen, denn die haben auch sehr interessante Sachen: Danke für die Liste. Gerade deswegen wäre so eine Datenbank ja so hilfreich, weil gerade diese Hersteller bestimmt oft übersehen werden. Aber bevor es losgehen kann fehlen noch ein paar Mitstreiter. Wenn es hilft würde ich den Server sponsern für den Anfang und beim befüllen der Datenbank helfen. Aber Web Seiten stricken ist leider gar nicht mein Ding.
Lars, danke für die Blumen, aber meine Beiträge waren eher ein wenig abschreckend gemeint! Schau Dir mal ein paar Webseiten der aufgeführten Kandidaten an. Alle gibt es tatsächlich und die machen auch wirklich tolle Sachen, vor allem preislich (Controller ab 2ct). Aber hier geht es schon mit der Informationsbeschaffung los. Die haben nur einen Bruchteil der Produkte auf der Webseite, dazu kommt die notwendige Übersetzung. Wenn man die weglässt ist die Datenbank aber auch schon wieder weniger hilfreich. Du hast ja gefragt, welche Alternativen oder evtl. besseren Weg es gibt. Meine Meinung: Aus Erfahrung wählen, dabei offen sein für Neues und auch mal etwas wagen, immer lernbereit sein. Randprobleme (EMV, Errata, Verfügbarkeit usw.) erkennen und einsortieren. Viel informieren. Erfahrung ausbauen und immer so weiter. Das ist wertvoller als eine Datenbank, denn die wird diese eigentlich unverzichtbaren Aspekte nie kennen.
Harald schrieb: > Lars, danke für die Blumen, aber meine Beiträge waren eher ein wenig > abschreckend gemeint! Schau Dir mal ein paar Webseiten der aufgeführten > Kandidaten an. Alle gibt es tatsächlich und die machen auch wirklich > tolle Sachen, vor allem preislich (Controller ab 2ct). Aber hier geht es > schon mit der Informationsbeschaffung los. Die haben nur einen Bruchteil > der Produkte auf der Webseite, dazu kommt die notwendige Übersetzung. > Wenn man die weglässt ist die Datenbank aber auch schon wieder weniger > hilfreich. Vergleich das doch bitte mal mit der jetzigen Situation. Wenn der Hersteller die Daten so schlecht verfügbar hat werden alle die die Informationen nicht finden diesen Hersteller nicht verwenden. Die wenigsten werden wohl deine komplette Liste abarbeiten. Wenn es die Chips nicht bei Digikey gibt ist meistens der Hersteller schon draußen. Wenn irgendwer es schafft Daten für diesen Hersteller zu finden kann er die dann in die Datenbank eintragen und alle die die Datenbank nutzen haben jetzt eine bessere Chance die Chips dieses Herstellers zu finden. Die Datenbank verbessert also die Situation für und Verwender und für die Hersteller, außer natürlich der Hersteller will nicht das wir seine Chips verwenden. Aber darauf können wir dann keien Rücksicht nehmen ;-) > Du hast ja gefragt, welche Alternativen oder evtl. besseren Weg es gibt. > Meine Meinung: Aus Erfahrung wählen, dabei offen sein für Neues und auch > mal etwas wagen, immer lernbereit sein. Randprobleme (EMV, Errata, > Verfügbarkeit usw.) erkennen und einsortieren. Viel informieren. > Erfahrung ausbauen und immer so weiter. Das ist wertvoller als eine > Datenbank, denn die wird diese eigentlich unverzichtbaren Aspekte nie > kennen. Ich versuche so meine Auswahl zu treffen. Leider sehe ich das viele es anders machen. Und ehrlich gesagt ist es auch eine Menge Aufwand. Ich habe mich halt gefragt warum muss jeder von uns selbst diese Erfahrungen sammeln und Risiken eingehen. Würde es nicht allen helfen wenn wir die gemachten Erfahrungen Teilen? Das man die Datenbank aus den Hersteller Seiten befüllt heißt ja nicht das kein User Feedback möglich sein soll. (Wikipedia !) Vielleicht können so die "alten Hasen" den jungen noch Tipps geben. Gerade Randprobleme oder Besonderheiten einzelner Chips, sind ja Dinge die in so einer Parametrischen Suche nicht auftauchen. Wenn da ganz tief im Errata steht das ein Interface nicht zuverlässig funktioniert dann könnte man das eintragen und alle die das Interface brauchen nehmen einfach einen anderen Chip.
Lars P. schrieb: > Gibt es vielleicht eine bessere Lösung als so eine Datenbank? Wenn man neue Mikrocontrollerhersteller kennen lernen möchte: - Besuche eine (Elektronik-)Messe - Gehe auf die Seite von deinem Distributor, treffe eine grobe Vorauswahl (Eigenschaften, die eher zwischen Herstellern und uC-Typen vergleichbar sind z.B. Pinanzahl, Architektur, Lagerbestand mind. 1k Stk., ...). Betrachte anschließend die verbliebenen Hersteller. Klappere deren Homepages ab und suche mit deren Parametrischer Suchfunktion.
Ich denke auch, dass eine Datenbank über uC eine Sisyphosaufgabe wäre. Die meisten Infos/Merkmale wusste ich nicht Mal zu kategorisieren, so unterschiedlich sind die. Eine Liste, in der vielleicht nur Hersteller und Familien aufgeführt sind, wäre schon mehr als genug. Und dann so Infos wie Architektur, spgsbereich, kleinste und größte Bauform, ob (freie) Compiler verfügbar, ob englische Datenblätter, Link zum Hersteller, spezielle Features, ... Und bei den spezielle Features erschlägt es einen dann schon. Allein die myriaden an (wichtigen) Modi für Timer oder uarts irgendwie zu kategorisieren ...
Harald schrieb: > Sorry, habe noch übersehen: > Puolop Wobei Puolop wohl hauptsächlich Padauk-µC unter eigenem Namen weiterverkauft. Anscheinend fertigt Padauk aber auch einige Semicustom-Varianten für Puolop, die man direkt bei Padauk nicht im Katalog findet.
Hallo Du kannst nicht alle Mikrocontroller erfassen. Das wird eine Lebendsaufgabe. Nimm doch nur die Controller die am meisten im Hobbybereich genutzt werden. Oben auf der Seite siehst du einen Filter unter denen Mikrocontroller aufgelistet sind. Nimm diese doch als Anfang und bau darauf deine Datenbank auf. Vielleicht solltest du zuerst einmal festlegen, welche Parameter du haben willst, von den verschiedenen Controller. Daraus eine Datenbank machen und dann kann ja jeder eintragen was er kennt vom Controller.
Stefan schrieb: > Vielleicht solltest du zuerst einmal festlegen, welche Parameter > du haben willst, von den verschiedenen Controller. Das kann schnell ziemlich viel werden. Es gibt zB nicht nur den Unterschied UART vs USART. Dann gibts ja noch USARTs mit einem "data timeout IRQ" um per DMA unbekannte längen eines Frames zu empfangen. Oder USARTs mit DE Pin welcher in HW die Senderichtung des RS485 Treibers umschalten kann. Bei sonem STM32 zB gibts ja schon eine Tabelle mit etlichen Einträgen was der USARTx jetzt eigentlich kann und was nicht. Autobauding zB steht da auch drinne. Kurz gesagt: das wird eine riesen Menge an Paramatern!
Lars P. schrieb: > Wenn es die Chips nicht bei Digikey gibt ist meistens der > Hersteller schon draußen. Das ist doch schon mal eine gute Vor-Auswahl. Nimm meinetwegen noch Mouser und RS dazu, aber wenn die alle den nicht führen, dann ist er draußen. > Wenn irgendwer es schafft Daten für diesen Hersteller zu finden kann er > die dann in die Datenbank eintragen Bitte nicht, bzw. nur, wenn die Filterfunktion so gut ist, dass ich diese Datensätze nicht sehe. Was nützen mir die schönsten Daten, wenn ich den Chip nicht kaufen kann? > ...außer natürlich der Hersteller will nicht das wir seine Chips > verwenden. Aber darauf können wir dann keien Rücksicht nehmen ;-) Sollten wir aber. Sonst kommt sowas dabei raus wie die FPU-Entdeckungsreise im Thread "Neue MCU APM32F103". Das ist bestimmt spannend, so wie Höhlenforschung oder so, dagegen hab' ich nichts. Aber es ist ein Widerspruch zu dieser Datenbank-Idee. Damit will man doch genau solche Sachen vermeiden.
Bauform B. schrieb: > Nimm meinetwegen noch > Mouser und RS dazu, aber wenn die alle den nicht führen, dann ist er > draußen. Die führen ja nicht einmal Nuvoton. Willst Du die halbe Welt außen vor lassen? Gerade die aktuelle politische Lage wird Halbleiter aus Asien befeuern. Ich finde, lcsc.com ist auch ein ernstzunehmender Distributor, nach der Logik sind dann alle Hersteller oben dabei.
Bauform B. schrieb: > Bitte nicht, bzw. nur, wenn die Filterfunktion so gut ist, dass ich > diese Datensätze nicht sehe. Was nützen mir die schönsten Daten, wenn > ich den Chip nicht kaufen kann? Dann brauchts eben nochn Feld "kaufbar bei". Bei LCSC gibts die padauk, bei den westiclehn Distris nunmal nicht. Das Große Problem ist dann eher: Wie hält man das aktuell?
Mw E. schrieb: > Das Große Problem ist dann eher: Wie hält man das aktuell? Die Frage stellt sich so nicht, weil der Zustand, dass die Datenbank aktuell ist garnicht erreicht wird. Wenn es etwas was man sich wünscht nicht gibt hat das i.d.R. auch seine Gründe. Mein Vorschlag ganz am Anfang, der TO soll selbst mal damit anfangen war nicht wirklich ernst gemeint, ich dachte es würde ihm schon ziemlich schnell klarwerden dass das nicht zu schaffen ist. Aber ich will niemand von gemeinnütziger Arbeit abhalten. Georg
Was passiert eigentlich theoretisch in der Datenbankabfrage, wenn ich einen uC mit min. 1kB Speicher, min. 4 IOs und min. 1x 8bit-Timer benötige? Das ergibt dann 178324 Treffer von 178348 insgesamt. Welches Fabrikat wird dann vorrangig ausgespuckt bzw. empfohlen?
Harald schrieb: > Gerade die aktuelle politische Lage wird Halbleiter aus Asien > befeuern. Das ist eben die Frage, man liest auch genau das Gegenteil... > Ich finde, lcsc.com ist auch ein ernstzunehmender Distributor, Kann sein, aber wenn kein westlicher Händler diese Hersteller im Programm hat, wird es einen Grund haben. Vielleicht sogar das: Lars P. schrieb: > außer natürlich der Hersteller will nicht das wir seine > Chips verwenden. Aber ich sag' schon nichts mehr. Das wird jetzt viel zu politisch.
Lars P. schrieb: > Meine Frage ist also gibt es eine Datenbank/WebSeite/Wiki/.. die > genauere Informationen zu möglichst vielen Mikrocontrollern hat? Octopart kommt dem vll noch am naehesten. Ist aber hauptsaechlich eine Datenbank (mit API) um Verfuegbarkeit und Preis bei den Distributoren zu finden.
Bauform B. schrieb: > Aber ich sag' schon nichts mehr. Wäre aber schade! Solange alle höflich und respektvoll miteinander reden macht es doch Spaß! Es ist ja gerade die Frage, ob man die Datenbank durch eine einseitig gesteuerte Politikstrategie einschränken will. Die westlichen Distributoren werden eben ganz gezielt durch Politik gesteuert. Wenn ich bei Mouser schon lese, das ich als Europäer ganz normale Halbleiter aufgrund US-amerikanischer Exportbeschränkungen nicht kaufen kann wird mir ehrlich gesagt schlecht und habe den Drang woanders zu kaufen.
Harald schrieb: > Wenn ich bei Mouser schon lese, das ich als Europäer ganz > normale Halbleiter aufgrund US-amerikanischer Exportbeschränkungen nicht > kaufen kann wird mir ehrlich gesagt schlecht und habe den Drang woanders > zu kaufen. Das wird ja noch geiler wenn man bedenkt, dass das bis vor kurzem auch bei einem STM32H750 der Fall war. Wir erinnern uns: ST ist ein europäischer Hersteller! Die F7 konnt man kaufen, bei den H7 gabs zicken. Hab ich mir eben ein STM32H750 Devboard vom Ali geklickt.
Ich glaube, mir würde schon eine Tabelle der Familien reichen, mit Hersteller, pincount (min und max) und Versorgung (min und max). Und dann ganz generell nur -, x oder n für I2C, SPI, Uart, LCD, otp, USB, Timer usw.. Wenn ich was konkretes machen will, und beim Distri bestellen will, dann kann ich besser da suchen.
Harald schrieb: > ganz > normale Halbleiter aufgrund US-amerikanischer Exportbeschränkungen nicht > kaufen Die Cocom-Listen aus dem kalten Krieg gibt es immer noch, und natürlich richten sie sich wesentlich nach amerikanischen Wünschen. Damals waren schon Prozessoren wie Z80 genehmigungspflichtig. Mitglied sind alle Nato-Staaten, wir auch, also ist im Prinzip alles was auf der Liste steht exportgenehmigungspflichtig, auch aus Deutschland usw. Grosse Bedeutung hat das heute nicht mehr, ich habe mich auch schon lange nicht mehr damit beschäftigt, aber die Beschränkungen gibt es immer noch (und wahrscheinlich für immer und ewig). Vorsichtig sollte man schon sein, ich habe z.B. in meiner Elektronik-Firma aus dem Iraq von Saddam Hussein Anfragen erhalten über schnelle Schaltelemente zur Zündung von Atombomben. Geantwortet habe ich vorsichtshalber nicht. Georg
Hat etwas gedauert, aber es gibt jetzt was neues. Wie hier empfohlen habe ich einfach mal angefangen die Datenbank aufzubauen. Das mit den über tausend STM32 war nicht so das Problem. Auf der ST Seite kann man den passenden Chip finden indem man nach ein paar Informationen filtert. Wenn man gar nicht filtert kann man eine Excel Tabelle mit allen Chips bekommen. So was ähnliches haben auch andere Hersteller. Die Excel Dateien kann man dann per Python Script in die Datenbank importieren. Auch um Informationen aus Datenblättern zu extrahieren gibt es Tools. Die PDFs kann man in einzelne Seiten zerteilen, zu Bildern konvertieren oder zu Text Dateien wandeln. Das alles geht auch automatisch aus einem Script. Mit der Darbietung der Information als Web Seite haben wir (ja ich habe Hilfe) gerade erst angefangen. Der absolute Anfang ist hier zu bewundern: https://chipselect.org/search In der Datenbank sind schon mehr Daten als was zur Zeit zu sehen ist. Da gibt es auch ein Wiki zum sammeln weiterer Informationen. Vor allem hier: https://wiki.chipselect.org/doku.php?id=firstdata sind noch einige Lücken was Daten von anderen Herstellern betrifft. Ich möchte mich hier bei allen die hier schon geholfen haben herzlich bedanken. Die Liste der Hersteller zum Beispiel kommt direkt aus diesem Thread. Leider fehlen zu vielen Herstellern noch die Web Seiten. Auch links zu weiteren "Product Selector" - Excel Datei quellen würde ich mich freuen. Wer helfen will, weitere Informations-Quellen kennt oder Anmerkungen hat was noch fehlt oder besser gemacht werden kann ist herzlich eingeladen sich bei mir zu melden oder sich gleich ins Wiki einzubringen. Je mehr Leute mit machen desto schneller können wir mehr Informationen bessere und einfacher zur Verfügung stellen. Vielen Dank auch für die positiven Nachrichten in diesem Thread ohne die wir wohl nie so weit gekommen wären.
Wie oben schon genannt, MCH stellt eine recht ausführliche XLS-Tab
bereit, rel. viele Spalten.
An diesen 'Spalten' könnte man sich viell. orientieren.
(zuerst mal die CPU-Architektur..)
>Auch um Informationen aus Datenblättern zu extrahieren gibt es Tools.
Man könnte viele (Hersteller)Abfragen automatisieren und in eine
Datenbank reinbringen.
(Das vom Distri kann auch mit Fehlern behaftet sein)
Was aber wohl ein Problem bzw grosser Aufwand wäre, die speziellen
Modes, Abhängigkeiten, Vergleichbarkeiten usw einzelner Perif-Module
zusammen zu fassen.
(Bsp zig verschiedene Modes für UART, SPI, Serial.., ADC usw)
Fast jede CPU-Familie hat hier Eigenheiten!, die man beim groben
Durchsehen des DB so direkt nicht feststellt.
Das dürfte also mit 'automatisch' ein Problem sein.
Da muss wohl ein Mensch drüber guggen.
Eine wichtige Spalte: Verfügbarkeit (in DE) (viell. ein
Schwierigkeitsgrad nennen oder so).
Es gibt China-Herst., die selbst heute noch 4-Bit-CPUs machen (die aber
für GP-Anwendungen wohl kein Mensch mehr braucht).
georg schrieb: > ich habe z.B. in meiner Elektronik-Firma aus dem Iraq > von Saddam Hussein Anfragen erhalten über schnelle Schaltelemente zur > Zündung von Atombomben. Geantwortet habe ich vorsichtshalber nicht. War das an dem Abend als du mit Elvis und Diana Poker gespielt hast? Oder warst du da grade mit Trump Golfen?
Lars P. schrieb: > Das Problem ist das wenn man (nur als Beispiel) 2 SPI und 3 I2Cs braucht Die Frage stellt sich mir in der Regel nicht, diese Busse können ja mehrere Slaves bedienen. Man kann aber auch leicht weitere SPI/I2C-Master in SW mit beliebigen Portpins erstellen. Oder wenn mir die ADC-Eingänge nicht reichen, pappe ich eben noch nen 4051 davor. In der Regel ist es am effektivsten, sich auf nur wenige MCs zu konzentrieren, je nach Anwendungsklasse. Denn das teuerste ist oft die Einarbeitungszeit und die Zeit für die Programmerstellung und für Test/Debugging. Und bei der Hardwareentwicklung sollte man auch drauf achten, nicht bei jedem Projekt alle Portpins neu durcheinander zu würfeln. Einmal getroffene Festlegungen sollte man projektübergreifend beibehalten.
@MCUA Wenn DU mit "MCH" Microchip meinst, dann ja diese Tabellen habe ich gefunden und die sind importiert. Auch CPU Architektur ist bereits drin. Beim Thema Web Interface fehlt uns einfach die Zeit, deswegen sieht es da noch so mau aus. Welche Datenquellen wir nutzen kann man hier sehen: https://wiki.chipselect.org/doku.php?id=firstdata Wir haben auch schon angefangen die Datenbank zu dokumentieren: Der aktuelle Stand ist das hier: https://wiki.chipselect.org/doku.php?id=doc:db_layout Das wird jetzt natürlich schritt für Schritt erweitert werden. Und einfach nur ein besserer µC selector zu sein als die Distries ist nur eine mögliche Anwendung solcher Informationen: https://wiki.chipselect.org/doku.php?id=organization Alle links gehen ins Wiki, da könnt Ihr gerne direkt euer Feedback einbringen.
@ Peter D. So kann man das natürlich machen. Aber wen zwei Chips die selbe I2C Slave Adresse haben, oder man zwei SPI Geräte gleichzeitig bearbeiten muss dann sind zwei Busse einfach ein muss, oder zumindest besser für die Performance. Das mit der Einarbeitung stimmt nur bis zu einer bestimmten Stückzahl. Je mehr Produkte du verkaufst desto entscheidender wird der Preis. Im Amateurbereich hast Du völlig recht. Bei einem Global Player sieht es manchmal anders aus. Aber auch gerade wenn man deine Strategie fährt und alles mit einem Prozessor zu beackern, dann ist ja entscheidend dafür den richtigen zu finden. Und @MCUA hat ja recht wenn er sagt das jeder Chips so seine Eigenarten hat und das deswegen der Vergleich so schwer ist. Der UART des einen Herstellers kann auch als SPI dienen, beim anderen nicht, dafür kann der aber vielleicht als LIN oder I2C benutzt werden. Wie schaffst Du es denn den einen oder die wenigen Chips zu finden die Du dann in deinen Projekten einsetzt? Gerade wenn man sich auf wenige Chips konzentriert muss man doch vorher sicher sein das sich die Einarbeitungszeit auch lohnt, oder?
>Bin ich der einzige der dieses Problem hat?
Ja. sicher. Den Guenstigsten ? Was soll das ? Das ist eine voellig
zufaellige Selektion, ausser es geht um 10 Millionen Stueck aufwaerts.
Ja, wir haben hier viele Leute, die ATTiny verwenden, weil die 2 Euro
guenstiger wie ein ATMega sein koennen. Und ? Diese 2 Euro reichen nicht
mal fuer eine Kaffee pause. Auch bei 100 Stueck haette ich noch nichts
gespart.
:
Bearbeitet durch User
Lars P. schrieb: > Das mit der Einarbeitung stimmt nur bis zu einer > bestimmten Stückzahl. ... die aber m.E. ziemlich hoch liegt. > Je mehr Produkte du verkaufst desto entscheidender > wird der Preis. Im Amateurbereich hast Du völlig > recht. Bei einem Global Player sieht es manchmal > anders aus. Und ein "Global Player" guckt in Deine Datenbank? Da wird eher der strategische Einkauf zu einem kostenlosen Seminar mit anschließendem Erholungs- urlaub eingeladen... > Wie schaffst Du es denn den einen oder die wenigen > Chips zu finden die Du dann in deinen Projekten > einsetzt? Gerade wenn man sich auf wenige Chips > konzentriert muss man doch vorher sicher sein das > sich die Einarbeitungszeit auch lohnt, oder? M.E. wäre eine herstellerübergreifende Datenbank durchaus nützlich -- aber weniger, um jedesmal den "optimalen" Chip zu finden, sondern um sich einen schnellen Überblick über die Familien zu verschaffen.
>Gerade wenn man sich auf wenige Chips konzentriert ...
Norm.weise "konzentriert"/"einigt" man sich eher auf eine bestimmte
Familie von (uC)Bausteinen, die dann möglichst oft benutzt wird (solange
es eben geht). Innerhalb solch Familie sind, neben der CPU, die
Perif.teile ja rel. ähnlich (man wird bsp.weise bei 100 Derivaten nicht
100 verschiedene UART- oder ADC-Arten vorfinden).
Für Vergleiche innerhalb einer Familie gibt es nat. entspr. Guides usw.
der Hersteller (der macht die, denn er will auch seine ICs verkaufen).
Lars P. schrieb: > Aber wen zwei Chips die > selbe I2C Slave Adresse haben, oder man zwei SPI Geräte gleichzeitig > bearbeiten muss dann sind zwei Busse einfach ein muss, oder zumindest > besser für die Performance. In der Regel macht eine CPU nicht hauptsächlich SPI/I2C, d.h. der Performancegewinn ist gering bis nicht merkbar. Adreßkonflikte sind bei I2C möglich, da ist ein 2. I2C eine einfache Lösung. Wenn die Slaves einen Adreßpin haben, kann man z.B. mit einem PCF8574 bis zu 8 Stück davon auswählen. Es gibt aber auch I2C-Multiplexer (TCA9548A). Lars P. schrieb: > Wie schaffst Du es denn den einen oder die wenigen Chips zu finden die > Du dann in deinen Projekten einsetzt? Das ist mehr oder weniger Zufall. Der eine mag Michrochip/Atmel, der andere NXP/Philips, wieder einer ST usw. Als wir z.B. 1997 mit CAN angefangen haben, sind wir beim Siemens C505 gelandet. https://www.infineon.com/dgdl/m505c.pdf?fileId=db3a304412b407950112b41a81b92abf Da Siemens aber meinte, beim OTP stehen bleiben zu können und die Flash-MCs aber sowas von verschlafen hat, setzen wir keine Infineon-MCs mehr ein.
https://www.cypress.com/file/45906/download Route any digital or analog peripheral to any GPIO 20 to 24 universal digital blocks (UDB), programmable to create any number of functions: • 8-, 16-, 24-, and 32-bit timers, counters, and PWMs • I2C, UART, SPI, I2S, LIN 2.0 interfaces • Cyclic redundancy check (CRC) • Pseudo random sequence (PRS) generators • Quadrature decoders • Gate-level logic functions Analog peripherals Configurable 8- to 20-bit delta-sigma ADC Up to two 12-bit SAR ADCs Four 8-bit DACs Four comparators Four opamps Four programmable analog blocks, to create: • Programmable gain amplifier (PGA) • Transimpedance amplifier (TIA) • Mixer • Sample and hold circuit CapSense® support, up to 62 sensors 1.024 V ±0.1% internal voltage reference
Pandur S. schrieb: > Ja, wir haben hier viele Leute, die ATTiny verwenden, weil die 2 Euro > guenstiger wie ein ATMega sein koennen. Und ? Diese 2 Euro reichen nicht > mal fuer eine Kaffee pause. Auch bei 100 Stueck haette ich noch nichts > gespart. Doch. 200 Euro. Gerade heutzutage, wo schon für die meisten Leute 20 Euro für ein Mikrocontrollerboard zu teuer sind, wird an den Teilen gespart. Es sind auch nicht alle Entwickler oder Hersteller in der glücklichen Situation, nur Kunden beliefern zu dürfen, bei denen Geld keine Rolle spielt. Gruß Joachim
Peter D. schrieb: > Lars P. schrieb: >> Wie schaffst Du es denn den einen oder die wenigen Chips zu finden die >> Du dann in deinen Projekten einsetzt? > > Das ist mehr oder weniger Zufall. Das dem Zufall zu überlassen ist mir halt nicht gut genug. Ein Blick in die Datenbank kann in Zukunft vielleicht auch Ihre Chancen verbessern den optimalen Chip zu finden. @Uwe Ja ich kenne die PSoCs. Komischer weise haben ST Microchip und die Anderen aber noch nicht das Geschäft komplett eingestellt, obwohl die doch auch die PSoCs kennen. ;-) PSoCs können eine Lösung sein, müssen aber nicht immer die beste Lösung sein. Wer nur einen Chip in all seinen Projekten einsetzen will, dem hilft so ein flexibler Chip bestimmt das zu schaffen. Wer stärkere Anforderungen hat für den ist der PSoC auch nur eine Lösung von vielen. Damit bleibt das Problem, den passenden Chip zu finden also gleich.
Lars P. schrieb: > Hat etwas gedauert, aber es gibt jetzt was neues. Schön, es gibt nichts Gutes, ausser man tut es. Aber: Damit diese Datenbank nützlich ist, muss sie mehr als RAM und ROM Grösse abdecken. Erster Schritt ist es, dabei auch Parameter aufzunehmen, die andere Prozessoren nicht haben. Also nicht bloss das kleinste Gemeinsame abzubilden. Die Datenbankstruktur darf also nicht vorgegeben sein, sondern sie muss alle Eigenschaften (Properties) enthalten die man zu einem uC nur finden kann. Sie muss intelligent sein, artifical intelligence. Denk an einen Fitter für ein FPGA. Der hat alle Formeln, weiss also was das FPGA realisieren muss, und versucht damit in Modell nach Modell diese Anforderungen reinzupressen, und liefert dann den kleinsten (billigsten) Chip der das kann. Du müsstest für das zu realisierende also eine Beschreibung erfinden, man könnte sich point and click vorstellen, also zusammenkopieren von angebotenen Eigenschaften, und dann wird mit dieser Beschreibung in der Datenbank gesucht in dem die Software für jeden uC das gewünschte umsezt und schaut, or er dafür ausreicht. Dabei geht es nicht nur um die Frage, ab 12 bit A/D oder 8k ROM, sondern auch um die Frage, ob SPI bei Nicht-Benutzung sich den Pins mit UART teilen kann, oder ob 2 Ausgänge die 50mA für einen TRIAC direkt schalten oder man dazu je 3 parallel schalten muss, oder um die Frage ob die Ansteuerung eines LCD alle 2ms den Stromverbrauch höher treibt weil ein LCD Controler fehlt und man das per Interrupt aus dem sleep heraus machen muss. Ab coolsten wäre naürlich eine Beschreibungssprache, in der gleich das Programm beschrieben wird, welches der uC ausführen soll, und dann wirklich ähnlich einem FPGA Fitter gleich für alle möglichen Plattformen kompiliert wird (man weiss dann also den Speicherbedarf exakt) und die I/O Anforderungen mit den auf der Plattform zur Verfügung stehenden Hardware-Reousrcen umgesetzt werden oder eben emuliert werden. Das wäre eine herstellerübegreifende HAL Schicht, nicht nur wie bei Arduino maximal ausgebremst, sondern maximal optimierbar. Aber keine Frage, der Aufwand ist kaum schaffbar, und das Ergebnis wäre viel wert und man wäre dumm es kostenlos anzubieten.
Ich bin da kein Freund, viel analoges Zeugs direkt in der CPU zu machen. Die steilen Schaltflanken rumpeln doch schon heftig dazwischen. Ich nehme lieber externe DACs und ADCs, das reduziert die Störungen enorm. Und man kann mit digital Isolatoren (ADuM) auch einfach GND-Schleifen auftrennen. Eine GND-Plane sieht nur auf den ersten Blick störfrei aus, sie ist es aber nicht. Statt einer großen Plane, nehme ich lieber separate GND-Inseln für digital und für analog.
Es ist schon ein Weilchen her. Ich hatte auch andere Dinge zu tun. Habe mich jetzt in letzter Zeit doch noch mal dran gesetzt. Das Ergebnis ist hier zus sehen: http://chipselect.ing-poetter.de/ Das kann noch nicht viel, ist aber mal ein Anfang. (Ihr hattet also Recht das es viel Arbeit ist) Es dürften bisher ungefähr etwas über 5000 Prozessoren der großen Hersteller sein. Bei vielen der kleinen Herstellern habe ich leider noch nicht die passenden Infos gefunden. Wer seinen lieblings- Chip vermisst kann mir gerne einen Link zu der passenden SVD Datei zukommen lassen, dann nehme ich den Chip mit auf. Ich würde mich über jedwedes Feedback freuen.
Lars P. schrieb: > Es ist schon ein Weilchen her. Ich hatte auch andere Dinge zu tun. Habe > mich jetzt in letzter Zeit doch noch mal dran gesetzt. Das Ergebnis ist > hier zus sehen: > > http://chipselect.ing-poetter.de/ > > Das kann noch nicht viel, ist aber mal ein Anfang. [...] Ich finde den Ansatz sinnvoll und nützlich, und Du hast da offensichtlich schon viel Arbeit investiert. Respekt! Ich frage mich allerdings zwei Dinge: erstens, wäre es nicht besser, auf User-Generated Content zu setzen, ähnlich wie Wikipedia? Wenn man eine gewisse Anzahl Benutzer gewinnen könnte, die zum Inhalt beitragen, dann ginge das Befüllen und Pflegen der Daten vermutlich wesentlich schneller. Meine zweite Frage betrifft das Backend. Im Moment sieht es so aus -- bitte korrigiere mich, wenn ich falsch liege -- als sei das eine klassische Relationale Datenbank, also so etwas wie PostgreSQL oder MySQL. Solche Systeme sind meiner persönlichen Erfahrung nach nicht besonders gut darin, komplexe Datenstrukturen und Volltexte zu durchsuchen. Insofern frage ich mich, ob eine Suchmaschine wie Elasticsearch oder Apache Solr nicht möglicherweise besser geeignet wäre, um diese Art von Daten abzubilden. Beide Systeme sind bei der Abfrage -- die ja viel öfter geschieht als ein Schreibvorgang auf die Daten -- wesentlich schneller als klassische Relationale Datenbanken, lassen auch unscharfe Suchen zu, und geben ihre Ergebnisse nach Treffergenauigkeiten (Score) sortiert zurück.
Sheeva P. schrieb: > Lars P. schrieb: >> http://chipselect.ing-poetter.de/ >> >> Das kann noch nicht viel, ist aber mal ein Anfang. [...] > > Ich finde den Ansatz sinnvoll und nützlich, und Du hast da > offensichtlich schon viel Arbeit investiert. Respekt! Vielen Dank! > Ich frage mich allerdings zwei Dinge: erstens, wäre es nicht besser, auf > User-Generated Content zu setzen, ähnlich wie Wikipedia? Wenn man eine > gewisse Anzahl Benutzer gewinnen könnte, die zum Inhalt beitragen, dann > ginge das Befüllen und Pflegen der Daten vermutlich wesentlich > schneller. Ich habe die Daten aus verschiedenen Quellen importiert: Excel Dateien von Hersteller Web Seiten, aber hauptsächlich aus SVD Dateien. Ich habe also nicht Stunden bzw. Tagelang Datenblätter abgetippt. Aber ja ich fände es sehr gut wenn sich Benutzer finden würden die auch bei der Erweiterung des Umfangs helfen wollen. Deswegen habe ich auf jeder Seite eine Email Adresse angegeben an die sich Menschen wenden können die zum Beispiel eine SVD Datei haben von einem Chip der noch nicht vorhanden ist. Ich würde auch gerne noch andere Informationen zu den bereits gelisteten Mikrocontrollern aufnehmen. Ich denke den meisten Nutzen hat eine Solche Datenbank wenn Sie möglichst vielen Menschen zur Verfügung steht. Und mit mehr Informationen können hoffentlich auch immer mehr Anwendungen für die Daten gefunden werden. Ein Web Interface zu bauen das all diese Benutzer Interaktionen erlaubt ist aber für mich eine Menge Arbeit und nicht wirklich meine Kern Kompetenz. Auch weiß ich nicht wirklich welche Informationen Benutzer gerne verändern wollen würden. Ich denke aber das man das noch einbauen kann wenn sich so viele Leute mit Informationen melden das die Emails nicht mehr sinnvoll abgearbeitet werden können. Dann wäre ja auch klar was an Informationen hereinkommt. Leider fehlt es zur Zeit noch an Benutzern. Wenn Sich aber jetzt schon jemand engagieren will ich freue mich über jedwede produktive Kooperation. > Meine zweite Frage betrifft das Backend. Im Moment sieht es so aus -- > bitte korrigiere mich, wenn ich falsch liege -- als sei das eine > klassische Relationale Datenbank, also so etwas wie PostgreSQL oder > MySQL. Solche Systeme sind meiner persönlichen Erfahrung nach nicht > besonders gut darin, „ und Volltexte zu > durchsuchen. Insofern frage ich mich, ob eine Suchmaschine wie > Elasticsearch oder Apache Solr nicht möglicherweise besser geeignet > wäre, um diese Art von Daten abzubilden. Beide Systeme sind bei der > Abfrage -- die ja viel öfter geschieht als ein Schreibvorgang auf die > Daten -- wesentlich schneller als klassische Relationale Datenbanken, > lassen auch unscharfe Suchen zu, und geben ihre Ergebnisse nach > Treffergenauigkeiten (Score) sortiert zurück. Erst mal ja da ist eine normale SQL Datenbank hinter. Ich hatte bisher noch nicht den Bedarf für „komplexe Datenstrukturen“ ganz im Gegenteil versuche ich es möglichst simpel zu halten. Die SVD Dateien die herunter geladen werden können sind auch einfacher gehalten als die typischen SVD Dateien die die Hersteller zur Verfügung stellen. Auch „Volltext suche“ habe ich bisher nicht benötigt. Daher hat das bisher für mich gut funktioniert. Auch muss ich zugeben das ich keine Erfahrungen mit „Elasticsearch oder Apache Solr“ habe. Ich habe halt verwendet was ich kenne und womit ich zumindest halbwegs klar komme. Bestimmt gibt es noch sehr viel zu verbessern und jeder der helfen will ist herzlich willkommen. Ich kann auch gerne die ganze Webseite, die Daten der Datenbank und alle Import-Skripte frei geben. Wer Interesse an den Daten hat kann sich gerne bei mir melden.
Lars P. schrieb: > Sheeva P. schrieb: >> Lars P. schrieb: >>> http://chipselect.ing-poetter.de/ >>> >>> Das kann noch nicht viel, ist aber mal ein Anfang. [...] >> >> Ich finde den Ansatz sinnvoll und nützlich, und Du hast da >> offensichtlich schon viel Arbeit investiert. Respekt! > > Vielen Dank! Da nicht für, ist doch wahr! ;-) > Ich habe die Daten aus verschiedenen Quellen importiert: Excel Dateien > von Hersteller Web Seiten, aber hauptsächlich aus SVD Dateien. Ich habe > also nicht Stunden bzw. Tagelang Datenblätter abgetippt. Aber ja ich > fände es sehr gut wenn sich Benutzer finden würden die auch bei der > Erweiterung des Umfangs helfen wollen. Ja, ich will... lol > Wenn Sich aber jetzt schon jemand engagieren will ich freue mich über > jedwede produktive Kooperation. Du hast eine E-Mail. > Ich hatte bisher noch nicht den Bedarf für „komplexe Datenstrukturen“ > ganz im Gegenteil versuche ich es möglichst simpel zu halten. Die SVD > Dateien die herunter geladen werden können sind auch einfacher gehalten > als die typischen SVD Dateien die die Hersteller zur Verfügung stellen. > Auch „Volltext suche“ habe ich bisher nicht benötigt. Daher hat das > bisher für mich gut funktioniert. Auch muss ich zugeben das ich keine > Erfahrungen mit „Elasticsearch oder Apache Solr“ habe. Ich habe halt > verwendet was ich kenne und womit ich zumindest halbwegs klar komme. Alles gut, ich finde es schon großartig, daß Du Dir die Mühe überhaupt gemacht und so etwas entwickelt hast! Wie gesagt: Hut ab! ;-) Es wäre natürlich toll, wenn ein Benutzer so etwas eingeben könnte wie "bit:8 uart:>2 pwm:>4" und dann alle 8-Bit-MCs mit mehr als zwei UARTs und mehr als 4 PWMs ausgegeben würden, im Idealfall in einer sortierbaren Tabelle. Und ja, ob unser Benutzer "uart" oder "usart" eingäbe, würde so ein Esearch mit Synonymen sehr einfach lösen können. Ein Beispiel für so eine Tabelle findest Du hier: [1]. Bitte beachte, daß diese Datei wegen Sicherheitsbeschränkungen aktueller Browser zuerst heruntergeladen und lokal aufgerufen werden muß. Außerdem habe ich seinerzeit wenig bis keinen Aufwand betrieben, um das Ganze wirklich hübsch zu machen... ;-) Ach so: diese Query Syntax "bit:8 uart:>2 pwm:>4" gefällt mir auch noch nicht richtig. Aber wenn es erstmal eine Basis gäbe, ließe sich anhand der Queries natürlich schauen, wonach die Benutzer wirklich suchen, und dann lassen sich auch benutzerfreundlichere Formulare für die meistgenutzten Suchen einbinden. [1] https://www.mikrocontroller.net/attachment/477682/dt_502813.html
Klasse. Jetzt noch Sortier- und Filtermöglichkeit einbauen.
Ohne user generated content ist sowas immer eine Totgeburt. Es wird in Zukunft nicht aktuell gehalten werden und damit innerhalb kürzester Zeit wertlos. Wenn dann müsste man heute automatisiert, über die APIs der Hersteller und/oder der großen Distris solche Infos zusammenfahren.
@Armin: sheevaplug arbeitet gerade daran. @Cyblord: User content und automatisches importieren steht auch auf der TODO Liste. Jeder der will kann gerne mithelfen damit es schneller geht,...
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.