Hallo zusammen,
ich suche im Raum Braunschweig findige Köpfe, die mir bei Assembler für
Atmel weiterhelfen können oder generell Erfahrungen in dem Bereich
austauschen mögen. Ich lese mich gerade in das Thema ein und suche
Hilfen, Inspirationen und eventuell auch Lösungsansätze für ein Projekt.
Martin Kreiner schrieb:> Was zahlst du denn?
Wenn schon so gefragt wird:
Für komplett fertigen, funktionierenden und komplett verständlich
dokumentierten/kommentierten Sourcecode nach Vorgaben des Projektes wäre
ich durchaus bereit über einen Stundenlohn zu diskutieren.
Die Vorgaben des Projektes gibt es bei ernstgemeinten Anfragen.
Die Vorgabe Assembler ist schon sehr erstaunlich.
In der Regel kann ein erfahrener C-Programmierer (beinahe) alles ohne
Assembler lösen.
Den höheren Stundensatz gleicht die durch C eingesparte Zeit bei weitem
aus.
Es soll sonst auch noch diese kaskadierbaren Kompressoren geben. Das
bedeutet jede Stufe soll Faktor 16 oder irgenwas machen. Dh wenn man den
Code vor der Ausfuehrung erst ein paar Mal entpacken muss, kann man
moeglicherweise auch einen kleineren Controller verwenden. Auf Kosten
der Ausfuehrungszeit dann...
:-)
Siebzehn und Fuenfzehn schrieb:> Erst mal : weshalb ASM?> Hohe Stueckzahlen, und deshalb muss das Navigationssystem plus Karte in> einen Tiny rein ?
Assembler ist gewünscht, da ich mir einbilde darüber am meisten die
Arbeitsweise im Mikrocontroler verstehen zu können, man möge mich
korrigieren, wenn ich falsch liege.
Stückzahlen sollen nur wenige sein. Hauptsächlich für mich und
vielleicht noch für interessierte Freunde, nichts großartig
kommerzielles.
Ich habe hier einen (teilweise kompletten) Test-Aufbau mit einem
ATMEGA8, und ich denke in die Richtung des ATMEGA8 wird es auch gehen.
Zumindest sagt mir der schon von den Funktionen und I/O-Ports her zu.
Ich werde mal nachher genauer formulieren wie die Anforderungen an die
Schaltung und den Mikrocontroller sind.
T. E. schrieb:> Assembler ist gewünscht, da ich mir einbilde darüber am meisten die> Arbeitsweise im Mikrocontroler verstehen zu können, man möge mich> korrigieren, wenn ich falsch liege.
Als Anfänger läufst du Gefahr, vor lauter Bäumen den Wald nicht zu sehen
und das eigentliche Problem - die Anwendung - aus den Augen zu
verlieren.
T. E. schrieb:> Assembler ist gewünscht, da ich mir einbilde darüber am meisten die> Arbeitsweise im Mikrocontroler verstehen zu können, man möge mich> korrigieren, wenn ich falsch liege.
Was ein Quatsch.
wenn du den µC verstehen willst, lies das Datenblatt und implementier
den Mist selbst, anstatt jemanden dafür zu bezahlen, dass er dir dein
Projekt umsetzt.
In C ist man nah genug am Controller dran, um zu verstehen was er macht.
Abgesehen davon wirst du dir es kaum leisten können jemanden auf
(vernünftiger) Stundenlohnbasis für ein Privatprojekt zu beauftragen.
Vlad Tepesch schrieb:> [...]anstatt jemanden dafür zu bezahlen, dass er dir dein> Projekt umsetzt.> In C ist man nah genug am Controller dran, um zu verstehen was er macht.>>> Abgesehen davon wirst du dir es kaum leisten können jemanden auf> (vernünftiger) Stundenlohnbasis für ein Privatprojekt zu beauftragen.
Das war auch ungefähr so ernst gemeint, wie ich den entsprechenden
Vorposter genommen habe. Natürlich ist es mir lieber das selber zu
schreiben.
Uhu Uhuhu schrieb:> Als Anfänger läufst du Gefahr, vor lauter Bäumen den Wald nicht zu sehen> und das eigentliche Problem - die Anwendung - aus den Augen zu> verlieren.
Das klingt nach einem berechtigten Einwand. In Assembler einlesen ist
derzeit tatsächlich noch sehr mühsam.
T. E. schrieb:> In Assembler einlesen ist> derzeit tatsächlich noch sehr mühsam.
Wirst du trotzdem nicht umhin kommen. Es ist bei einer Plattform
wie diese kleinen Controller mehr als sinnvoll, dass man den
Assemblercode zumindest lesen kann um im Zweifelsfalle zu
verstehen, was der Compiler da gebaut hat. Allerdings ist es wie
mit natürlichen Fremdsprachen: etwas notdürftig zu verstehen
bedeutet eben noch lange nicht, dass man es auch selbst formulieren
kann. Das müsstest du aber bei einer Programmierung in Assembler
tun können.
So ein Compiler nimmt die vor allem algorithmisch viele Fratzenfallen
ab, in die du sonst reintappen kannst. Das fängt beim simplen Test
der Flagbits an („welche Flags muss ich prüfen, wenn ich jetzt a
kleiner/gleich b testen will?“). Auch ist es fürs Debuggen hilfreich,
wenn man schon mal fertige Routinen hat, um Zahlen zu formatieren,
ganz zu schweigen von „mal schnell ein printf()“ nutzen zu können.
Damit sind wir auch schon bei der Plattform: nimm dir lieber etwas mit
mehr Flash + RAM, das spart Stress beim Debuggen. Wenn du statt des
ATmega8 in die ATmega88-Familie guckst (pinkompatibel und funktions-
mäßig aufwärtskompatibel), dann kannst du bis zu einem ATmega328
gehen. Wenn deine Applikation dann erstmal debuggt ist, kannst du
für das endgültige System immer noch auf ATmega88 runtergehen und
must nichts weiter tun, als einmal neu zu compilieren, damit der
Code 1:1 dort läuft.
>Ich habe hier einen (teilweise kompletten) Test-Aufbau mit einemATMEGA8, und ich denke in die Richtung des ATMEGA8 wird es auch gehen.
Zumindest sagt mir der schon von den Funktionen und I/O-Ports her zu.
Sowas Duemmliches. Was sollen die paar gesparen Cent denn bringen? Nimm
was Groesseres. Unter einem 32k Flash macht keiner einen Sinn. Ein
TQFP44 ist ja immer noch schnuckelig.
Siebzehn und Fuenfzehn schrieb:> Unter einem 32k Flash macht keiner einen Sinn.
Als ATmega328 bekommt er den sogar noch pinkompatibel zu seinem
ATmega8.
Siebzehn und Fuenfzehn schrieb:> Unter einem 32k Flash macht keiner einen Sinn.
Was soll das?
Nicht jeder will immer alles mit Ethernet, USB, Webserver, GLCD, Touch
und son Schnickschnack programmieren.
Mit nem Text-LCD oder 7-Segment LEDs kommt man meilenweit mit 8kB.
Und man schafft es selber und muß nicht versuchen, haufenweise fremde
Libs zusammen zu pappen.
