"Lebensberechtigung" von PIC-µC

Ich empfehle Pellkartoffeln. Halbhart.

--
mfg horst-dieter

Bei den "Ersatztypen" ATmega128, ATmega162, ATmega8515, ATmega8, etc. AFAIK nicht wirklich. Brauchen aber sicher nicht mehr Strom als die Vorgaenger die sie ersetzen.

Es gibt einige neue wie z.B. den ATmega169 der sehr sparsam *sein kann* wenn man ihn richtig betreibt (die aktuelle Revision ist lt. Atmel auch endlich bugfrei).

Wenns um den Preis geht ... das bisschen was man da reinbringt kann oft mit den bescheidenen Ressourcen leben. Wie auch immer, den nicht viel juengeren AT90S2313 kann man ja auch noch kaufen bzw. der kompatible ATtiny2313 steht schon am Start (und ist warscheinlich billiger und besser).

Micha

--
Eine Konstruktion, die gehorsame_Elektronen(tm) benoetigt ;-/
"Gehe bis zur naechsten Ecke, warte dort 0,5s und fliege dann
 weiter ..."
                         Oliver Bartels in de.sci.electronics

*Den* Spruch würd ich mir sofort schützen lassen.

A propos RISC. Ist der entscheidende Punkt nicht der Wegfall des Microcode-Layers? Somit wird die Optimierungsarbeit allerdings auf den Compiler übertragen, was viele dann nicht richtig hingekriegt haben. (Alles etwas nach meinem schlechten Gedächtnis, ist auch nicht aktuell, der andere Gastredner bei den Vorträgen war Konrad Zuse ;-)).

--
mfg Rolf Bombach

Die auch noch Software verdauten, die (fast komplett) maschinell von (8 Bit)

8080-Anwendungen portiert werden konnten. Einige schon unter C/PM beliebte Programme (z.B. WordStar, Turbo Pascal) konnten deshalb schnell für den 8088 angepasst werden.

Klaus

--
Die email Adresse (reply-to) im header ist ungueltig.
Fuer mail "pub . kp2 . pieper @ ibeq . com" benutzen.
(Leerzeichen loeschen).

Reply-to invalid.
Use "pub . kp2 . pieper @ ibeq . com" (remove spaces).

In article , Rolf Bombach writes: |> Thomas Pototschnig wrote: |> > |> > ... mit einem CISC-Befehlssatz - intern aber RISC. |> |> *Den* Spruch würd ich mir sofort schützen lassen. |> |> A propos RISC. Ist der entscheidende Punkt nicht der |> Wegfall des Microcode-Layers? Somit wird die

Nein, nicht ausschliesslich. Ist auch gut so, sonst käme Microchip wirklich damit durch, das PIC-Gelumpe als RISC zu bezeichnen. Der PIC ist nämlich auch ziemlich trivial direkt verdrahtet. Bei der nahe-null Funktionalität der Befehle wäre ein Mikroprogramm auch Verschwendung....

|> Optimierungsarbeit allerdings auf den Compiler |> übertragen, was viele dann nicht richtig hingekriegt |> haben. (Alles etwas nach meinem schlechten Gedächtnis, |> ist auch nicht aktuell, der andere Gastredner bei |> den Vorträgen war Konrad Zuse ;-)).

Das geht inzwischen ganz gut, nachdem die CPUs auch wieder eine Menge Eigenintelligenz bekommen haben, wann sie welche Befehle starten dürfen. Vor 15 Jahren war es aber noch fummelig, der i860 ist daran mehr oder weniger eingegangen. Sauschnelle FPU, aber wg. diverser Haken kaum performant in Hochsprache programmierbar.

Zur Zeit aber immer noch problematisch sind VLIW-Compiler-Techniken für Itanium und andere (TI C6x, Philips Trimedia). Wen's mal grausen will, sollte sich die Orderingregeln für den C6x anschauen, den möchte man auch nicht in Assembler programmieren...

Bei DSPs kann man sich noch damit behelfen, handoptimierte Kernels für FFT, FIR&Co zu machen, bei General Purpose siehts aber noch nicht so gut aus. Könnte gut sein, dass das der Itanium nicht übersteht...

Hm, seltsam, Intel macht alle 10 Jahren einen Griff ins Klo (1980 i432, 1990 i860, 2000 Itanium)...

--
         Georg Acher, acher@in.tum.de
         http://wwwbode.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias

Hallo Thomas,

wenn Du den Falschen PIC verwendest, dann haste ein Problem. Klar, kostengünstige Programmer gibts nicht für alle PICS...

Indirekte Adressierung kann der PIC auch (INDF heisst das Register glaub ich). Lustig wirds bei PIC's > 2K. PCLATH falsch gesetzt und das lustige Wanzenjagen geht los. Warum nimmst Du für den MP3 Player nicht C? da gibts auch für PICs was Kostenloses.

Gruss Jochen

Ich wollte damit sagen: Im Gegensatz haben die AVRs nicht nur eine handvoll Befehle die fast garnichts können (und das was sie können nur umständlich) wie der PIC sondern einen umfangreichen Befehlssatz wie man sie von CISC Prozessoren gewohnt ist, sind aber RISC. Laut Atmel ist der Befehlssatz der AVRs Hochsprachenoptimiert. Jedenfalls behauptet Atmel sie wären RISC aber hier gibt's ja so viele kluge Leute die sicher mehr wissen ;-)

Gruß

Thomas

"Rolf Bombach" schrieb im Newsbeitrag news:40e9acd3$1 snipped-for-privacy@news.bluew> >

Damals, 1999 konnte ich die PICs noch weniger ausstehen als ich sie Heute leiden kann :-) Ich kannte damals z.B. den AVRGCC noch nicht - somit fing ich in Assembler an und zog das Projekt halt durch. Für mich ist es schon fast kein Unterschied ob ich in AVR Assembler oder C programmiere, denn ich vermisse bei den AVR eigentlich garnichts. Voll zufrieden was ich von den PICs nicht behaupten kann. Erst ein Jahr später oder so hab ich dann den ersten AVRGCC gesehen. Auf meiner

Seite hab ich aber einen nachträglich in C geschriebenen Sourcecode, der allerdings nie fertig geworden ist, auch zum Download bereitgestellt.

Ja - die Sache mit dem PCLATH ist mir sehr gut bekannt. Ich liebe die PICs - sie bescheren mir regelmäßig Stunden an Freude in denen ich Fehler suche die auf die bescheuerte Controllerarchitektur zurückzuführen sind. Einen superheißen Fehler hatte ich erst vor ein paar Wochen ...

Gruß

Thomas

"Jochen Rapp" schrieb im Newsbeitrag news: snipped-for-privacy@uni-berlin.de...

ich).

Wanzenjagen

Kostenloses.

Thomas Pototschnig schrieb im Beitrag ...

Das ist immer der Satz, wenn man sich am Assemblercode die Finger bricht -> lieber per Compiler. Denk immer an Werbung aus Urlaubskatalogen.

(obwohl AVR schon eine Linderung gegenueber PIC ist)

--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Thomas Pototschnig schrieb:

Befehle die fast nicht koennen. Wie soll man das verstehen? Umstaendliche Loesungen sind eher RISC typisch.

Fuer mich ist der AVR ein RISC, da fast alle Befehle gleich lang sind und meist gleich lang dauern. Auch fehlen ihm die CISC-typischen Adressierungsarten.

Mich aergert, das einige Befehle des AVR-Assembler, nur bekannte Befehle mit alternativen Mnemonics sind. Das verwirrt manchmal beim Code lesen.

servus thomas «

--
Die 4. Österreichische Fan-Convention zum Thema Japanische Popkultur
** AniNite 2004 ** 20.-22.August 2004 ** http://www.aninite.at/ **
Anime & Manga * J-Pop Bar * Cosplay * Videogames * Go * DDR * AMV *
Manga Workshop * Quiz * Trading Cards * Vortraege * Origami * Kyudo *

"Thomas Pototschnig" schrieb im Newsbeitrag news: snipped-for-privacy@uni-berlin.de...

liebe die PICs -

Fehler suche die

Einen

Hatte bisher noch nie Fehler meiner Programmierkunst bis auf die Architektur der Hardware zurückgeführt, wahrscheinlich denke ich da zu kurz... (*Ironie*).

Probleme mit denen ich in meinen letzten -zig Projekten zu kämpfen hatte, lagen ausschliesslich auf einer anderen, höheren Komplexitätsebene. (Nicht zuletzt konzeptionelle Schwächen --- inzwischen denke ich dass mindestens 2/3tel der Softwareentwicklung (in Arbeitszeit gemessen natürlich) für das Endprodukt auf die Konzeption entfallen sollte und der erste step besteht sinnvollerweise in einem 'rapid prototype' zum rumspielen, evtll. auch für den Kunden zur Verifikation des Grundkonzepts, (a la 'breadboard'. Das Spielzeug 'bottom-up' und vielleicht auch nicht alles ins Detail ausgearbeitet --- das Endprodukt dann 'ordentlich' top-down... )

Tatsächlich musste ich vor Jahren mal 'aus dem Feld' nachbessern, da ging was in den latch-up. Verschämt muss ich allerdings eingestehen dass es tatsächlich _mein_ Fehler war; ich hatte das Datenblatt nicht sorgfältig genug gelesen... nach kurzem Umstricken der Software lief dann alles.

So rächt sich das fehlendes Gedankenlesemodul im Baustein. Schande über den Hersteller!

zum Thema: Ich suche mir die Zielhardware nicht unbedingt als erstes aus (Konzeption), auch nicht bereits im zweiten Entwicklungsstep (funktionales dekomponieren in testbare Module), meist erst deutlich später (eigentlich erst möglich, wenn die Anforderungen der Module parametrisiert sind). Da ich es zumeist mit Steuerungen kleiner Geräte (mit PC-Anbindung) zu tun habe, reichen fast immer die _allerkleinsten_ (billigsten) PICs völlig aus. (Letztens hatte ich mich noch geärgert über einen in einem Serienprodukt eingesetzten 16F874, der da m.E. nix drin zu suchen hat... 1/3tel seines Preises reicht dicke aus...)

Für einen mp3 player würde ich wohl keinen PIC nehmen --- würde aber auch keinen solchen player machen wollen, lohnt irgendwie nicht...

Ach ja: An PCLATH kann ich nix aufregendes entdecken, was ist denn damit?

Apropos "stundenlange Fehlersuche in Software"... schreibt man kleine, funktional nicht überladene Module sollte sich ein Fehler doch leicht eingrenzen lassen --- es sei denn man hat bei der Konzeption geschlampt, dann ist wohl alles Murks... am besten neu machen, dann. Wenn du "stundenlang suchen musst", würde ich vorschlagen: Schreib es neu (und besser, übersichtlicher). Zumindest du selbst solltest schon Durchblick haben bei deinem Werk unmittelbar nachdem du es gemacht hast :-)

mit freundlichen Grüssen: Rüdiger

Klar lohnt sich das jetzt nicht mehr - aber vor 5 Jahren hat sich das gelohnt :) Wäre da vor 5 Jahren (nach der Lehre zum Kommunikationselektroniker Fr. Funktechnik) die Bundeswehr mit dem Blöden Grundwehrdienst nicht dazwischengekommen, hätte daraus was werden können...

Mein Konzept ist "kein Konzept" :-) Ne - die Sache mit dem PCLATH war, dass ich in eine Tabelle realisieren wollte, in der mittels addition zum Programmcounter gesprungen wird und mittels RETLW wieder zurück. Dummerweise gab es da einen Fehler mit dem PCLATH, dass 2 Bits oder so durch den Call in die Unterfunktion nicht gesetzt wurden. Sehr seltsames Problem. Laut Manual hätte das einwandfrei funktionieren müssen. Bei der Addition zu dem Programmcounter ist das Teil dann irgendwohingesprungen, weil die besagten Bits noch den Zustand hatten vor dem Call in meine Unterfunktion. War ein saublöder Fehler, der bei den AVRs mir noch nicht passiert ist. Wie denn auch? Da gibts so dumme Sachen nicht weil die Architektur moderner ist.

Wie gesagt - die einzigen Fehler die ich nicht finde, sind die mit denen ich nicht rechne - z.B. unvorhersehbare Fehler die Architekturbedingt sind. Sonst bin ich relativ fit mit Fehlersuche - auch ohne Debugger.

Gruß Thomas

"Ruediger Klenner" schrieb im Newsbeitrag news:ccerta$fgh$ snipped-for-privacy@sunu789.rz.ruhr-uni-bochum.de...

Endlich mal ein Beitrag von jemanden, für den das Programmieren von Microcontrollern nicht einem Selbstzweck, sondern zum Lösen einer Aufgabe dient.

Jede Microcontrollerfamilie hat ihre Stärken und ihre Schwächen. Die Entscheidung für einen Microcontrollertyp sollte nicht von subjektiven Vorlieben abhängig gemacht werden, sondern von den jeweiligen Applikationsanforderungen, dem Preis, der Verfügbarkeit und dem technischen Entwicklungs- und Produktionsumfeld.

Bei einem guten Programmierer steht die Applikation im Vordergrund. Programmier- und Hardwarekenntnisse sind lediglich das notwendige Handwerkszeug, welches er beherrschen muß. Es geht also darum, wie mit den gegebenen Mitteln die jeweilige Aufgabe möglichst optimal umgesetzt werden kann. Jammern und schimpfen ist dabei fehl am Platz - Kreativität und ein umfangreicher Kenntnisstand sind gefragt.

Um bei der Überschrift zu bleiben: Auch mit PIC-Controllern lassen sich, wie mit allen anderen Familien auch, an geeigneter Stelle "Wunder" vollbringen. Oder anders gesagt, in vielen Produkten, die einen Wettbewerbsvorteil besitzen, ist ein PIC-Controller eingebaut.

MfG Martin

damit

ziemlich

ein

Ich glaub, das beantwortet erstaunlich gut und knapp die ursprüngliche Frage ;-]. Könnte mal jemand nach dan einreichen...

Eine Zeit lang hat DEC darüber ja gelacht. Jetzt nicht mehr.

--
mfg Rolf Bombach

Im Drummer wird behauptet, im "Microelectronics", Vol.8. (1976)p17 wäre erwähnt, dass Intel den ersten Microcomputer 1972 konstruiert hätte. Inwieweit der aber noch diskret war und was darin der eigentliche Controller war, keine Ahnung, ich hab die Quelle nicht.

reichste

Mittlerweile soll's der Ikea Boss sein. Liegt wohl an der Qualität der Produkte.

--
mfg Rolf Bombach

|> Im Drummer wird behauptet, im "Microelectronics", Vol.8. (1976)p17 |> wäre erwähnt, dass Intel den ersten Microcomputer 1972 konstruiert

Du meinst wohl Mikroprozessor. Damals war Microcomputer wohl "alles kleiner als ein Schreibtisch"...

|> hätte. Inwieweit der aber noch diskret war und was darin der |> eigentliche Controller war, keine Ahnung, ich hab die Quelle nicht.

Doch, so das stimmt schon so. Der 4004 war ursprünglich für eine Tischrechenmaschine der Firma Busycom gedacht und hätte auch keine CPU werden sollen. Nachdem die Auftraggeber aber dauernd die Specs geändert haben, dachte man bei Intel, dass eine kleine Universal-CPU für das Moving-Target weniger anstrengend wäre. Busycom ging dann aber pleite und der 4004 blieb so übrig ;-)

Der 4004 war aber kein Microcontroller, er hat noch zwei, drei andere Chips gebraucht (IO-Expander, ROM, RAM und so).

--
         Georg Acher, acher@in.tum.de
         http://wwwbode.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias

In article , Rolf Bombach writes: |> Im Drummer wird behauptet, im "Microelectronics", Vol.8. (1976)p17 |> wäre erwähnt, dass Intel den ersten Microcomputer 1972 konstruiert |> hätte. Inwieweit der aber noch diskret war und was darin der |> eigentliche Controller war, keine Ahnung, ich hab die Quelle nicht.

Der i4004 als erster Mikroprozessor wurde m.W. sogar schon 1971 vorgestellt.

Etwas vergleichbares, aber diskret aufgebaut, gab's IIRC in einer Elektor- Ausgabe von 1975.

Wer nun den Preis für den ersten Mikrocontroller erhält -- ob nun TI (TMS1000), GI (1650) oder Intel -- müßte ich erst nachschauen.

|> Mittlerweile soll's der Ikea Boss sein. Liegt wohl an |> der Qualität der Produkte.

Eher am Abstinken des Dollarkurses. Die durchschnittliche Ikea- Produktqualität kann sich IMO durchaus mit Microsoft messen :)

Rainer

Rainer Buchty schrieb:

Nö, ich einige Möbel von Ikea, Bluescreen gabs noch nie...

Gruß Dieter

Wiso? Bauen die Tresore die neben der Tür einen Vorhang haben. Eventuell noch mit der Aufschrift "Eintritt nur für ms-mitarbeiter".

--
MFG Gernot