H
horst-dieter
Guest
MaWin wrote:
--
mfg horst-dieter
Ähem, derzeitiger Lieblingsausdruck?
--
mfg horst-dieter
J
Jan C. Bernauer
Guest
Hi,
etwas am Thema vorbei, aber hat hier jemand schon mal die dsPICs
getestet? 16 bit und "dsp" klingt ja ganz gut...
Viele Grüße,
Jan.
----
Jan C. Bernauer
etwas am Thema vorbei, aber hat hier jemand schon mal die dsPICs
getestet? 16 bit und "dsp" klingt ja ganz gut...
Viele Grüße,
Jan.
----
Jan C. Bernauer
H
horst-dieter
Guest
MaWin wrote:
--
mfg horst-dieter
Ich empfehle Pellkartoffeln. Halbhart.
--
mfg horst-dieter
M
Michael Baeuerle
Guest
Steffen Koepf wrote:
AFAIK nicht wirklich. Brauchen aber sicher nicht mehr Strom als die
Vorgaenger die sie ersetzen.
wenn man ihn richtig betreibt (die aktuelle Revision ist lt. Atmel auch
endlich bugfrei).
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
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 oftBTW: Den allerersten AVR, den AT90S1200 gibt es immer noch.
Ja, den will man aber nicht wirklich nehmen
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
R
Rolf Bombach
Guest
Thomas Pototschnig wrote:
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
*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
K
Klaus P. Pieper
Guest
Peter Heitzer wrote:
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).
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).
G
Georg Acher
Guest
In article <40e9acd3$1_3@news.bluewin.ch>,
Rolf Bombach <rolfnospambombach@bluewin.ch> 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
Rolf Bombach <rolfnospambombach@bluewin.ch> 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
J
Jochen Rapp
Guest
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
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
T
Thomas Pototschnig
Guest
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" <rolfnospambombach@bluewin.ch> schrieb im Newsbeitrag
news:40e9acd3$1_3@news.bluewin.ch...
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" <rolfnospambombach@bluewin.ch> schrieb im Newsbeitrag
news:40e9acd3$1_3@news.bluewin.ch...
T
Thomas Pototschnig
Guest
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 www.oxed.de 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" <j.rapp@addcom.de> schrieb im Newsbeitrag
news:2kttrkF6gi68U1@uni-berlin.de...
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 www.oxed.de 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" <j.rapp@addcom.de> schrieb im Newsbeitrag
news:2kttrkF6gi68U1@uni-berlin.de...
M
MaWin
Guest
Thomas Pototschnig <thomas.pototschnig@gmx.de> schrieb im Beitrag <2kv0n6F6ckf1U1@uni-berlin.de>...
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.
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.
T
Thomas Mozgan
Guest
Thomas Pototschnig schrieb:
Umstaendliche Loesungen sind eher RISC typisch.
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 *
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 *
R
Ruediger Klenner
Guest
"Thomas Pototschnig" <thomas.pototschnig@gmx.de> schrieb im
Newsbeitrag news:2kv13eF6sukiU1@uni-berlin.de...
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
Newsbeitrag news:2kv13eF6sukiU1@uni-berlin.de...
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
T
Thomas Pototschnig
Guest
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 ichWenn 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
nicht rechne - z.B. unvorhersehbare Fehler die Architekturbedingt sind.
Sonst bin ich relativ fit mit Fehlersuche - auch ohne Debugger.
Gruß Thomas
M
Martin Konopka
Guest
"Ruediger Klenner" <Ruediger.Klenner@ruhr-uni-bochum.de> schrieb im
Newsbeitrag news:ccerta$fgh$1@sunu789.rz.ruhr-uni-bochum.de...
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
Newsbeitrag news:ccerta$fgh$1@sunu789.rz.ruhr-uni-bochum.de...
Endlich mal ein Beitrag von jemanden, für den das Programmieren vonHatte 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
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
R
Rolf Bombach
Guest
Georg Acher wrote:
ursprüngliche Frage ;-]. Könnte mal jemand nach dan einreichen...
--
mfg Rolf Bombach
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
R
Rolf Bombach
Guest
Rainer Buchty wrote:
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 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
hätte. Inwieweit der aber noch diskret war und was darin der
eigentliche Controller war, keine Ahnung, ich hab die Quelle nicht.
Mittlerweile soll's der Ikea Boss sein. Liegt wohl an
der Qualität der Produkte.
--
mfg Rolf Bombach
G
Georg Acher
Guest
In article <40eb01a2$1_2@news.bluewin.ch>,
Rolf Bombach <rolfnospambombach@bluewin.ch> writes:
|> 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
Rolf Bombach <rolfnospambombach@bluewin.ch> writes:
|> 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
D
Dieter Wiedmann
Guest
Rainer Buchty schrieb:
Gruß Dieter
Nö, ich einige Möbel von Ikea, Bluescreen gabs noch nie...Die durchschnittliche Ikea-
Produktqualität kann sich IMO durchaus mit Microsoft messen
Gruß Dieter
R
Rainer Buchty
Guest
In article <40eb01a2$1_2@news.bluewin.ch>,
Rolf Bombach <rolfnospambombach@bluewin.ch> 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
Rolf Bombach <rolfnospambombach@bluewin.ch> 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