Das erste Board mit Quark ist ein Arduino-Kompatibles Dev-Board.
Engadget: Intel launches Galileo, an Arduino-compatible development board
Quasi ein 400 Mhz Pentium.
Engadget: Intel launches Galileo, an Arduino-compatible development board
Quasi ein 400 Mhz Pentium.
warum fahren denn aktuell alle so auf diesen Arduino Käse ab?
Die quälen einen 8-bitter mit C++, haben eine unbrauchbare IDE und keinen Plan von Programmierung (Künstler und so
) und jetzt soll dass mit einem x86 erschlagen werden?
Ich finde ja die Idee einer modularen Plattform nicht schlecht und die Libraries/Treiber sind auch nicht verkehrt, aber da sollten sie doch wenigstens welche hin setzten, die Ahnung von Programmieren haben (nutzen zB. ein word um 1 bit zu speichern, auf einem 8 Bitter) und das ganze dann noch etwas Konsistenter durch dacht würde auch nicht schaden.
Zum Quark, glaube kaum, dass der sich gegen ARM und andere Mikrocontroller durch setzten kann (außer Intel sponsort ihn
). Die Konkurenz ist zu stark und die Stärken von x86 sehe ich nicht in I/O Ausgaben, eher in Computing mit den Ganzen Erweiterungen wie SSE (wobei ARM wohl ähnliche Erweiterungen haben dürfte) und hier stellt sich die Frage, was Quark davon abbekommen hat und wie schwer es ist, darauf zuzugreifen.
Die quälen einen 8-bitter mit C++, haben eine unbrauchbare IDE und keinen Plan von Programmierung (Künstler und so
) und jetzt soll dass mit einem x86 erschlagen werden?Ich finde ja die Idee einer modularen Plattform nicht schlecht und die Libraries/Treiber sind auch nicht verkehrt, aber da sollten sie doch wenigstens welche hin setzten, die Ahnung von Programmieren haben (nutzen zB. ein word um 1 bit zu speichern, auf einem 8 Bitter) und das ganze dann noch etwas Konsistenter durch dacht würde auch nicht schaden.
Zum Quark, glaube kaum, dass der sich gegen ARM und andere Mikrocontroller durch setzten kann (außer Intel sponsort ihn
). Die Konkurenz ist zu stark und die Stärken von x86 sehe ich nicht in I/O Ausgaben, eher in Computing mit den Ganzen Erweiterungen wie SSE (wobei ARM wohl ähnliche Erweiterungen haben dürfte) und hier stellt sich die Frage, was Quark davon abbekommen hat und wie schwer es ist, darauf zuzugreifen.
Markus Everson
Grand Admiral Special
Die Sorte kenn ich gar nicht. Gibts die bei Toom?
Und das "die" keinen Plan von Programmierung haben glaubst Du zu wissen weil....?
Hab doch zwei Beispiele genannt, zum einen nutzen sie C++ auf einem kleinen 8 bit Mikrocontroller. Das ist eine Ressourcenverschwendung und bringt eigentlich keine Vorteile.
Und zum anderen, dass sie zum speichern eines bools in ihrer Standard Library eben auf einen 16-bit Int setzten und das auf einem 8 bitter. Denn das braucht mind. doppelt mal so lange wie ein 8bit bool zum abarbeiten.
Gibt noch ein paar mehr, bin aber gerade zu faul zum suchen
Und zum anderen, dass sie zum speichern eines bools in ihrer Standard Library eben auf einen 16-bit Int setzten und das auf einem 8 bitter. Denn das braucht mind. doppelt mal so lange wie ein 8bit bool zum abarbeiten.
Gibt noch ein paar mehr, bin aber gerade zu faul zum suchen
Nuja, der Vorteil von C++ ist hier derselbe wie bei x86 auch. Es ist eben "einfacher" zu programmieren als Assembler. Und C ist auch bei Mikrocontrollern nicht gerade unüblich. Damit lässt sich ebenfalls schon recht effizient programmieren. Die meisten Leute dürften mittlerweile auch schon für 16 Bit Controller programmieren. Arduino ist ja eher eine kleine Bastlerplattform, auf der keine besonders rechenintensiven Sachen laufen sollen. Also eher Abfragen von Zählerdaten, ansteuern von LEDs oder kleine Steuerungen/Regelungen. Gegebenenfalls hängt man das dann eben noch mit dem Ethernetshield an den heimischen Router, damit man es Online abfragen kann.
Warum man aber für einen BOOL überhaupt einen Int Datentyp nehmen sollte ist mir irgendwie schleierhaft.
Warum man aber für einen BOOL überhaupt einen Int Datentyp nehmen sollte ist mir irgendwie schleierhaft.
Wenn man gescheit C++ verwendet hat das keine Auswirkungen auf die Ressourcen und hat den riesen Vorteil den Code strukturierter und sicherer zu gestalten. Wenn man natürlich dicke Libraries ohne Sinn und Verstand benutzt, dann setzt die Ressourcenverschwendung ein. Das Problem hast du bei C allerdings auch.
Optimierung ist dann noch ein weiteres Problem. Hab aber auch schon oft die Erkenntnis gehabt, dass es keinen Sinn macht sich mit bitfriemelei aufzuhalten und statt dessen einen int verwendet. das Maskieren der Bits bremst und wenn genug Speicher vorhanden ist macht es nichts anstelle von 100 Bits eben 400 Bytes zu benötigen.
Warum die Leuts so auf den Arduino Käse abfahren? Weiß ich auch nicht, da ich nicht darauf abfahre. Vorteile sind sicherlich der günstige Preis und die frei verfügbare Entwicklersoftware. Beim PC braucht es erst teure Zusatzboards um überhaupt was anzusteuern und eine SPS läßt sich Siemens gut bezahlen.
Zuletzt bearbeitet:
Markus Everson
Grand Admiral Special
Ach so. Und die von Dir genehmigte Programmiersprache wäre dann...?
Und das es eine Ressourcenverschwendung ist weißt Du weil....?
Und das es keine Vorteile bringt weißt Du weil...?
Bist Du ein Gott? Oder woher dieser Ansatz für andere entscheiden zu wollen wie sie ihre Ressourcen am effektivsten einzusetzen haben und was sie als Vorteilhaft zu erachten haben?
Dir ist aber schon klar das man jederzeit auf Assembler - auch gemixt mit einem C/C++ Grundgerüst, ausweichen kann falls das zum Problem wird?
Die Frage ist, was Intel nun mit Quark will (also das nicht, sondern, wie sie in dem Marktbereich damit Fuß fassen wollen). Schaut man sich mal im nicht-x86-bereich um, dann gibt es da auch ARDUINO-kompatible Boards lange nicht nur mit Atmel-Winz-CPUs, sondern auch mit größeren ARM-Kernen.
z.B. gibt´s ein OlinuXino mit Allwinner A10 für 53 €. Das ist jetzt nur ein 1Ghz Cortex A8, es gibt aber auch schon Versionen mit Dual Cortex A7.
Dabei sei bemerkt, dass da auf dem ARM-SoC noch eine (FullHD-fähige)-GPU inklusive HDMI mit dabei ist.
Also wozu brauche ich da Intel und wo haben sie ihren Platz? Die bringen so ein 486-fürzlein ohne GPU in einen Bereich in dem mit den SoCs Cent-beträge verdient werden, weil die Anforderungen gering sind....
Wer wenig will nimmt einen einfachen Controller, wer mehr will bekommt ein volles ARM-SoC für weniger als das, was Intel für seinen Galileo-Quark verlangt.
z.B. gibt´s ein OlinuXino mit Allwinner A10 für 53 €. Das ist jetzt nur ein 1Ghz Cortex A8, es gibt aber auch schon Versionen mit Dual Cortex A7.
Dabei sei bemerkt, dass da auf dem ARM-SoC noch eine (FullHD-fähige)-GPU inklusive HDMI mit dabei ist.
Also wozu brauche ich da Intel und wo haben sie ihren Platz? Die bringen so ein 486-fürzlein ohne GPU in einen Bereich in dem mit den SoCs Cent-beträge verdient werden, weil die Anforderungen gering sind....
Wer wenig will nimmt einen einfachen Controller, wer mehr will bekommt ein volles ARM-SoC für weniger als das, was Intel für seinen Galileo-Quark verlangt.
Vorhandene Software könnte ein Argument sein, ansonsten muss man mal sehen wie aggressiv Intel die Preispolitik betreibt. Die Systeme der Frankfurter Verkehrsgesellschaft hab ich dank diverser Abstürze schon mit x86 und Uralt-Windoof gesehen, was in den neuen mit Touchscreen drin ist weiß ich nicht aber solche Kunden könnte ich mir vorstellen.
?@ndrs
Und mit vorhandene x86-Software ist auch nicht Crisis, Battlefield oder sonstige Games gemeint, sondern wohl eher die seit Jahren auf einem altem embedded X-86 eingesetzte Software und moderne Entwicklungsumgebungen. Und da gibt es für x86 eben alles.
Der beste Mikrocontroller nützt dir nichts, wenn du keine gescheite Entwicklungsumgebung hast.
Und mit vorhandene x86-Software ist auch nicht Crisis, Battlefield oder sonstige Games gemeint, sondern wohl eher die seit Jahren auf einem altem embedded X-86 eingesetzte Software und moderne Entwicklungsumgebungen. Und da gibt es für x86 eben alles.
Der beste Mikrocontroller nützt dir nichts, wenn du keine gescheite Entwicklungsumgebung hast.
Eben. Und ich kenne keine x86-embedded-Maschinen, die ohne GUI laufen. Meist laufen nur die Bedienterminals mit Windows. Die eigentlichen Systeme dann auf dedizierter Hardware, wie SPS oder so.
Also mir will echt nicht ein einziges Beispiel einfallen, wo ich sowas mal gesehn hab.
Also mir will echt nicht ein einziges Beispiel einfallen, wo ich sowas mal gesehn hab.
Bis vor ein paar Jahren liefen doch die meisten embedded Systeme mit ein paar LEDs oder einem, wenn es komfortabel war, mehrzeiligem Alphanumerischem Display als Anzeige. Da braucht es wirklich keine GPU. Zudem dürften noch genug Geräte mit Geode NX oder alten Celerons, Pentiums ohne GPU unterwegs sein.
Woerns
Grand Admiral Special
- Mitglied seit
- 05.02.2003
- Beiträge
- 2.994
- Renomée
- 233
Ich entwickele gelegentlich Software für XP embedded Systeme. Die Geräte sind i.d.R. äußerst schlank ausgestattet, LAN nur 10MBit/s, immer irgendein GUI, gelegentlich eine Touch Oberfläche, oft nur rudimentäres Keypad mit reduzierter, bzw. spezialisierter Tastatur für den jeweiligen Anwendungszweck, Prozessor i.d.R. kein X86.
MfG
MfG
Vllt. Interessiert es ja jemanden: http://www.golem.de/news/test-intels-galileo-board-1312-103167.html
Sieht so aus, als ob der Quark noch etwas reifen muss:
MobileGeeks: "Intel Edison: Plattform für Smartwatches & Co kommt zuerst als Atom “Bay Trail”-Variante"
Man will also ein System mit 2 Silvermont-Kernen nutzen, die auf 500 Mhz heruntergetaktet werden und so vorab als Entwicklungsplattform dienen sollen....Offensichtlich ist sich Intel gerade bewusst geworden, dass man (mal wieder) in einen Markt einsteigt, der schon fest von ARM besetzt ist und will daher Schadensbegrenzung betreiben. Wahrscheinlich wird man Edison dann bald verschenken, damit ein paar Hersteller Systeme damit bauen.
MobileGeeks: "Intel Edison: Plattform für Smartwatches & Co kommt zuerst als Atom “Bay Trail”-Variante"
Man will also ein System mit 2 Silvermont-Kernen nutzen, die auf 500 Mhz heruntergetaktet werden und so vorab als Entwicklungsplattform dienen sollen....Offensichtlich ist sich Intel gerade bewusst geworden, dass man (mal wieder) in einen Markt einsteigt, der schon fest von ARM besetzt ist und will daher Schadensbegrenzung betreiben. Wahrscheinlich wird man Edison dann bald verschenken, damit ein paar Hersteller Systeme damit bauen.
Oder man macht nen fonds dafür. Sofern das kein Aprilscherz ist, legt intel nen 100 mio. Fonds für Smart DeVices auf.
"Fonds", ne interessante Umschreibung dafür, daß man die Dinger verschenkt. Wenn Intel nicht so abartig viel Finanzkraft hätte, würde Analysten bei sowas nervös werden. Und ob das erfolgreich ist, ist ja auch nicht gesagt, denn ARM wird ja genommen, weil es Vorteile hat, die sind wahrscheinlich mehr wert als Intel zahlen kann; und die müßten ja dauerhaft draufzahlen, weil ihre künstlich aufgeweitete Marktnische sonst sofort zusammenbricht, wenn sie aufhören mit der Subventionierung. Die Vorgehensweise von AMD, den ARM-Markt mit einem eigenen ARM-Prozessor anzuzapfen, scheint mir da irgendwie ökonomisch sinnvoller zu sein.
Intel kann da quasi kein Geld verdienen. Es gibt kaum ansprüche an die Smart devices und "die ARM-Partner decken unglaublich viel ab, vom einfachen Low-Power-SoC bis zum SoC mit "dicker" GPU und ordentlich Rechenleistung. Da gibt´s für jeden Anwendungszweck das entsprechende Design und wo x86 keine Trumpfkarte ist, wird´s schwer. Auch Microsofts Ankündigung, Windows jetzt auch für diese Smart-Devices zur Verfügung zu stellen dürfte Intel kaum helfen, weil Microsoft nicht allein auf x86 setzen kann, wenn man sich nicht von Anfang an den Markt verbauen will. Offensichtlich ist allerdings das Galileo-Board als Entwicklerplattform vorgesehen, hier scheint also die alte Wintel-Allianz noch einmal zu greifen.
Intel kann nicht so diversifizieren, wie die zahllosen Hersteller mit MIPS und ARM-Designs. Dazu müssen die Dinger billig sein, d.h. die Margen sind "nicht Intel-würdig". Man muss also sehen, dass man mit der Brechstange einen kritischen Marktanteil erobert, um überhaupt für Entwickler interessant zu sein.
Das mit Quark ist meiner Meinung nach wirklich ein unglaublich schwieriges Feld für Intel, weil das ein Markt ist, der praktisch schon komplett ARMiert ist. Und das Geschäftsmodell von ARM ist da schlicht perfekt.
Im Prinzip kann Intel ab einem gewissen Zeitpunkt nur noch eigene Geräte rausbringen oder eben gebrandete Referenz-Designs anbieten. Für diesen Zweck haben sie ja jetzt Basis Science gekauft.
Intel kann nicht so diversifizieren, wie die zahllosen Hersteller mit MIPS und ARM-Designs. Dazu müssen die Dinger billig sein, d.h. die Margen sind "nicht Intel-würdig". Man muss also sehen, dass man mit der Brechstange einen kritischen Marktanteil erobert, um überhaupt für Entwickler interessant zu sein.
Das mit Quark ist meiner Meinung nach wirklich ein unglaublich schwieriges Feld für Intel, weil das ein Markt ist, der praktisch schon komplett ARMiert ist. Und das Geschäftsmodell von ARM ist da schlicht perfekt.
Im Prinzip kann Intel ab einem gewissen Zeitpunkt nur noch eigene Geräte rausbringen oder eben gebrandete Referenz-Designs anbieten. Für diesen Zweck haben sie ja jetzt Basis Science gekauft.
Zuletzt bearbeitet:
Woerns
Grand Admiral Special
- Mitglied seit
- 05.02.2003
- Beiträge
- 2.994
- Renomée
- 233
Es ist ein bisschen OT, aber trotzdem kann ich mir den Kommentar nicht ersparen.
AMD hatte einst die Devise "X86 everywhere" ausgerufen. Eigentlich ist das Intels Glaubenssatz, spätestens nachdem Intel Xscale abgestoßen hat. Dahinter stand für beide X86-Hersteller die Aussage, dass man mit dem breiten Angebot an vorhandener X86 Software eigentlich gar nichts anderes mehr machen könne als X86 überall anzubieten...
Derzeit erleben wir, dass der einst treue Kompanion der "WinTel"-Allianz Microsoft sein Office auf iOS portiert. die Software ist anscheinend doch viel weicher und biegsamer als die Hardwarebasis, auf der sie einst entwickelt wurde. Ich sehe das Dogma "X86 everywhere" als gescheitert an.
Aber wenn "X86 everywhere" schon nicht für Smartphones und Tablets greift, wie steht es dann um Armbanduhren und andere Kleinstartikel des "Internet of things"? Bringt uns da eine Softwarebasis Vorteile, die einst unter X86 kompiliert wurde? Microsoft Access auf der Armbanduhr? Corel Draw auf dem Hosenknopf?
Spaß beiseite, ich halte von dem "Internet of things" ohnehin nichts, aber eines glaube ich gewiss: wenn die "Dinge" eine gewisse Intelligenz erhalten, dann sicher nicht aufgrund einer X86 Vergangenheit. Die Zukunft kommt vielleicht ARM-lastig daher, aber vielleicht wird sie auch dieses Mal wieder neu erfunden.
MfG
AMD hatte einst die Devise "X86 everywhere" ausgerufen. Eigentlich ist das Intels Glaubenssatz, spätestens nachdem Intel Xscale abgestoßen hat. Dahinter stand für beide X86-Hersteller die Aussage, dass man mit dem breiten Angebot an vorhandener X86 Software eigentlich gar nichts anderes mehr machen könne als X86 überall anzubieten...
Derzeit erleben wir, dass der einst treue Kompanion der "WinTel"-Allianz Microsoft sein Office auf iOS portiert. die Software ist anscheinend doch viel weicher und biegsamer als die Hardwarebasis, auf der sie einst entwickelt wurde. Ich sehe das Dogma "X86 everywhere" als gescheitert an.
Aber wenn "X86 everywhere" schon nicht für Smartphones und Tablets greift, wie steht es dann um Armbanduhren und andere Kleinstartikel des "Internet of things"? Bringt uns da eine Softwarebasis Vorteile, die einst unter X86 kompiliert wurde? Microsoft Access auf der Armbanduhr? Corel Draw auf dem Hosenknopf?
Spaß beiseite, ich halte von dem "Internet of things" ohnehin nichts, aber eines glaube ich gewiss: wenn die "Dinge" eine gewisse Intelligenz erhalten, dann sicher nicht aufgrund einer X86 Vergangenheit. Die Zukunft kommt vielleicht ARM-lastig daher, aber vielleicht wird sie auch dieses Mal wieder neu erfunden.
MfG
Ähnliche Themen
