Einsteig in Microcontroller und Programmierung

Es hängt u.a. davon ab über welche Zeiträume man Software am Laufen halten muß/will. Hier hat mein Kunde gerade von Kollegen der das 2002 entwickelte hatte die frohe Kunde erhalten "Leider ist der IAR-Freeware Assembler hier nichtmehr vorhanden ..." mit kleiner, schneller, billiger Softwareänderung für das Board is also nix mehr.

Bei dem Laden bei dem ich 1986 mal angefangen habe standen verstaubt 2-3 CP/M-Rechner rum: wurden nicht für Neuentwicklung benötigt. Aber Geschäftsleitung hatte Hoffnung daß da noch Aufträge kommen. Dann wurden die Kisten irgendwann mal in den Keller abgeschoben. Dann kam tatsächlich nochmal Winzigauftrag: alles wieder raufgeholt. Leider festgestellt daß die Lagerung der Hardware nicht gutgetan hatte: es hagelte Lesefehler von der Floppy ( Harddisk hatten die nicht ).

Die Probleme hat man offensichtlich nicht wenn der Compiler im Zielsystem sitzt und auf PC-Seite nur Standardsoftware wie Terminalprogramm benötigt wird.

MfG JRD

Rafael Deliano schrieb:

Ich kenne Forth nicht, aber das erinnert mich an

#define LED_ON PORTC|=(1

Ich bin bei #define DEBUG(x) resp. #define DEBUG(x) x

Und dann DEBUG({ printf ("Jetzt sind wir hier..."); })

So kann man auch die kniffligsten Sachen auf Systemebene debuggen. Wenn es um Typkonversionen, Zeiger u.a. geht, schreibt man sich ein main() und debuggt komfortabel auf dem PC.

ICE oder ein Jtag-debugger sind natürlich komfortabler, aber dieser Thread wurde ja einst mit der Prämisse "Einstieg" gestartet.

Falk

Lutz Schulze schrieb:

Eher eine Stunde.

Jetzt haben wir die Grenzen einvernehmlich definiert und müssen uns nur noch über den überaus seltenen Fall 100..10.000 den Kopf zerbrechen ;-)

Falk

Würde bei beiden darauf tippen daß die Entwicklungs- aufträge das Geld einspielen und dem Kunden egal ist womit programmiert wird.

Es ist schlicht so daß es für embedded Controller sehr wenig Alternativen gibt:

• C ist mainstream und von Anbietern forciert.
• C++ als "das bessere C" hat technische Probleme und ist für embedded Controller zu langsam aus den Startlöchern gekommen. Es wäre/ist wohl der bevorzugte Alternative der C-Anbieter. Hat aber bei vielen Anwendern wenig Sympathien.
• ADA hatte ursprünglich Intresse der Anwender aber inzwischen seine besten Zeiten hinter sich. * "no-subsets" verhinderte daß Varianten für kleine 16 Bit Controller ( z.B. ohne float ) verfügbar wurden. * hohe Kosten für Compilerentwicklung wurden ursprünglich auf eine geringe Zahl sehr zahlungskräftiger Kunden umgelegt. Das beschränkte die Verbreitung: wenig Anwender, wenig Programmierer die das können. Also bastelt man heute in USA auch im aerospace-Bereich wieder mit C++ weils da genügend Programmierer im hire&fire-Markt gibt.
• FORTH ist das was kaum Anbieter aber eine lautstarke und recht umfangreiche Benutzergruppe hat. Zudem ist der Compiler relativ einfach implementierbar. Läuft auch gut auf kleinen Controllern.
• BASIC : da schleicht immer noch die Fiktion rum daß Maschinenbauer, Verfahrenstechniker usw. den "leicht bedienbaren Interpreter" wollen. Da schliest sich das Zeitfenster aber: die Leute die in den 80ern nicht auf Homecomputern mit BASIC in Berührung gekommen sind werden es heute nichtmehr anfassen. Zudem ist es auch nicht wirklich trivial ein gutes, für echte Anwendungen brauchbares BASIC zu implementieren.
• "the-last-big-thing": wer will kann dem Pearl-Verein beitreten, gibts immer noch. Versionen aber wohl nur für 68xxx & Derivate. Haben damals auch versäumt sich Richtung auf kleine Controller zu öffnen.
• "the-next-big-thing": wenn "besser" bedeutet "umfangreicherer Compiler" scheitert es schlicht genau daran. Embedded Controller sind ein unerfreulicher Spielplatz für Informatiker. * der Anwender will was was auch auf relativ kleinen Controllern läuft. Wenn in einem Automobil 100 Controller sind dann sind das nicht alles ARM7. * anders als bei PCs gibt es mehr als eine Sorte CPU: der Aufwand da wirklich Code dafür zu generieren ist immens. Die fade Zwischenlösung: wir erzeugen C-Code, ein C-Compiler macht den Rest überzeugt niemand.

MfG JRD

Rafael Deliano schrieb:

Doch, mich. Ich betrachte den C-Compiler nicht als Werkzeug, das mir das Denken abnimmt, sondern als Werkzeug, das mir das elende Herumhampeln mit Opcodes, Stack, Funktionsparametern und Datentypen, also die "Sklavenarbeit" erspart. Mehr nicht. Wenn ich denkfaul bin, nehme ich perl.

Ich habe gar nichts gegen Forth. Ich habe auch nichts dagegen, daß der Klempner seine Rohre crimpt, nur weil ich meine Strippen weichlöte.

Falk P.S.: Basic 6502-Assembler Z80-Assembler Pascal 68000-Assembler C perl PIC-Assembler php AVR-Assembler C

Nicht wirklich, dort ist lediglich der parallele SCSI-Bus ausgestorben. ATAPI CD/DVD-Brenner, FW-Festplatten und USB-Sticks verwenden heute SCSI-Befehle ... SATA ist heute eigentlich das letzte was intern noch nicht SCSI ist.

Das SCSI-Geraetemodell hat Maszstaebe gesetzt. Es waere nicht heute - ueber 20 Jahre spaeter - immer noch aktuell wenn es nichts taugen wuerde. Und in den 90er Jahren war auch der parallele Bus noch auf der Hoehe der Zeit. Was hat euch daran nicht gefallen?

Micha

Am Thu, 09 Apr 2009 09:21:33 +0200 schrieb Falk Willberg:

Die hätte ich wahrscheinlich länger schlafen sollen ;-)

Lutz

Nein. Er muß das abliefern können, was sein Auftraggeber verlangt. Und das ist (zum Glück) in den seltensten Fällen das, was du "Industriestandard" nennst.

Ich weiß das ziemlich genau, denn viele meiner Kollegen sind solche "Jungs von hinterm Ural". Die compilieren ihren Code mit gcc auf Linux-Maschinen. Das Endprodukt wird nachher durch eine Menge Compiler gedreht. Inclusive denen von Microsoft.

Ja, Jörg. Das mag in deiner kleinen, bedauernswerten Welt so sein. Aber nochmal: hinter deinem Horizont gehts weiter. Ich kenne sonst niemanden, der Word97 für irgendwie toll halten würde.

Das belegt höchstens den geringen Radius deines Horizonts. Sonst gar nichts.

Alle Märkte fangen mal klein an. Und der Linux-Markt ist für etliche Hardware-Hersteller mittlerweile offensichtlich groß genug, daß sie ihn nicht länger ignorieren. Die 0.8% die du hier mal genannt hast, sind nur eine Marketinglüge von Microsoft.

Hängt sicher auch von der Branche ab. Aber wenn du mal ein Stück südlich in die Bay Area schaust - bei den meisten Unternehmen da dürfte der Microsoft-Anteil auf dem Desktop deutlich unter 50% liegen. Ich sage mal ebay, Google, Amazon, Sun.

Weil das im wesentlichen der gleiche Kernel ist? Und auch alles x86? Abgesehen davon glaube ich nicht, daß alle deine Hardware an NT4 läuft. Es sei denn, sie ist genauso alt wie NT4.

Und da haben wir wieder dein Horizontproblem. Bloß weil *dein* Klimbim aller unter Windoze spielt, *kann* Windoze kein Treiberproblem haben.

XL

-- Der geistige Horizont vieler Menschen ist ein Kreis mit Radius Null. Den nennen sie dann ihren Standpunkt.

Dass Server als bloße Datei-Archive dienen und Programme am Arbeitsplatzrechner laufen, ist das Arbeitsmodell von Microsoft. Im Rest der IT-Welt ist es eher umgekehrt. Die Anwendungen laufen auf dem Server und der Rechner am Arbeitsplatz stellt im wesentlichen nur die Schnittstelle zum Menschen.

Das behaupten die Salesdroiden voon Microsoft seit 20 Jahren. Die Wirklichkeit zeigt sich in den Umsätzen von Oracle (22 Mrd USD) und SAP (11 Mrd EUR).

Vielleicht weil die interessanten IT-Jobs eher an Physiker/Mathematiker gehen? ;-)

------

Hallo!

"Nikolaus Riehm" wrote

Ich persönlich finde die AVRs gut. Es gibt viel dazu im Netz zu finden. Vor allem kleine Programmfetzen in C für alles mögliche.

Aber im Prinzip kannst du jeden µController nehmen. Zum Thema Erweiter- barkeit vielleicht folgendes. Die Controller haben oft schon 8 oder

-AD-Wandler entweder schon eingebaut oder eben als extra Baustein

-Steuerspannungen erzeugen geht mit PWM oder besser digitalen Potis wie z.B. AD5206 und wie sie nicht alle heissen. Einfach einen Wert per SPI reinschieben und n/256tel von 1/10/100kOhm raus.

-Sensoren gibt es auch wie Sand am Meer und können von jedem µC angesprochen werden

-Taster/Matrix einfach über die Ports realisieren und wenn die nicht reichen kann man sie erweitern mit z.B. PCF8574 per I2C

alsdenn, Jens

Rafael Deliano schrieb:

Kein Widerspruch. Dann zurück zum PIC vs. AVR Religionskrieg ;-)

Falk

Joerg schrieb:

Völlig konträr zu meinen Erfahrungen. Z.B. hier in der Firma schreibt man Java-Anwendungen zum internen Gebrauch und die laufen selbstverständlich auf dem Server. Überhaupt gibt es in der gesamten IT eine starke Tendenz zu Webapplikationen, die teilweise an Irrsinn grenzt (Office-Programme als google-Services, na klar tippe ich vertrauliche Korrespondenz auf Systemen, die ich nicht kontrolliere...), die aber vom Wartungsaspekt her natürlich sinnvoll ist: Ein Rechner nur mit Webbrowser ist weitaus einfacher zu pflegen als ein Rechner mit diversen installierten Programmpaketen (Updates, Lizenzverwaltung, Sicherheitsaspekte, Hardwareanforderungen etc. pp.) Ticketsystem, Dokumentationssysteme, Versionsverwaltung, alles ist inzwischen web-, also serverbasiert.

Selber habe ich ein Callcenter mit ca. 40 netzbootenden thin clients für die Agents aufgebaut, die lediglich als Terminal dienen. Die gesamte Benutzerumgebung mit Webbrowser und Office-Programm läuft auf dem Server, dazu noch eine CRM-Webapplikation, fertig. Ist ein Rechner defekt, wird er getauscht, ohne daß irgendeine Konfiguration notwenduig wäre. Der Wartungsaufwand ist nahezu unsichtbar geworden, seit die vollwertigen Arbeitsplatzrechner abgeschafft wurden.

Wenn ein Ing an seinem Arbeitsplatz ein dickes Spezialprogramm für Simulationen oder so was braucht, ist das natürlich was anderes, aber so ein Fall ist SEHR selten beim Computereinsatz in Unternehmen.

Daß nicht generell die Office-Programme auf Servern laufen, was außerdem noch deutlich performanter sein dürfte, liegt im Wesentlichen daran, daß die Bauern nicht fressen, was sie nicht kennen: "Das ham wa immer schon so gemacht, das muß so bleiben."

Hanno

Joerg schrieb:

Hanno

Joerg schrieb:

"This entry is filed under Marketing."

Die Meldung von Microsoft, sie hätten 96% Marktanteil bei Netbooks, hat ebenfalls allgemeine Heiterkeit ausgelöst :)

Hanno

Mach ich auch so, aber dann kommen wieder die Bedenkenträger und Theoretiker, die nie ein Forth angefasst haben ... :-)

Saludos Wolfgang

Rafael Deliano schrieb:

Dafür gibt's doch alle möglichen Emulatorn. Es verbleibt natürlich das Problem die Entwicklungsumgebung zu installieren. Ich habe irgendwann Anno Schnupftabak selbst mal mit sowas gearbeitet. 8048 Assembler unter CP/M unter DOS innerhalb Win 3.1. Hat auch funktioniert.

Hajü

Oh, dann bin ich wohl doch noch in der Steinzeit :-)

Allerdings habe ich schonmal einen FM modulator hier, falls ich in diesem Jahrtausend in Sachen MP3 doch nochmal die Kurve kriege. Bisher reicht mir auf den langen amerikanschen Highways aber der CD Player, aber ich habe die Fahrleistung inzwischen auf um die 3000km/Jahr runter. Den Rest machen die Schuhsohlen.