Rufus t. Firefly wrote:
> http://www.ccc.de/hackabike/index_de.html
Schade, dass sie bei eigentlich (immerhin durch den CCC bescheinigter)
guter Intelligenz so trottelig waren, die Lockbits nicht zu setzen.
Die Fragestellung hier im Thread ist durch das Wort "Profi" eigentlich viel zu allgemein. Man hätte schon fast schreiben können "Atmel ist unter Menschen nicht gerade beliebt". Die Fragestellung, die mich viel mehr interessiert ist: Wo sind die typischen Einsatzbereiche für AVR's und wo werdern sie eher gemieden? Da scheint sich herauszukristallisieren, dass im Automobilbereich die Teile eher gemieden werden. Ebenso in Bereichen, wo langfristige Verträge gemacht werden und große Stückzahlen der Controller immer am Markt verfügbar sein müssen. In einer Firma, wo z.B. 1000 Geräte im Jahr mit AVR gebaut werden, ist es überhaupt kein Problem, Engpässe von 6-12 Monaten durch Lagerhaltung zu überbrücken. Ebenso wird ein umdesignen alle 5-10 Jahre, wenn mal ein Chip nicht mehr verfügbar ist, oft kein Problem darstellen. Zumal die Nachfolgetypen bisher recht kompatibel waren. Das große Horrorszenario wäre, wenn AVR mal pleite geht und man auf völlig andere Chips umsteigen müsste. Aber das wird wohl nicht passieren: Die Firma würde übernommen werden und der Markt, der ja da ist, weiterbedient.
Ob es tatsächlich Vorsprung war, oder nur gutes Marketing? Vor vielen Jahren wurden mir persönlich die MCS51er zu langsam und zu aufwendig. Für jeden Hersteller eines Derivats dieser Klasse musste man einen eigenen Programmer bauen oder kaufen. Motorola wuselte parallel mit seinen HC Typen herum und hatte, wie zuvor die MCS auch das Problem mit einem externen Latch und ROM. Dazu kam, dass man vom Z80 zum MCS Bustechnisch nicht so weit umdenken musste und PullUps waren mir schon immer lieber als PullDowns. (Motorola hatte doch ein Active-High Chip-Select, oder?) Aufgrund diverser inkompatibilitäten zog also auch das Argument Second-Source innerhalb der MCS51er nicht mehr wirklich, wenn man auch nur kleine Verbesserungen mitnehmen wollte. Da kochte jeder Hersteller sein eigenes Süppchen. Wollte man zudem mehr Geschwindigkeit, dann gab es mit Dallas auch nur einen einzigen Hersteller und einen unannehmbaren Preis für Einzelstücke. PIC verlangte für jeden Chip eine eigene IDE, totaler Murks. So bin ich, weil preiswert und All-Inclusive auf den AT90S8515 gekommen. Irgendwie sah die Idee dahinter sehr einfach und einladend aus. RISC, Single-Cycle Instructions... Ein Programmer erschlug eine ganze Serie Chips unterschiedlicher Größe, eine IDE für alle Chips. Damals habe ich alles noch in Assembler gemacht, 150 Befehle hatte man an zwei Nachmittagen drauf. Eine große Erleichtung war auch das Errechnen von Timings bei der Hardwareemulation in Software. Serielle, IR, SCSI, diverse perallel und serielle Bussysteme, was hab ich nicht alles emuliert... Es war sicherlich eine Gefühlsentscheidung, weil das Konzept einfach simpel, offen und durchgängig erschien. Ob es das Marketing war, oder eben der klitzekleine Konzeptvorsprung gegenüber anderen Systemen, ich kann es heute nicht mehr sagen. Letztendlich zählt aber, dass mich ATMEL bis heute nicht ein einziges mal im Stich gelassen hat, es gab immer einen Chip der passte und jede Support-Anfrage, egal ob privat oder Beruflich, wurde kurzfristig und zufriedenstellend beantwortet. Natürlich sind die ehemaligen Konkurrenten auch gewachsen. PIC verfügt inzwischen über eine IDE für alle, und viele andere Hersteller sind mit neuen Designs und Ideen auf dem Markt gekommen. Bislang konnte mich keine Aufgabe dazu bringen etwas anderes als einen AVR einzusetzen obwohl ich fast jede Neuentwicklung in diesem Bereich aufmerksam verfolge. Vielleicht ist es auch anders herum gewesen? Zufor schrieb schon jemand, dass die alten Systeme in den Köpfen der Entwickler zu stark verankert sind. Ich kenne Sprüche wie "Wir entwickeln seid 30 Jahren für den Z80 und werden das auch in 20 Jahren noch machen". Vielleicht hatte ATMEL bei mir Glück, weil ich damals gerade erst auf dem Sprung vom Hobby-Bastler zum Entwickler war und sowohl Zeit als auch Neugier genug hatte um einen großen Schnitt zwischen MCS51 und 'Etwas Neuem' zu machen. Gruß, Astralix
Ulrich P. wrote:
> PIC verlangte für jeden Chip eine eigene IDE, totaler Murks.
Nur so aus Neugier, kannst Du das etwas erläutern?
War das in der Zeit von MPLAB? Unter DOS?
Danke
Ich möchte Ulrich P. weitgehend zustimmen, obwohl bei Motorola alle CS immer low-aktiv waren :-) Der erste Typ AT90S1200 hob sich nur wenig von den damaligen PICs ab: kein RAM, kein Stack. Aber mit den zum 8051 DIL40 und 2051 DIL20 kompatiblen Typen 8515 und 2313 konnte man dann auf einfache Weise seine vorhandene 8051-Schaltung damit testen, zunächst in Assembler, der nicht viel konnte, aber den es kostenlos gab. Der Geschwindigkeitsunterschied war wie Tag zu Nacht. Und da man wiederholt umprogrammieren konnte, wollte ich den 8051 auch garnicht mehr haben. Alles in einem Gehäuse war einfach zu praktisch. Profi hin - Profi her, mit den Atmels kann man gut seine Brötchen verdienen.
"Ebenso wird ein umdesignen alle 5-10 Jahre, wenn mal ein Chip nicht mehr verfügbar ist, oft kein Problem darstellen." Das halte ich für eine seeeehr optimistische Sichtweise. In der Realität ist nach 10 Jahren der Entwickler an einem ganz anderen Projekt, anderen Abteilung oder einer anderen Firma. Die Tools produzieren plötzlich ganz anderen Code und können mit der Source nichts mehr anfangen. Wenn sie überhaupt noch verfügbar sind. In der Regel bedeutet so etwas ein Neudesign. Und das dann evtl. für ein Produkt, für das nur noch Ersatzstückzahlen benötigt werden. Da setzt man dann eben lieber Hersteller ein, die noch Bausteine von vor 10 Jahren im Programm haben. Die haben dann schon mal bewiesen, dass sie langfristig liefern. Und letzlich sind die Vorteile der verschiedenen Architekturen nicht so gravierend, alle kochen mit Wasser und kein Controller ist wirklich herausragend besser. Gruss Axel
Gast wrote: >Aber mit den zum 8051 DIL40 und 2051 DIL20 kompatiblen Typen 8515 und >2313 konnte man dann auf einfache Weise seine vorhandene 8051-Schaltung >damit testen, zunächst in Assembler, der nicht viel konnte, aber den es >kostenlos gab. Bitte erwähne aber auch, dass der Reset-Pegel unterschiedlich ist. Also nicht ohne Umbauten auf der gleichen leiterplatte einsetzbar. Desweiteren hat Atmel bisher für jeden abgekündigten Baustein einen funktionskompatiblen und besser ausgestatteten Ersatz geschaffen, sodass nach dem (leider neu anzupassenden) Bearbeiten des Quellcodes durchaus die Produktion weiter gehen konnte. Ich bin selber einige Male in die Falle des Kompatibilitätsbits des M103 gelaufen wie viele hier im Forum. Wenn das konsequent durchgezogen wäre á la Bit gesetzt, IC arbeitet mit der alten ID (HEX-Dump unbearbeitet), Bit gelöscht, alle neuen Features stehen einem zur Verfügung (mit neuem Kompilat), das wäre sinnig gewesen. MW
>Bitte erwähne aber auch, dass der Reset-Pegel unterschiedlich ist. Also >nicht ohne Umbauten auf der gleichen leiterplatte einsetzbar. Gut, eine Änderung war aber sowieso notwendig, da man ISP nutzen wollte. Aber alle Portpins konnten bleiben und die ser. Schnittstelle unterstützte auch den Multiprozessormodus vom 8051. Der Aufwand zum Probieren war somit minimal.
Axel wrote: > "Ebenso wird ein umdesignen alle 5-10 Jahre, wenn mal ein > Chip nicht mehr verfügbar ist, oft kein Problem darstellen." > > Das halte ich für eine seeeehr optimistische Sichtweise. > Nein, bis auf wenige Ausnahmen läuft es doch so ab: Kunde braucht einen Ersatz für etwas, dass er vor vielen Jahren bei irgendwem gekauft hat, der schon längst was anderes macht oder pleite ist. Die Bauteile sind kängst nicht mehr verfügbar. Im Grunde war der Kunde eh nie so ganz zufrieden und will im Zuge der Aufrüstung gleich das ein oder andere Feature mehr haben. Meine letzten Projekte fingen alle damit an, dass nur eine SPS ersetzt werden sollte durch eine andere und dann das ganze System bitte weiter 5x aufbauen. Es endete damit, dass das nach Einsammeln aller Wünsche feststand, dass diese unter Einsatz einer SPS icht erfüllt werden könnten. Also wurde ein Prototyp auf Basis einer vollen Eigenentwicklung mit AVR und SAM7 erstellt, der wiederum so gut gefiel, dass gleich 7 weitere Systeme beauftragt wurden. Bei einem anderen vor 15 Jahren erstmalig ausgelieferten Gerät steht nun ein Ersatz an, da auch hier die Bauteile nicht mehr lieferbar oder unbezahlbar sind. Da inzwischen ein grafikfähiges Display, SD-Card und USB unverzichtbar sind, wurde aus einem 98S8151 ein SAM7. Letztendlich muss man dem Kunden klar machen, dass er, wenn er mehr Leistung und Features haben will auch etwas Gedult und Kleingeld investieren muss um dann weitere 10..15 Jahre zu überleben. Natürlich legt man sich auch als kleine Bude ein wenig Reserven auf Lager. Dadurch, dass man aber seine Entwicklungen auf einige Typen einschränkt, relativiert sich diese Lagerhaltung aber. Es ist bei Kleinserien schon mal billiger einen ATmega64 einzusetzen, wenn man diesen schon in drei anderen Projekten verwendet, als einen ATmega16, den man speziell nur für ein Board einsetzt und den man dann auch auf Halde legen muss um irgendwelche 10-Jahres Verträge einzuhalten. > In der Realität ist nach 10 Jahren der Entwickler an einem ganz anderen > Projekt, anderen Abteilung oder einer anderen Firma. Die Tools > produzieren plötzlich ganz anderen Code und können mit der Source nichts > mehr anfangen. Wenn sie überhaupt noch verfügbar sind. > Das ist sicherlich in besonderen Projekten ein Problem. Andererseits ist es aber auch eine Frage der Disziplin. Wenn man jedem Projekt eine Datensicherung mit ihrem Letzten Stand gewährt und auch Datenblätter und Compiler dort hinzufügt, kann ein Stand schnell wieder hergestellt werden. Andererseits muss man Prioritäten setzen. Wenn ich Zulieferer für die Deutsche Bahn oder Automobilindustrie bin oder nach Avionic Normen Arbeiten muss, dann ist das sicherlich eine aufwendige Sache. Aber in fast allen anderen Bereichen ist es eine Frage des verkäuferischen Geschicks den Kunden von einem Benefit bei einer Plattformumstellung zu überzeugen. Und ich verstehe dabei nicht, ihn anzulügen um seine eigenen Versagenskosten wegen fehlender Datensicherungen zu decken. > Da setzt man dann eben lieber Hersteller ein, die noch Bausteine von vor > 10 Jahren im Programm haben. Die haben dann schon mal bewiesen, dass sie > langfristig liefern. > Wie gesagt, dass ist eine Fall zu Fall Entscheidung. So pauschal, wie Du das darstellst, sehe ich das bei weitem nicht. Technischer Stillstand tut weder dem Lieferanten noch dem Kunden gut. > Und letzlich sind die Vorteile der verschiedenen Architekturen nicht so > gravierend, alle kochen mit Wasser und kein Controller ist wirklich > herausragend besser. > Da kann ich allerdings nur zustimmen. Im Grunde muss man entscheiden, ob eine neue Plattform durch ihre speziellen Features mehr Zeit einspart als für ihre Einarbeitung erforderlich ist. Im Gegenzug muss man auch betrachten, ob diese Ersparnis immer noch gilt, wenn man dieses spezielle Feature mit erhöhtem Aufwand auf einer bekannten Plattform emuliert. @GAST > Ich möchte Ulrich P. weitgehend zustimmen, obwohl bei Motorola alle CS > immer low-aktiv waren :-) War es nicht so, dass Motorola dieses High-Aktive E(nable) Signal hatte? Zugegeben, ist zu lange her. @Severino > Nur so aus Neugier, kannst Du das etwas erläutern? > War das in der Zeit von MPLAB? Unter DOS? Das kann gut sein, ich habe mit den MCS51ern und später dann mit den AVRs schon gearbeitet, als Windows noch in den Versionen 3.x und kleiner existierte. Auch der AVR Assembler war eine reine DOS-Applikation. Hei, wie die Zeit vergeht... Gruß, Astralix
Ulrich P. wrote: > @Severino >> Nur so aus Neugier, kannst Du das etwas erläutern? >> War das in der Zeit von MPLAB? Unter DOS? > Das kann gut sein, ich habe mit den MCS51ern und später dann mit den > AVRs schon gearbeitet, als Windows noch in den Versionen 3.x und kleiner > existierte. Auch der AVR Assembler war eine reine DOS-Applikation. Hei, > wie die Zeit vergeht... > Meinte natürlich " in der Zeit voR MPLAB...". Und ich habe unter DOS Z80-Programme entwickelt, und Windows 3.x startete man nur für bestimmte Anwendungen, und die Zeit vergeht auch für mich... Aber trotzdem: Welche PIC-Typen brauchten eine gesonderte IDE?
Jörg Wunsch wrote:
> Das ist einfach: "Profi" ist die Abkürzung von "professionell"
Ich ging bisher immer davon aus, dass "Profi" von "provisorisch" kommt
;-)
>Ich ging bisher immer davon aus, dass "Profi" von "provisorisch" kommt
Das ist gar nicht mal so falsch.
Das Provisorium hält am längsten ;)
Kann ich nur bestätigen. Bei mir zu Hause laufen fast nur provisorische "fliegende" Aufbauten. Beim Portieren dieser zu entgültigen Gerätschaften schleicht sich immer irgendwo ein Fehler ein. Inzwischen versuch ich's gar nicht mehr, meine fliegenden Aufbauten verschwinden zu lassen.
war lange nicht hier, deshalb habe ich in dem 'alten' zeug rumgekramt. zu meiner person : ich verdiene seit 83 mit µp / µc mein geld. bin über z8 (bockiges mißtvieh) über z80 und pic bei avr gelandet. meine meinung zu avr: was mir grfällt: - simpler befehlssatz (glaube, so um die 130, wovon ich max. 40% nutze) - schnell wie der blitz - sehr, sehr, sehr , ... guter adc - verfügbarkeit rel. großer µc'c im dil gehäuse (für prototypen) was mir nicht gefällt: - die doppelt- oder dreifachbelegung der pin's - die teilweise kryptische bezeichnung der 'fuse bit's' - und das schlimmste, die assembler syntax (die namen der bedingten rel. sprünge zb. breq -> "gehe frühstücken, wenn es gleich ist", warum nicht jrz wie beim z? diese syntax ist wesentlich verständlicher, weil sie sich direkt auf ein flag bezieht. warum ldi , lade register mit konstante und nicht mov, der compiller sollte doch alleine zwichen einem register und einer konstanten unterscheiden können? ....... wenn das mir einer erklären könnte wäre ich dankbar. gruß pico
@pico: Nunja, wer von der z80-Seite kommt, muß sich natürlich umgewöhnen, die Bezeichnungen sind verständlich, wenn man sich ein paar Millimeter von der Hardware löst, z.B.: breq = Branch if equal --> Verzweige wenn gleich. Jump Relative Zero trifft es zwar auch, breq paßt aber perfekt, wenn man einfach nur am Ergebnis interessiert ist. LDI = LoaD Immediate --> Lade Wert direkt ins Register. Ist eigentlich auch verständlicher, denn durch das LDI weiß ich, der dabeigefügte Wert geht direkt ins Register. Natürlich könnte man alle Speicher-/Registerladeanweisungen mit 'MOV' bezeichnen, aber mit STI/STS/LDI/LDS/MOV separat sehe ich im Assemblertext direkt, woher die Daten kommen und wohin sie geladen werden. Natürlich wäre ein Assembler in der Lage, anhand kryptischer Zeichen und unterschiedlicher Klammern bei der Wertangabe selbst zu entscheiden, wo was hingeschoben wird, so wie es aber beim AVR-ASM gemacht wird, ist es aber merklich besser lesbar. Und mir persönlich auch lieber. Ich habe übrigens auch schon verschiedenste Architekturen hinter mir, unter anderem Z80/8085, R6502, 6800/1/2, 8048, 8086. Und ehrlich gesagt, die AVR-Controller sagen mir, was Assemblersprache und Architektur anbelangt, noch am ehesten zu. Hätte ich bei der Entwicklung was zu sagen gehabt, wären ein paar zusätzliche Befehle mit hineingekommen: z.B. ein Add Immediate und ein Decimal Adjust, der BCD-Operationen merklich vereinfacht. Und der Stack beim AT90S1200 und den anderen RAM-losen Teilen hätte auch ein paar Ebenen mehr gehabt. Gegen die Doppelt-, Drei-, Vierfachbelegung ist leider kein Kraut gewachsen, die Anzahl der Anschlüsse ist nunmal begrenzt. Und die Benutzer der Chips wollen nunmal alle möglichen Funktionen mit drinhaben, da muß man sich entscheiden, was man hinterher braucht und ggfs. langsame Peripherie seriell anbinden, will man nicht in jedes kleine Gerät ein 100pin-Monster einsetzen. Nur das ist ein generelles Problem aller modernen Controller-Architekturen und eben kein originäres AVR-Problem. Gruß Jadeclaw.
@Jadeclaw
.... ,dann sollte avr das z-flag im sreg in in e-flag umtaufen und
verbieten das logische opp's das e-flag beeinflussen! für mich
wäre dann mämlich ein konstukt von ....
ldi r16, 0b00000001
or i r16, 0b00000001
breq xyz
... nicht mehr lesbar.
gruß pico
pico wrote: > was mir nicht gefällt: > > - die doppelt- oder dreifachbelegung der pin's Das läßt sich kaum umgehen. Dagegen ist die Pinzuordnung bei den Silabs 8051 ne totale Katastophe. Sobald man einen Pin zuweist, verschieben sich die Funktionen aller nachfolgenden Pins nach hinten. Man muß also schon vor dem Layout ganz genau wissen, welche Spezialfunktionen man benötigt. Danach ist ein Wechsel unmöglich. > warum ldi , lade register mit konstante und nicht mov, der compiller > sollte doch alleine zwichen einem register und einer konstanten > unterscheiden können? ....... Naja, beim 8051 wird gerne mal das "#" vergessen bei Konstanten und der Code nimmt es als Adresse. Und man sucht ewig den Fehler. Etwas gewöhnungsbedürftig ist es allerdings, statt 3 Ladebefehlen (MOV, MOVC, MOVX) nun 15 Befehle zu benötigen (MOV, MOVW, LPM, SPM, IN, OUT, LD, ST, BST, BLD, LDI, LDD, LDS, STD, STS). Peter
pico wrote: > was mir nicht gefällt: > > - die doppelt- oder dreifachbelegung der pin's Jupp, is bissi gefährlich, insbesondere mit dem SPI-Zeuchs. Ist ja auch eine oft genug angesprochene Stolperfalle, aber wenn mans weiß, ists kein Thema mehr. > - und das schlimmste, die assembler syntax (die namen der > bedingten rel. sprünge zb. breq -> "gehe frühstücken, wenn es > gleich ist", warum nicht jrz wie beim z? diese syntax ist wesentlich > verständlicher, weil sie sich direkt auf ein flag bezieht. Naja, breq hat vermutlich seinen Namen von der Vergleicherei. Die wiederum ist aber auch nur eine Subtraktion und das Steuerwerk setzt im Statusregister das Nullbit automatisch immer dann, wenn irgendwo Null bei rauskommt. Deshalb kann man auch z.B. nach einem LSR/LSL mit breq weiterprüfen. > warum ldi , lade register mit konstante und nicht mov, der compiller > sollte doch alleine zwichen einem register und einer konstanten > unterscheiden können? ....... > wenn das mir einer erklären könnte wäre ich dankbar. Jupp, das kann dir einer erklären^^ Ganz verallgemeinert und banal: Ein ASSEMBLER ist kein COMPILER. Der Compiler erzeugt aus Hochsprachenquelltext (C, Basic etc.) einen Assemblerquelltext. Und der Assembler übersetzt den Assemblerquelltext in Maschinensprache. Irgendwo ist es ja der Sinn des Assemblers, eben gerade keine automatische Rumersetzerei zu machen, ich will ja genau das als Maschinencode erhalten, was ich als Assemblerquelltext reinschreibe.
@Jadeclaw
>Add Immediate und ein Decimal Adjust ....
die befehle vermisse ich nicht so, da subi mit dem zweiercompliment
den addi befehl ersetzt.
aber einen der wirklich geschwindigkeit bringen würde.
nämlich ret 6 -> vergiß die letzten 6 byte auf dem stack und kehre
zurück.
folgender hintergrund:
manchmal ergibt sich in der sub, dass eine rekonstruktion der register
keinen sinn mehr macht. aber ich muß mich mit pop's zurückhangeln, das
kostet ordentlich zeit! ich würde nicht in assembler programmieren, wenn
es bei mir nicht selten um einen einstelligen µs-bereich gehen würde.
da hat man unter umständen nur 20-50 takte (befehle) zeit zum reagieren.
gruß pico
pico wrote: > folgender hintergrund: > > manchmal ergibt sich in der sub, dass eine rekonstruktion der register > keinen sinn mehr macht. aber ich muß mich mit pop's zurückhangeln, das > kostet ordentlich zeit! ich würde nicht in assembler programmieren, wenn > es bei mir nicht selten um einen einstelligen µs-bereich gehen würde. > da hat man unter umständen nur 20-50 takte (befehle) zeit zum reagieren. Beim IAR-Compiler werden 2 Stacks konfiguriert, einen RSTACK und ein CSTACK. Der RSTACK ist nur für die Rücksprungadressen und der CSTACK für die Registerspeicherung. Der CSTACK wird mittels Y Register realisiert: ST -Y,Rr <-- wie PUSH LD Rd,Y+ <-- wie POP Werden Register nicht benötigt nach Funktionsaufrufen so kann das Y Register einfach manipuliert werden mittels ADIW oder SBIW
@Gottfried S. das ist ja genial, auf die idee bin ich nach über 20 jähriger berufserfahrung noch nicht gekommen. einfach mit 2 stack's arbeiten. daten und rücksprungadressen sauber trennen. danke pico (das kommt von herzen)
Ich vermisse Shifts mit Angabe der Anzahl der Bits, also sowas: LSR r0,3 um 3 Bits rauszuschieben. Das würde so manchen Code ziemlich beschleunigen. Und dann verstehe ich nicht warum nicht alle AVRs, egal ob Tiny oder Mega, die exakt gleiche ALU und somit auch alle die gleichen Befehle haben. Es wäre schon vorteilhaft die MUL Opcodes auch auf den Tinys zu haben. Das kann nur mit dem Marketing zu tun haben. Gruß Hagen
> Es wäre schon vorteilhaft die MUL Opcodes auch auf den Tinys zu haben.
Der Tiny hat aber nunmal keinen Hardware-Multiplier, dadurch wird er ja
so billig. Was würde dir der Opcode ohne Hardware-Multiplier bringen?
Oder redest du von einer Software-Emulation des Befehls?
@Hagen Re
>Ich vermisse Shifts mit Angabe der Anzahl der Bits
das geht wohl mehr in richtung cisc architektur!
gruß pico
pico wrote: > - und das schlimmste, die assembler syntax (die namen der > bedingten rel. sprünge zb. breq -> "gehe frühstücken, wenn es > gleich ist", warum nicht jrz wie beim z? diese syntax ist wesentlich > verständlicher, weil sie sich direkt auf ein flag bezieht. In den meisten Architekturen gibt es keine direkte 1:1 Beziehung zwischen den bedingten Sprungbefehlen und den Flags. Viele Vergleiche mit Vorzeichen fallen darunter, weil darin teilweise bis zu 3 verschiedene Flags zueinander in Beziehung gesetzt werden (sowas wie S^V|Z). Und niemand hindert dich daran, die diversen Jxx Befehle per Macro zu implementieren. > warum ldi , lade register mit konstante und nicht mov, der compiller > sollte doch alleine zwichen einem register und einer konstanten > unterscheiden können? ....... Könnte man so machen. Allerdings neigt Atmel offenbar dazu, verschiedenen Maschinenbefehlen verschiedene Mnemonics angedeien zu lassen. Das hat auch ein bischen was mit CISC vs RISC zu tun. Bei CISCs ist es oft so, dass etliche unterschiedlich codierte Befehle den gleichen Namen haben, bei RISCs findet man öfter getrennte Namen für verschiedene Maschinenbefehle. Das Extrem davon wäre dann beispielsweise MAXQ2000. Da gibt's eigentlich nur noch einen einzigen Befehl, MOV. Der Rest ergibt sich aus diversen Seitenffekten der verwendeten Adressen.
pico wrote: > das geht wohl mehr in richtung cisc architektur! Als interne Microcode-Schleife realisiert passen sie nicht ins Konzept der AVRs. Und würde die Interrupt-Latenzzeit kräftig erhöhen. Barrel-Shifter hingegen sind bei RISCs genauso oft vertreten wie bei CISCs, sind aber erheblich aufwendiger und deshalb bei 8bit Controllern generell eher selten anzutreffen. Zumal der einzige wirklich sinnvolle Shifter bei AVR ein 16=>8 Shifter wäre, denn nur dann liesse sich der in C-Compilern wirklich nützlich anwenden.
@Andreas Kaiser >Und niemand hindert dich daran, die diversen Jxx Befehle per Macro zu >implementieren. meinst du eine *.inc datei mit sowas? .equ jrnz = brne ;jump relativ not zero .equ jrz = breq ;jump relativ zero . . . . . . gruß pico
4-Bit Shifter: SWAP Rd ANDI Rd,0xf0 ; Entspricht LSR Rd,4 Insgesamt 2 Taktzyklen SWAP Rd ANDI Rd, 0x0f ; Entspricht LSL Rd,4 Da diese Befehle sehr selten benötigt werden, wäre es bestimmt eine Verschwendung für solche Shifter eine Menge Transistoren zu verschwenden.
pico wrote: > meinst du eine *.inc datei mit sowas? > .equ jrnz = brne ;jump relativ not zero Wenn das so geht... Ich dachte eher an
1 | .macro jz |
2 | breq @1 |
3 | .endmacro |
aber wahrscheinlich geht auch
1 | #define jz breq
|
Ich hoffe doch, dass du mit dem Konzept von Macros in Assemblern vertraut bist.
@Andreas Kaiser
he cool
damit kann man sich ein assambly für avm schreiben, was wie z code
aussieht.
.macro jrz
breq @1
.endmacro
ldi r16, 0 ;einziger hinweiß auf einen avr
mov r17, r16
or r16, r17
jrz springe_immer
sieht doch gut aus ...
freude pico
ps die macro's sollten natürlich in einer include datei gekapselt
werden!
pico wrote:
> ich verdiene seit 83 mit µp / µc mein geld.
Willst du mir damit erzählen, dass du seit 1983 professionell in
Assembler programmierst, ohne jemals Macros begegnet zu sein? Respekt!
nein selbst mein erster assamber war ein macro-assambler gruß pico
back to the roots meime meinung zu avr (als einer der damit seine brötchen verdient) ich mag ihn! also keinesfalls unbeliebt. er hat wie alle µc's ecken und kanten aber wenn es um schnelle app's geht ist er spitze! pico
Hmmm, nichts gegen Dich, liebe(r) pico, aber nach 25 Jahren sollte man doch wenigstens wissen, wie man "Assembler" schreibt (v.a., dass es in dem Wort nur ein a gibt)... Oder läuft das nach dem Motto "Gestern wuste ich noch nich, wie mann Inschenör schraipt unt hoite bin ich einen...";-? SCNR...
ich kann's schreiben aber meine tastatur nach 3 bier nicht mehr.
pico wrote:
> ich kann's schreiben aber meine tastatur nach 3 bier nicht mehr.
Oha, Deine Tastatur trinkt Bier?
Bier & PC != gut; Am nächsten Tag kommt dann der Standardgedanke: ".. was hab' ich mir bloß dabei gedacht .." :-)
Thilo M. wrote:
> Bier & PC != gut;
Man kann sich beschwipst an den PC setzen und 10min an dem aktuellen
Projekt "arbeiten" (natürlich ohne vorher den aktuellen Stand zu
sichern).
Man kann dann den ganzen nächsten Tag benötigen, um alle gemachten
Fehler zu finden und wieder auszubauen.
Peter
Thilo M. wrote: > Bier & PC != gut; > > Am nächsten Tag kommt dann der Standardgedanke: ".. was hab' ich mir > bloß dabei gedacht .." > > :-) Naja, ich hab schon mal ne Flasche Bier über mein Notebook entleert (unabsichtlich, versteht sich...) und dabei Glück gehabt, dass nach einer gründlichen Reinigung der Tastatur alles wieder funktionierte. Seitdem bin ich auch ein wenig vorsichtiger mit der Kombination "Computer + Bier"...
Wir haben letztes Jahr über 30.000 verbaut, unsere Kunden noch viel mehr. Sind schon steile Teile. Was echt nervt sind Lieferzeiten, das wird immer anstrengender. Die Architektur ist topp (gibt es etwas vergleichbar schnelles im 8bit Bereich?). Was ich mir wünschen würde, wäre eine "Sync"-Möglichkeit im Sinne von "stehenbleiben, bis der Port sich ändert". Mit dem "Skip over Jump" hat man leider immer ein paar Taktzyklen Toleranz. Der Erfolg von Atmel lag damals darin begründet, daß sie mit kleinen Bausteinen (z.B. 1200) angefangen und von da aus nach oben gebaut haben. Heute starten sie mit full-featured Riesenchips, die Module teilweise halbfertig (man sehe sich nur mal die AVR32 Erratas an) und lassen die potentiellen Kunden jahrlang auf die kleinen Derivate warten...
so ganz nebenbei da ihr 30.000 Stück pro Jahr verbaut. Kann man solche Stückzahlen bei Atmel direkt beziehen oder verdient da immer ein Distributor mit?
LG Baut Millionen von LCD Fernsehern mit ATMega48, kommt halt drauf an für welche Anwendung.
In den Lego Mindstorms ist auch ein ATMega48 als Co-Prozessor verbaut: http://mindstorms.lego.com/Overview/NXTreme.aspx dann das Hardware Development Kit herunterladen, dot befinden sich die Schaltpläne.
> - die doppelt- oder dreifachbelegung der pin's Multiplexing kann man bei Controllern mit wenigen Pins und großem Funktionsumfang leider nicht verhindern. > - die teilweise kryptische bezeichnung der 'fuse bit's' Bei AVR muß ich mich auch ständig durch die Beschreibungen wühlen, um herauszufinden, was ich eigentlich setzen muß. Die Tatsache, daß es bei PonyProg dann auch noch invertiert ist, vereinfach die Sache nicht wirklich. Kann natürlich auch damit zu tun haben, daß ich mit PICs mehr Erfahrung habe als mit AVR. ["breq" vs "jrz"] Das eine Orientiert sich eher an den Mnemonics von Motorola und das andere an Intel. Ich denke mal, daß es hier wie bei little- und big-endian ist, wo einem das "natürlicher" vorkommt, was man als erstes kennengelernt hat. Ich persönlich bin beispielsweise mit den Motorola-Mnemonics vertrauter und muß bei den Intel-Gegenstücken meist erst überlegen, was gemeint ist. ["ldi" vs "mov"] Finde ich eigentlich gar nicht schlecht, da es klar macht, daß hier wirklich eine andere Instruktion mit anderer Codierung dahinter steckt. "mov" wäre natürlich möglich und wird von einigen RISC-Architekturen auch gemacht, kann aber auch fehleranfällig sein, wie hier jemand schon angemerkt hat. > Ich vermisse Shifts mit Angabe der Anzahl der Bits Ich glaube das habe ich hier im Thread auch schon mal bemängelt. Irgendwie kommen da Erinnerungen an den 8086 auf, der auch nur um eine Position shiften konnte. > das geht wohl mehr in richtung cisc architektur! Nicht unbedingt, da es über einen Barrel-Shifter durchaus in einem Taktzyklus machbar ist. > Barrel-Shifter hingegen sind bei RISCs genauso oft vertreten wie bei > CISCs, sind aber erheblich aufwendiger und deshalb bei 8bit Controllern > generell eher selten anzutreffen. Ich kenne mich jetzt zugegebenermaßen nicht mit der Implementierung eines Barrel-Shifters aus, aber der ARM2 hatte meines Wissens auch schon einen und dieser Prozessor hatte komplett gerade mal 8000 Transistoren.
Michael König wrote: > Irgendwie kommen da Erinnerungen an den 8086 auf, der auch nur um eine > Position shiften konnte. Über Shiftcount in CL ging auch mehr. Die interne Hardware konnte aber nur um eine Position, der Rest lief in Microcode ab. Womit man die Maschine schon man ein nettes Weilchen beschäftigen konnte. Und das geht zu Lasten der worst case interrupt latency, eine Zahl die sich die Hersteller von Controllern gerne gegenseitig um die Ohren hauen. > einen und dieser Prozessor hatte komplett gerade mal 8000 Transistoren. Ein 8x8 Multiplier ist auch kein Hexenwerk, trotzdem besitzt nur ein Teil der AVRs diese Unit.
Ich glaube nicht, dass Shift über mehrere Bits beim Achtbitter Sinn macht, da das Carry nur ein rausgeshiftetes Bit (als Übertrag für Rotation ins nächste Byte) auffangen kann. Ich hätte zwar gerne noch CPSNE (Gegenteil von CPSE) gehabt, und/oder T-Bit-Transfer mit dem I/O-Bereich, aber man kann nicht alles haben, der Befehlssatz ist endlich (es sind nunmal nur 16 Bit für Befehl incl. Parameter da). Zum ursprünglichen Thema kann ich (wie viele Andere auch) nicht beitragen, da ich kein "Profi" bin. ...
Michael König wrote: >> das geht wohl mehr in richtung cisc architektur! > > Nicht unbedingt, da es über einen Barrel-Shifter durchaus in einem > Taktzyklus machbar ist. > >> Barrel-Shifter hingegen sind bei RISCs genauso oft vertreten wie bei >> CISCs, sind aber erheblich aufwendiger und deshalb bei 8bit Controllern >> generell eher selten anzutreffen. > > Ich kenne mich jetzt zugegebenermaßen nicht mit der Implementierung > eines Barrel-Shifters aus, aber der ARM2 hatte meines Wissens auch schon > einen und dieser Prozessor hatte komplett gerade mal 8000 Transistoren. Man bräuchte doch 'nur' 8 Multiplexer (einen pro Ausgabebit) mit jeweils 7 Eingängen die jeweils mit jedem Bit außer dem 'eigenem' verbunden sind (Shift um die Position 0 mach keinen Sinn). Und je nach angelegter Auswahl am Multiplexer hätte man einen geeigneten Shift. Ich denke der meiste Teil der Chipfläche geht bei den größeren Modellen eh für Flash und SRAM drauf oder?
Malte __ wrote: > Man bräuchte doch 'nur' 8 Multiplexer (einen pro Ausgabebit) mit jeweils > 7 Eingängen die jeweils mit jedem Bit außer dem 'eigenem' verbunden sind Ein 8:8 Barrelshifter ist für Multibyte-Shifts ziemlich sinnfrei. Da es dank vorherrschender Programmierung in C recht oft um 16bit-Shifts geht, wäre nur ein 16:8 Barrelshifter wirklich sinnvoll. Ausserdem dürfte, so implementiert, die Fläche der Muxer selbst nicht der Punkt sein. Ich schätze dass dann der grösste Aufwand in der Verdrahtung draufgeht, zumal wenn dafür nur wenig Layer zur Verfügung stehen. Wird besser, wenn man das in mehreren Stufen macht.
Leute leute ... es is ein RISC und kein CISC... solchen "komplexen" funktionen wie ein Barrel werden anderwertig zusammengenudelt. und 8000 Transistoren glaub ich dir ned, weil selbst wenn es 8000 Gates wären das auf 0.35um ca. ~1.0mm² kommen
Laut Wikipedia hatte der ARM2 30000 Transistoren. Das sind ungefähr so viele wie bei 8086 und halb so viele wie 68000. Allerdings hatten 8086 und 68000 teils mehrere Microcode-ROMs, die wesentlich einfacher und kompakter strukturiert sind als synthetisierte random logic. Zum Vergleich: 8080 hatte 6000, Z80 bereits 13000 Transistoren.
Ein Barrel-Shifter passt meiner Meinung nach nicht gut in das AVR-Konzept: Wie Andreas Kaiser weiter oben gechrieben hat, ist ein Shift um mehrere Bits nur dann sinnvoll, wenn die aus dem Register herausgeshifteten Bits nicht verloren gehen, sondern in ein zweites Register hineingeshiftet werden. Nur damit können auch Shifts von 16- und 32-Bit-Variablen realisiert werden. Ein Barrel-Shifter ist im Vergleich zu Addition, logischen Bitmanipulationen deutlich komplexer, siehe http://en.wikipedia.org/wiki/Barrel_shifter Die Tinies können keine komplexen Operationen. Ich schätze, sie sind konsequent auf minimale Chipfläche getrimmt. In die Megas würde ein Barrel-Shifter eher passen, da hier bspw. auch ein Multiplizierer Platz findet. Allerdings würde ein Shift mit 16-Bit-Ergebnis architekturbedingt wahrscheinlich 2 Zyklen dauern, da zwei Ergebnisregister beschrieben werden müssen. Eine Multiplikation mit 2**n tut ähnliches in 3 Zyklen, wenn man den zusätzlichen Befehl zum Laden des zweiten Operanden berücksichtigt. Man würde also relativ viel Chipfläche investieren, um eine der seltener benötigten Operationen gerade mal einen Zyklus schneller zu machen. Der AVR-Befehlssatz ist in meinen Augen schon sehr durchdacht.
yalu wrote: > Allerdings würde ein Shift mit > 16-Bit-Ergebnis architekturbedingt wahrscheinlich 2 Zyklen dauern, da > zwei Ergebnisregister beschrieben werden müssen. Das läuft anders. 2 Register rein, eines raus. Ein kompletter 16bit Shift sähe dann ungefähr so aus: r16 = r17:r16 >> n r17 = r17 >> n (bzw. r1:r16 >> n, wenn r1=0) Den manchmal vermissten Rotate ohne Carry gibt's dann gratis, mit r18 = r18:r18 >> 1
> Das läuft anders. 2 Register rein, eines raus. Stimmt, so herum ist es natürlich gechickter. Trotzdem bleibt die Frage: Wie oft braucht man einen Shift um mehrere Stellen? In meinen AVR-Programmen kommt so etwas äußerst selten vor. Bei Controllern mit größerer Wortbreite schon häufiger, bspw. wenn sich bei 16- oder 32-Bit-IO-Registern eine Gruppe von Bits, die zusammen eine Zahl darstellen, in der Mitte des Registers befindet. Aber bei 8-Bit-IO-Registern geht dies auch mit ein paar LSL und SWAP ausreichend schnell.
yalu wrote: > Trotzdem bleibt die Frage: Wie oft braucht man einen Shift um mehrere > Stellen? Beispielsweise wenn man CAN IDs als 29-Bit Werte an Funktionen übergibt, und sie dort wild zerpflücken und auf die diversen Register eines MCP2515 verteilen darf. Und umgekehrt.
> Beispielsweise wenn man CAN IDs als 29-Bit Werte an Funktionen übergibt, > und sie dort wild zerpflücken und auf die diversen Register eines > MCP2515 verteilen darf. Und umgekehrt. Anstelle von N-bit-Shifts würde da auch z.B. ein Befehl Sinn machen, der die oberen 4 Bits des Source-Registers in den unteren 4 Bits des Zielregisters speichert. Dann erledigt man 8-Bit und Vielfache durch uminterpretieren der Register (kostenlos), 4 Bits mit einem Befehl, und die restlichen max. 2 Bits durch 1-Bit Shifts. Ohne 4-Bit-Shift kommst du so auf max. 4 einbit-Shifts (jeweils max. 2 Befehle um Bit durch das Carry "rüberzuschieben"). Bleibt die Frage, wieviele CAN IDs du so pro Sekunde verarbeiten willst, dass diese (im schimmsten Fall) 8 Befehle pro ID so ins Gewicht fallen. Da war der Hintergedanke dann sicher, dass man für diesen (eher seltenen) Fall halt einen anderen Controller nimmt.
Leider hat da Microchip nicht nach dem Bosch gearbeitet und einige Eigenerfindungen gemacht. Die ID-Register vom Atmel sind 1:1 vom Bosch übernommen. Und da die Geschwindigkeit vom CAN um etliches langsamer ist als die Geschwindigkeit vom AVR bleibt genügend Zeit die ID umzurechnen und weiter zu verarbeiten. Das Andere ist, das man solche Dinge dem C-Compiler überlässt, denn wer schreibt 32k Maschinencode in Assembler? Assembler benutzt man doch nur noch bei ganz kleinen Aufgaben oder wo es nicht anders möglich ist wird nur ein kleiner Teil (<5%) in Assembler geschrieben.
Nur die Ruhe, ich beklage mich doch garnicht. Da war bloss die Frage im Raum, wozu man grössere Shifts brauchen kann. Ich habe kein Problem damit, wenn auf AVRs dann eine Schleife draus wird. Und ich bin nicht verrückt genug, sowas in Assembler zu programmieren.
So einen 4-bit Shifter wie oben mittels SWAP beschrieben funktioniert doch auch ganz gut Beitrag "Re: Atmel ist unter "Profis" nicht gerade beliebt - Warum?" und den Rest mit normalen 1-bit Shifts
> Laut Wikipedia hatte der ARM2 30000 Transistoren.
Ich werde doch nicht etwa die Anzahl der Transistoren und die Taktrate
(8MHz) durcheinandergeworfen haben? Muß ich mal zu Hause bei Furber
nachschlagen...
@Andreas Kaiser >Und niemand hindert dich daran, die diversen Jxx Befehle per Macro zu >implementieren. >meinst du eine *.inc datei mit sowas? >.equ jrnz = brne ;jump relativ not zero >.equ jrz = breq ;jump relativ zero >. >. >gruß pico .equ add = 2 ; 'add' is a keyword (instruction) .def r1 = r16 ; 'r1' is a keyword (register) .def r0 = r31 ; 'r0' is a keyword (register) .def r16 = r24 ; 'r16' is a keyword (register) .def add = r2 ; 'add' is a keyword - again (instruction) .def mov = r29 ; 'mov' is a keyword (instruction) hey gefunden in der help für avr studio assembler2 ps: ret 6 fehlt mir immer noch, auch wenn ich daten und rückkehradressen auf dem stack (2 getrennte) trenne bedeutes einen einen nicht unerheblichen tacktaufwand ; bitte, bitte, sowas in si pico
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.