mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wer zu tief gräbt, muss zahlen


Autor: Christian Meurer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo liebe Leute,

zunächst mal muss ich sagen, dass ich mit dem PIC sehr gerne arbeite, 
was durchaus Gewohnheit ist, weil ich schon sehr lange mit ihm arbeite. 
Natürlich auch wegen der Bastler-freundlichen Bauformen (DIL).
Nun will ich für ein kleines Projekt Anschluß an den USB. Daher habe ich 
mir den 18C445x gewählt. Schaltung ist soweit fertig, allerdings will 
ich keinen Treiber für Windows programmieren, somit will ich die 
RS232-Emulation mit der CDC-Firmware von Microchip nutzen. Soweit so 
gut. Leider gibt es CDC aber nur im C-Code, Assembler wäre mir lieber. 
Nun gut, also schaue ich nach dem C-Compiler und was sehe ich da: den 
soll ich bezahlen oder als Krüppelware für 60 Tage testen? Nun habe ich 
schon in Programmer und zahlreiche PICs investiert und meinen 
PIC-Programmer (älterer Bauart) umgerüstet, damit dieser 18C445x brennen 
kann und damit ich nun damit arbeiten kann soll ich nun nochmal in die 
Tasche greifen, für eine Software, die ich eigentlich gar nicht will?

Dann wäre es in meinen Augen schon ehrlicher, wenn man für die 
USB-Software direkt zur Kasse gebeten würde und nicht so "hinten herum". 
Das würde mir zwar nicht gefallen, könnte ich aber verstehen. So jedoch 
ist es Beutelschneiderei.

Schöne Grüße und Schöne Pfingsten an alle,

Christian

Autor: Feadi F. (feadi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kenne jetzt die Microchip Firmware nicht. Aber wenn die nicht zu 
groß ist, übersetz den C-Code doch von Hand nach Assembler.

Autor: Christian Meurer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

recht klein ist die Firmware nicht, ca 5KB Maschinencode, da sitzt man 
schon ne Weile dran. Vielleicht hat jemand schon Erfahrung darin, mit 
der 60-Tage-Version des C-Cpompilers - den ich auf keinen Fall kaufe ;-) 
- den USB-Source in Assembler zu übersetzen. Dann bräuchte ich den 
Comipler anschließend nicht mehr und könnte mit Assembler 
weiterentwickeln.

Gruß
Christian.

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Leider gibt es CDC aber nur im C-Code, Assembler wäre mir lieber.

CDC in Assembler? Meinst du das ernst?

> Nun gut, also schaue ich nach dem C-Compiler und was sehe ich da:
> den soll ich bezahlen oder als Krüppelware für 60 Tage testen?

Richtig, dannach mußt du bezahlen, wenn du die volle Funktionalität 
weiter haben möchtest. Verständlich, Microchip ist ja kein 
Wohlfahrtsunternehmen. Allerdings wird der COmpiler nach 60 Tagen nicht 
unbrauchbar, es werden lediglich einige Optimierungsalgorithmen 
deaktiviert. Das ist nicht tragisch, dass Projekt lässt sich dnnoch 
kompilieren und benutzen. Probier's einfach mal aus.

Autor: Christian Meurer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jupp,

leider hast Du mich falschg verstanden. Es geht nicht darum NICH zu 
bezahlen, sondern die Art, wie. Hätte man für den CDC eine Obulus 
verlangt wäre das absolut einsichtig. Aber zunächst den Source kostenlos 
um dann den Compiler verkaufen zu können, ich habe Zweifel ob das so 
richtig ist.

Ich würde gern in Assembler programmieren, da ich hierbei gut die 
Laufzeiten abschätzen kann und ich darin auch schon Erfahrung habe.

Schöne Grüße

Christian

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was wäre denn für dich einen Obulus?

Ich völlig anderer Meinung.

Der CDC-Code ist frei verfügbar => sehr schön

Der Compiler ist für Privatpersonen/Studenten ebenfalls quasi kostenlos. 
Microchip gestattet die Nutzung auch nach den 60 Tagen und die genannten 
Optimierungen sind nicht zwingend notwendig.

Naja und für Firmen sind die 500$ für den Compiler eher Nebensache.

Ist doch nicht schlecht. Jeder hat somit die Möglichkeit, den Code als 
auch den Compiler kostenlos zu testet. Wäre doch Gülle, wenn ich "einen 
kleinen Obulus" (womoglich noch per PayPal LOL) bezahle und dann 
feststelle, dass irgendwas nicht so passt wie ich mir das vorstelle.

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach ja,

dir auch schöne Grüße :)

Autor: Uhu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guck doch mal, ob der Compiler eine Option hat, mit der der 
Assemblercode ausgegeben wird.

Den kannst Du Dir dann an den Assembler anpassen und auf den C-Compiler 
in Zukunft pfeifen...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Meurer wrote:

> Dann wäre es in meinen Augen schon ehrlicher, wenn man für die
> USB-Software direkt zur Kasse gebeten würde und nicht so "hinten herum".

Fragt dochmal, ob Du für den Quellcode noch extra was bezahlen darfst.


> Das würde mir zwar nicht gefallen, könnte ich aber verstehen. So jedoch
> ist es Beutelschneiderei.

Daran ist überhaupt nichts Beutelschneiderei !

Daß es manche Software als Freeware gibt, heißt noch lange nicht, daß 
sie Dir alles umsonst in den Hintern schieben müssen.

Compilerbauer müssen auch ihre Familien ernähren !

Wenn Dir soviel daran liegt, nimm doch nen Freeware-Compiler.
Ich benutze z.B. den 8051 und den AVR und dafür gibt es auch Freeware 
Compiler (SDCC, WINAVR).


Es ist normal, daß ab einer bestimmten Codegröße die Quellen in C 
geschrieben werden.
Z.B. beim 8051 mache ich Assembler bis höchstens 2kB. Darüber verliert 
man einfach den Überblick und die Wartbarkeit und Erweiterbarkeit sinkt 
gegen 0.
Ich hatte zu Anfang mal 8kB in Assembler geschrieben. Nach 2 Jahren habe 
ichs komplett weggeschmissen, da ich nicht die Bohne mehr durchsah.


Peter

Autor: Christian Meurer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jupp,

mir wäre ja geholfen, wenn ich einen geeigneten Weg finde, den C-Source 
in Assembler zu übersetzen. Ich will mich eigentlich gar nicht in C 
einarbeiten, zumindest nicht für meine Mikrocontroller-Aufgaben. 
Assembler für den PIC ist mir bereits vertraut und wäre genau was ich 
mir wünsche.

Ich habe auch schon überlegt, die Custom-USB-Firmware zu benutzen. 
Allerdings hat das 2 entscheidende Nachteile für mich:
)ich muss mich komplett in die USB-Spec einarbeiten
und noch viel schlimmer
)ich muss einen Windows Treiber schreiben.

daher ist CDC (RS232 Emu) wahrscheinlich die beste Lösung, auch wenn das 
vom User verlangt, dass er einen COM-Port wählt. Nur ist das leider 
nicht in Assembler verfügbar.

Aber ich bin mir sicher, irgendwie geht das... ;-)

Gruß

Christian

Autor: Beurteiler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Handykaps deiner seits:
1. Gebrauchst du PIC
2. Kannst und willst du kein C
3. Bist du nicht bereit was zu investieren aber forderst wieder mal 
alles.
4. CDC in Assembler ist SICHER nicht ein sinnvoller Weg.

Autor: Christian Meurer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

8kB ist natürlich auch schon ein ganz großes Ding, für meine Zwecke komm 
ich mit weit weniger aus. So ein µP-Crack wie Du bin ich sicher nicht.

Schöne Grüße

Christian

Autor: Jupp (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>mir wäre ja geholfen, wenn ich einen geeigneten Weg finde, den
>C-Source in Assembler zu übersetzen.

Der Compiler kann definitiv ein Assemblerlisting erzeugen, ich hab dir 
im Anhang mal eins hochgeladen. Mußt du entscheiden, ob du damit was 
anfangen kannst.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Meurer wrote:

> 8kB ist natürlich auch schon ein ganz großes Ding, für meine Zwecke komm
> ich mit weit weniger aus. So ein µP-Crack wie Du bin ich sicher nicht.

Das hat nichts damit zu tun, ob man ein µP-Crack ist, sondern mit dem 
Umfang der Aufgaben, die man dem MC zu erledigen gibt.

Ich hab auch viele AT89C2051 und ATtiny26 im Einsatz und die älteren 
Projekte darauf sind noch in Assembler.

Natürlich ist man mit zunehmender Erfahrung besser in der Lage, einen 
einzigen MC besser auszulasten und ihm mehr Aufgaben aufzubürden.


Peter

Autor: Christian Meurer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke an Jupp,

ich werde mir wohl oder übel den Compiler installieren und versuchen in 
eine Lage zu kommen, die Schnittstelle des CDC von Assembler aus zu 
nutzen. Ich habe gesehen, dass der Compiler auch Objekt-Files erzeugen 
kann, die mit MPLINK weiterverarbeitet werden können, so müsste ich doch 
weiter kommen, denke ich. Oder?

Gruß

Christian

Autor: Kai F. (k-ozz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso nimmst du nicht einfach einen PIC ohne USB und klebst draußen noch 
einen FT232 dran. Der Treiber ist schon vorhanden und vom Controller aus 
ist es nur eine normale UART-Schnittstelle. Der FTDI ist mit 5 Euro 
wesentlich billiger als der C-Compiler und den zusätzliche Aufwand, den 
du in die Übersetzung des C-Codes in Assembler stecken müsstest kannst 
du dir auch sparen.

Autor: Uhu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So sonderlich ernst scheints Dir ja nicht zu sein, sonst wärst Du längst 
auf die durchaus brauchbaren Vorschläge eingegangen, die gemacht wurden. 
Also nur klagen auf hohem Niveau?

Autor: Christian Meurer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Kai,

wäre eine denkbare Alternative, wenn alle Stricke reißen. Allerdings 
müsste ich die Schaltung dann wieder aufreißen. Ich war ja so 
optimistisch und hab schon auf PIC mit USB layoutet.
...und irgenwie geht es ich weiss es, auch ohne C   ;-)

Gruß

Autor: Christian Meurer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Uhu,

leider verstehe ich nicht was Du meinst. Oder gibst Du immer direkt auf, 
wenn was nicht klappt?

Gruß
Christian

PS. solche Kommentare erscheinenmir sinnlos, oder?

Autor: Uhu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also nochmal - wie Jupp und ich bereits geschrieben haben:

Laß Dir den Assembleroutput des Programmes vom Compiler erzeugen und 
protiere den auf Deinen Assembler.

Dann hast Du, was Du so sehr beklagst...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu wrote:

> Laß Dir den Assembleroutput des Programmes vom Compiler erzeugen und
> protiere den auf Deinen Assembler.

Ob man damit glücklich wird ?

In der Regel erzeugen Compiler nicht lokalisierten Code, d.h. die Code 
und SRAM-Adressen löst erst der Linker auf.

Assemblerprogrammierer schreiben aber meist festen Code und das geht 
dann schief, beides zu kombinieren.

Außerdem muß man sich noch mit den C-Internas auseinandersetzen. also 
wie welche Funktionen ihre Parameter organisieren (Byteorder) und 
übergeben (Register, Stack oder SRAM).


Ich habe mich daher vor dem Aufwand gescheut und entweder C oder 
Assembler geschrieben bzw. nur einzelne Zeilen Inline-Assembler.


Peter

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich habe mich daher vor dem Aufwand gescheut und entweder C oder
> Assembler geschrieben

Also ist C doch ein paar Nummern komplexer, als hier immer behauptet 
wird?

Ich scheue mich nämlich auch vor C, allerdings auf AVR. Ist mir einfach 
zu kryptisch.

Ich kann auch Christians Unmut gut nachvollziehen, ich wehre mich 
schließlich auch dagen, den GCC zu installieren, denn in ASM weiß ich 
inzwischen, was ich mache (auch dank Deiner Hinweise, Peter), in C 
müsste ich Lotto spielen, dazu habe ich weder Lust noch Nerven.

...

Autor: Rahul Der trollige (rahul)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Also ist C doch ein paar Nummern komplexer, als hier immer behauptet
>wird?

Das kann man nicht ganz so pauschal sagen: Es liegt wohl eher an der 
komplexen Struktur eines PIC - beim AVR kann man viele Sachen von C 
quasi direkt in Assembler übersetzen. Grundlagen benenötigt man aber 
schon (auf beiden Programmierseiten).
Ich würde aber sagen, dass Hannes auch ein C-Programm verstehen können 
sollte, wenn er die C-Bibel* zur Hand hat.
In C zu Programmieren sollte dank des Tutoriums auch möglich sein... ;-)

*Kernighan und Ritchie, "Die Programmiersprache C", in Deutsch ab der 2. 
Auflage als gute Übersetzung "anerkannt". Die vorherige ist was zur 
Belustigung...

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ist mir einfach zu kryptisch.

LOL was bitte ist an C kryptisch???

Autor: Thomas S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
/funein
Echte Progammierer programmieren nur in Assembler :o)))
/funaus

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jupp wrote:
>> Ist mir einfach zu kryptisch.
>
> LOL was bitte ist an C kryptisch???

Das hilft zwar dem Threadstarter nicht weiter, aber:

Ich programmiere keine anderen Controller als AVRs. Meine Programme sind 
vom Umfang her recht überschaubar und enthalten keine komplizierten 
Rechnereien, sind also eher "Bitschubserei". Die Programme laufen ja 
beim AVR direkt an der Hardware, also ohne OS.

Unter diesen Randbedingungen empfinde ich AVR-Assembler als sehr 
eindeutig und logisch. Der AVR macht exakt das, was ich ihm programmiert 
habe, da pfuscht mir kein Compiler dazwischen, da habe ich volle 
Kontrolle über jedes Bit und Byte. Alle benötigten Informationen sind im 
Datenblatt zu finden und sind recht eindeutig.

In einer Hochsprache wird sehr stark abstrahiert. Es wird mir zwar viel 
Arbeit abgenommen, aber damit auch der Blick auf's Detail. Da ich beim 
AVR aber am Detail (an der Hardware) programmiere, möchte ich darauf 
nicht verzichten. ASM ist eindeutig, bei einer Hochsprache lauert 
überall ein "ja, aber". In ASM fühle ich mich halbwegs sicher, in einer 
Hochsprache fühle ich mich verarscht, es gibt zu viele "Nebenwirkungen".

Um das gleiche, was ich in ASM mache, in einer Hochsprache machen zu 
können, müsste ich diese Hochsprache schon verdammt gut beherrschen. Und 
das ist mir einfach zuviel Aufwand, mit Sprachen lernen tu ich mich sehr 
schwer. Das ist halt nicht jedermanns Sache.

Jupp, es steht Dir aber frei, mich auszulachen, weil mir (mir 
persönlich) C zu kryptisch ist. Ich habe damit kein Problem.

...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hannes Lux wrote:
>> Ich habe mich daher vor dem Aufwand gescheut und entweder C oder
>> Assembler geschrieben
>
> Also ist C doch ein paar Nummern komplexer, als hier immer behauptet
> wird?


Du hast mich völlig falsch verstanden.

Ich habe mich nur davor gescheut, beides zu vermanschen.

Ich mache jetzt fast nur noch C, geht einfach viel schneller zu 
schreiben.


> in C
> müsste ich Lotto spielen, dazu habe ich weder Lust noch Nerven.

Wie kommst Du bloß darauf ?
Ich kenne keinen C-Programmierer, der sich als Lottospieler ansieht.

Als Assemblerfreak ist es auch kein Problem, sich zu Anfang den Output 
anzusehen, ob man es in C richtig gemacht hat.
Allerdings sollte man erstmal aufm PC die C-Grundlagen ausprobiert 
haben, geht mit dem Debugger doch viel einfacher, als aufm MC.


Peter

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Jupp, es steht Dir aber frei, mich auszulachen, weil mir (mir
>persönlich) C zu kryptisch ist.

Nein, ich möchte dich doch nicht auslachen, jeder hat halt andere 
Vorlieben.

Ich hab auch mit Assembler angefangen und zwar deshalb, weil die ersten 
µCs, mit denen ich zu tun hatten, einfach noch keinen nennenswerten SRAM 
hatten und es auch gar keine freien C-Compiler gab. AT90S1200 und 
PIC16C(F)84 sei hier als Beispiel genannt. Aber mitlerweile sind die 
ATtinys und ATmegas so günstig und leistungsfähig und die Compiler 
wirklich brauchbar, dass ich auf Assembler getrost verzichten kann.

Wenn ich mir vorstelle, CDC oder gar HID in Assembler zu 
programmieren...nein Danke. Dann mache ich es lieber in C und bin 
dreimal so schnell fertig und kann die restliche Freizeit genießen.

Ich meine, es gibt auch Leute, die ganze Textverarbeitungen für Windows 
in Assembler schreiben. Schön, wenn jemand nichts anderes zu tun hat?!?

Autor: Uhu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lieber Hannes,

wer hat Dir denn diese Schauergeschichten über C erzählt?

> In einer Hochsprache wird sehr stark abstrahiert.

Das mag für C++ gelten, aber keineswegs für C.

Ich arbeite seit Anfang der 80er mit C und meine Meinung darüber ist bis 
heute unverändert:

          C ist ein Highlevel-Assembler

Mit etwas Erfahrung weiß man recht genau, welchen Maschinencode der 
Compiler erzeugen wird - und daß der Compiler die ganzen Futzelarbeiten 
deutlich zuverlässiger und schneller ausführt, als der versierteste 
Assembler-Fuchs.

Wenn man sich sehr gut in Assembler auskennt, ist die Lernkurve sehr 
steil; wenn man C-Programme mit einem kombinierten Quelltext- und 
Maschinencode-Debugger ablaufen läßt, gehts sogar noch schneller.

Und die Parameterübergabekonventionen sind so einfach, daß man selbst im 
Frühstadium von Alzheimer damit zurecht kommen sollte, wenn man vorher 
kräftig Assembler geübt hat ;-)

@Peter:
> In der Regel erzeugen Compiler nicht lokalisierten Code, d.h. die
> Code und SRAM-Adressen löst erst der Linker auf.

Na ja, das ist aber ein komische Assembler-Stil, bei dem der 
Programmierer die Speicheradressen von Hand vergibt - einen Assembler 
braucht man dafür eigentlich nicht - ein Hex-Editor reicht da voll und 
ganz.

Tatsache ist, daß größere Assembler-Programme üblicherweise aus mehreren 
Quelltext-Modulen zusammengesetzt werden und der Linker macht genau das, 
was er immer macht: Er wandelt die symbolischen Adressen in absolute um.

Ob dabei ein Modul, den der Linker in das ausführbare Programm einbaut, 
aus dem Assembler kam, oder aus einem C- oder C++ - Compiler, ist völlig 
gleichgültig, so lange die Schnittstellen richtig gehandhabt werden.

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Assembler ist ok solange du kleine überschaubare Programme hast, und nur 
einen Typ µC verwendest.

Sobald du eine Codegröße von etwas 2 Kb überschreitest wird es sehr 
schnell sehr unübersichtlich.

C-Code ist übersichtlicher , und wenn du dich etwas damit beschäftigt 
hast WIE du etwas in C programmierst, kommt da ein asemmblercode raus 
der deinem von HAND programmierten in nichts nachsteht.

Wechselst du den µC, sogar innnerhlab einer µC Familie, musst du die 
Assemblerprogramme von Hand anpacken und Adressierungen, Sprünge, 
Befehle,.... anpassen.

Schreibst du in C, tauschst du für eine andern µC die Headerdatei mit 
den Adressen(ROM, RAM Start und Endadresse, IRQ Vektor, 
Registeradressen) und die Compilesettings aus, lässt neu compilieren und 
fertig.

In C musst du dich um die Speicherverwaltung nicht kümmern. Das heiß wo 
eine Variable im Ram steht, wie die Zugriffe darauf erfolgen macht der 
Compiler, du kannst dich um die Programmlogik kümmern.

Christian:

Du solltest dich mal mit C beschäftigen, nur auf Assembler zu setzen ist 
doch sehr einseitig.
Und es gibt auch freie C-Comiler die für den PIC genutzt werden könnene.
zb.: SDCC

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu wrote:

> @Peter:
>> In der Regel erzeugen Compiler nicht lokalisierten Code, d.h. die
>> Code und SRAM-Adressen löst erst der Linker auf.
>
> Na ja, das ist aber ein komische Assembler-Stil, bei dem der
> Programmierer die Speicheradressen von Hand vergibt

Das ist der übliche Stil, wie es MC-Anfänger machen.
Ich hab im Internet noch nie was anderes gesehen.


> - einen Assembler
> braucht man dafür eigentlich nicht - ein Hex-Editor reicht da voll und
> ganz.

Das ist doch nicht Dein Ernst. Hast Du alle Codes im Kopf und rechnest 
Sprünge und Calls selber aus ?


> Tatsache ist, daß größere Assembler-Programme üblicherweise aus mehreren
> Quelltext-Modulen zusammengesetzt werden und der Linker macht genau das,
> was er immer macht: Er wandelt die symbolischen Adressen in absolute um.

Tatsache ist, daß ich größere Programme grundsätzlich komplett in C 
schreibe.
Ich bin allerdings nur ein Hobby-Programmierer, der hauptsächlich 
Hardware entwickelt, wo auch mal MCs drin sind.


> Ob dabei ein Modul, den der Linker in das ausführbare Programm einbaut,
> aus dem Assembler kam, oder aus einem C- oder C++ - Compiler, ist völlig
> gleichgültig, so lange die Schnittstellen richtig gehandhabt werden.

Sehr schön ist das beim Keil C51, wo die Schnittstellen je nach 
Memory-Modell und Compiler-Optionen unterschiedlich sind.
Ne, geh mir weg, dazu ist mir meine Zeit einfach zu schade, sie mit 
solchem Unsinn zu verplempern.
Auch kann der C51 dann keine objektübergreifende Registeroptimierung 
mehr durchführen.

Wenn C, dann einfach alles in C und gut is.


Peter

Autor: Uhu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian:

Ich denke, die beste Lösung wäre der fertige 5€-Chip mit verfügbaren 
Windows-Treibern - zumindest, wenn Du keine Serienproduktion anfangen 
willst.

Die zweitbeste Lösung wäre, den vom C-Compiler erzeugten Modul in Dein 
Assembler-Programm einzubinden - inclusive der C-Runtime-Bibliothek.

Wie man die Funktionen aus dem Modul aufruft kann man auf verschiedenen 
Wegen herausfinden:

Anaphabeten schreiben ein kleines C-Programm, das nur die Aufrufe 
enthält und sehen sich an, was der Compiler daraus macht und äffen das 
dann in ihrem Asm-Programm nach, während

Cegastheniker ins Compilerhandbuch gucken und nach dem Kapitel über die 
Parameterübergabekonventionen suchen.


Das mit dem PC-Treiber selber schreiben, schlag Dir mal aus dem Kopf; 
das überstiege die Komplexität Deines gesamten bisherigen Lebenswerkes 
um Größenordungen.

Autor: Feadi F. (feadi)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> /funein
> Echte Progammierer programmieren nur in Assembler :o)))

Neeeee....

Echte Programmierer programmieren Binär!

> /funaus

Autor: Christian Meurer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

zunächst mal muss ich mich bei UHU entschuldigen, die weiteren 
Kommentare von Dir waren sehr gut und versiert.

Ich will kurz erklären, was mich dazu veranlasst, lieber in Assembler zu 
programmieren.
Es ist tatsächlich so, dass ich ein wenig C-Erfahrung habe, aber auf 
anderen Prozessoren, sprich x86 mit WIN-API. Allerdings sind meine 
µP-Programme immer recht klein gewesen, also ich glaube mein größtes 
Programm war 4kB. Meistens bewege ich mich aber unterhalb von 2kB. Ich 
scheue mich einfach davor C für PIC zu lernen, wo ich mich doch in 
Assembler recht sicher fühle und ich auch bisher nur selten etwas 
portieren musste.

Den C-Compiler hätte ich zur Not auch gekauft, allerdings habe ich den 
Eindruck, dass ich mit dem Preis von ca. 600€ pro Lizenz eher die 
komplette MPLAB-IDE sponsore, die ja frei verfügbar ist. Ich werde den 
nämlich sicher länger als 60 Tage verwenden wollen ( das ist die Zeit, 
die die Demo-Version lauffähig ist). Und ... sich selbst zerstörende 
Programme ;-) installier ich nicht gern auf meinem PC.

Daher finde ich es schade, dass es den CDC nicht als in Assembler 
einbindbares Projekt gibt, wohingegen der Custom-Treiber in Assembler 
ist. Der aber wirklich wohl nur für USB-Gurus taugt.

Gruß

Christian

Autor: Uhu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter:
> Das ist der übliche Stil, wie es MC-Anfänger machen.
> Ich hab im Internet noch nie was anderes gesehen.

Das beruht wohl eher auf einem Mißverständnis Deinerseits über die 
Funktionsweise eines Linkers.

Assembler erzeugen üblicherweise wenigstens drei Typen von Adressen:

- Absolute: z.B. Peripherie- oder Interruptvektor-Adressen
- Segmentrelative: die bestehen aus einer Segmentreferenz, dem 
symbolischen Namen und weiteren Informationen
- Commonblock-Adressen

Das passiert selbst dann, wenn das ganze Programm nur aus einem einzigen 
Quelltextmodul besteht.

Der Linker baut aus den Eingabemodulen die Segmente zusammen - indem er 
für jedes Segment Code/Daten der einzelnen Module einfach 
hintereinandersetzt. Dann werden die Segmente angeordnet, sofern sie 
verschieblich sind und zum Schluß werden die absoluten Adressen der 
Symbole berechnet.

In einem zweiten Durchlauf werden dann die relativen Referenzen in 
absolute umgewandelt und in Code/Daten eingetragen.

> Das ist doch nicht Dein Ernst. Hast Du alle Codes im Kopf und
> rechnest Sprünge und Calls selber aus ?

Aber klar doch, ist das mein Ernst: Wenn man Assemblerprogramme 
schreibt, in denen alle Adressen absolut sind, dann kommt man ums 
Rechnen sowieso nicht herum.

Wer so beknackt arbeitet, der braucht keinen Assembler, denn sein 
Programm ist weder pflegbar, noch auch nur innerhalb der Prozessorlinie, 
für die es geschrieben wurde, portabel. Von Lesbarkeit ganz zu 
schweigen.

Wenn so einer einen Assembler benutzt, statt dem Hexeditor, dann ist er 
ein absolutes Weichei und soll sich was schämen.

> Sehr schön ist das beim Keil C51, wo die Schnittstellen je nach
> Memory-Modell und Compiler-Optionen unterschiedlich sind.

Auf der x86-Linie ist das nicht anders. Dafür benutzt ein 
Assemblerexperte dann Macros, die je nach Speichermodell die passenden 
Codesequenzen absetzen.

Die Assemblertechnologie war schon lange vor dem Aufkommen von Fortran, 
Cobol und Algol-60 sehr weit entwickelt und gerade die Macrotechniken 
waren so ausgefeilt, daß man damit eine sehr hohe Effizienz erreichen 
konnte.

Sieh Dir mal dem MASM von M$ an - der hat viele dieser Techniken 
eingebaut, nur benutzt sie heute keiner mehr und das Wissen darüber 
stirbt langsam aus.

Autor: Christian Meurer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

@feadi:
genauso isses! Und nehmen auch keinen PIC sondern einen Z80 mit PIO, SIO 
und statischem Speicher ;-)
Die Codetabelle in der Linken, den Taschenrechner (auf hex geschaltet) 
für die Adressen in der Rechten.

LOL

Gruß

Christian

Autor: Uhu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Die Codetabelle in der Linken, den Taschenrechner (auf hex geschaltet)
> für die Adressen in der Rechten.

Nein, falsch: In der Rechten halten sie eine Zigarette und mit dem 
linken Zeigefinger wird getippt.

Die Codetabelle haben sie im Kopf und den Hex-Rechner auch -- selber 
schon gesehen!

Autor: Uhu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralph schrieb:
> Du solltest dich mal mit C beschäftigen, nur auf Assembler zu
> setzen ist doch sehr einseitig.

Die Umkehrung gilt genauso. Gerade bei hardware-naher Programmierung 
sind Assemblerkenntnisse für C-Programmierer sehr wertvoll.

Ich selbst habe schon die Ursache für so manchen Programmfehler mit 
einem schnellen Blick ins Disassembly-Fenster des Debuggers gefunden, an 
dem ich anders wohl einige Zeit genagt hätte...

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian:

"Ich würde gern in Assembler programmieren, da ich hierbei gut die
Laufzeiten abschätzen kann"

Nur was kannst du da wirklich abschätzen?
 nimm zb eine IRQ routine.

Du hast die routine in assmbler geschriben und ausgrechnet das sie (nur 
um mal eine Zahl zu nennen) 25 Taktzyklen benötigt.
Gut, du weißt jetzt wie lange die Routine benötigt.

Und jetzt kommen die Unbekannten ins Spiel.

+ Wie viele Taktzyklen werden benötigt um in die IRQ routine zu springen 
?
( bei PIC sind es glaub ich 6 oder 7, aber bin nicht ganz sicher)
+ Wie viele Taktzyklen werden benötigt um vm IRQvektor zur richtigen IRQ 
routine zu springen ? ( der PIC hat nicht allzuviele IRQ vektoren)
+ Wie lange sind in der MAIN Schleife die IRQ gesperrt weil etwas läuft 
das nicht unterbrochen werden darf ?

Also du weißt IRQ benötigt 25 Taktzyklen + 6 zum Einsprung in IRQ + n ( 
können leicht in die 100 gehen)Taktzyklen mit warten Ausführung deiner 
Routine.

Also eine sehr präzise Abschätzung ......

Bei einer Funktion die in der Main läuft ist es noch schlimmer.
Möglicherweise wird sie nicht unterbrochen, vieleicht von einem IRQ 
vielleicht von mehreren IRQ.
Also Laufzeitabschätzung fast unmöglich.

Ok die Nettolaufzeit deiner Routine kannst du immer ausrechnen, nur die 
Nettolaufzeit nutzt dir nichts.

Du brauchst die Bruttolaufzeit, das heißt mit allen möglichen 
Unterbrechungen und Verzögerungen.

Wenn du also deinen µC nach den berechneten Nettolaufzeiten auswählst, 
wirst du garantiert große Probleme bekommen.

Je kritischer das zeitverhalten deiner Anwendung ist, desto mehr Reserve 
musst du in der µC Auslastung frei haben.

Autor: Uhu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zudem kann man die Nettolaufzeiten von C-Routinen genauso bestimmen: Man 
rechnet die Ausführungszeiten der einzelnen Befehle zusammen - die gibt 
praktisch jeder Compiler auf Wunsch aus - sofern man nicht sogar die 
Zyklenzahlen direkt bekommen kann.

Ein Problem - neben ISRs - hat man allerdings: Es gibt Befehle, die je 
nach Daten verschieden lange brauchen - z.B. bedingte Sprünge.

Dieses Problem hat der Asm-Programmierer aber auch, wenn der Prozessor 
solche Befehle hat...

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu:

Niemand hat behauptet das er Assembler vergessen soll.

Man muss um vernünftig arbeiten zu können assembler lesen und 
nachvollziehen können.
Ohne das ist die Arbeit mit dem Debugger nahezu unmöglich.

Und welcher Wert ein Debugger hat, ist wohl unumstritten.

Nur in assmebler zu programmieren ist meiner Meinung nach viel zu 
umständlich und langsam.
Es gibt auf einigen µC Registerzugriffe die nur per Assembler machbar 
sind, ok hier reichen ein paar Zeilen INLINE Assembler.



In der Diskussion Assmbler oder C muss man eigentlich doch nur das Ziel 
des Projektes festlegen, dann ergibt sich die Antwort von allein.

+ Schreibt man die software um zu zeigen das man es kann ==> Assembler 
und dann eine Stunde eigene Schulter klopfen

+ Schreibt man die Software um zb eine Temperatur Regelung im Aquarium 
zu realisieren, dann ist die Software mittel zum zweck ==> C

als Vergleich zur nicht Softwarewelt.
Du bist in München und willst nach Hamburg

a) du gehst zu Fuß weil du es kannst und nur so den kürzesten Weg 
(Luftlinie) nutzen kannst

b) du fährst mit dem Auto, es sind vielleicht ein paar KM mehr, aber es 
geht viel schneller

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu wrote:
> @Peter:
>> Das ist der übliche Stil, wie es MC-Anfänger machen.
>> Ich hab im Internet noch nie was anderes gesehen.
>
> Das beruht wohl eher auf einem Mißverständnis Deinerseits über die
> Funktionsweise eines Linkers.

Lies bitte richtig:

Ich schrieb nicht "wie ich es mache", sondern "wie man es im Internet 
sieht" !

Sogar die Atmel, Intel und Philips Beispiele sind absolut adressiert.


Wie ein Linker funktioniert, brauchst Du mir nicht zu erklären, ich 
benutze doch C.
Ich hab auch schonmal einen C-Code nach Assembler übersetzt, um zu 
sehen, welcher Wasserkopf da erzeugt wird, damit alles relativ, extern 
und public ist.
Ich habe aber trotzdem keine Lust, C mit Assembler zu mixen und auch 
nicht die Notwendigkeit.

Ich weiß, wie es geht (einfach ne C-Dummy-Funktion nach Assembler 
übersetzen und dann den Assembler einfügen), aber wie gesagt, mir sind 
der Aufwand und die Nachteile zu groß.


> Aber klar doch, ist das mein Ernst: Wenn man Assemblerprogramme
> schreibt, in denen alle Adressen absolut sind, dann kommt man ums
> Rechnen sowieso nicht herum.

Quatsch, da muß man überhaupt nichts rechnen.
Sprungmarken kann man auch in absoluten Code verwenden und die Variablen 
werden zu Anfang aufsteigend absolut positioniert:
dseg
org 30h
var1: ds 1
var2: ds 1
...
stack: ds16
cseg
org 0000h
jmp init
...
init:
...


Peter

Autor: jjk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>In der Diskussion Assmbler oder C muss man eigentlich doch nur das Ziel
>des Projektes festlegen, dann ergibt sich die Antwort von allein.

Ehrlich gesagt verstehe ich nicht was es da ueberhaupt zu diskutieren 
gibt.

Im Hobbybereich (Altdeutsch: Liebhaberei) sollte doch jeder genau das 
machen was ihm Spass macht.

Genau deshalb programmiere ich seit 20 Jahren in Assembler, auch 
jenseits von 8K ;)

Hoeher, schneller, weiter... hab ich dabei nicht noetig. Ich muss 
schliesslch Niemandem etwas beweisen.

just my 2 cents.

juergen

Autor: Christian Meurer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo liebe Leute,

ich wußte gar nicht, dass ich in so ein Wespennest steche mit meiner 
Vorliebe für Assembler. Um Gottes Willen, ich will doch nicht die 
C-Programmierer diffamieren, ich hab doch selbst mein Geld damit 
verdient.

Die Frage ist doch nur, wie ich meinen PIC programmieren will. Und dafür 
erscheint mir beim Umfang meines Programms und Wissens Assembler als die 
beste Lösung. C für PIC müsste ich erst lernen, und wenn ich es dann 
kann ist mein Compiler abgelaufen und "läuft nur noch auf 3 Pötten". Ne 
ne, kommt mir nicht ins Haus.

Schönen Gruß

Christian

Autor: Uhu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter:
Und was ist daran absolut adressiert?

> jmp init
> ...
> init:

Garnichts. init ist eine symbolische Adresse.

Das ORG 0 macht das Segment absolut und damit hat der Entwickler des 
Sprachpaketes die Wahl, ob der ASM die Relokation durchführt, oder ob 
der Linker - der das sowieso können muß - dafür zuständig ist.

Letzteres wäre die aus Entwicklersicht ökonomischere Lösung, ersteres 
die zur Laufzeit schnellere.

Daß das Problem nicht allgemein vom ASM lösbar ist - was stark für die 
generelle Lösung per Linker spricht -, zeigt folgendes Szenario:

Modul 1:
ORG 0x0000
extern init
....
jmp init


Modul 2:
ORG 0x01000
public init
...
init:
...

Obwohl es sich um zwei absolute Segmente handelt, muß der Linker den 
'jmp init' modifizieren, damit die Module zusammenpassen.

@jjk:
> Im Hobbybereich (Altdeutsch: Liebhaberei) sollte doch jeder genau
> das machen was ihm Spass macht.

Findest Du es nicht schön, wenn dabei so nebenbei etwas mehr, als nur 
ein solides Halbwissen rauskommt?

Autor: jjk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@jjk:
>> Im Hobbybereich (Altdeutsch: Liebhaberei) sollte doch jeder genau
>> das machen was ihm Spass macht.

>Findest Du es nicht schön, wenn dabei so nebenbei etwas mehr, als nur
>ein solides Halbwissen rauskommt?

Interessante Argumentation ;)
Ich bin zutiefst beeindruckt wie gut Du mein Wisssen einschaetzen kannst 
obwohl ich Deiner Logik nicht ganz folgen kann. Muss ich aber auch 
nicht.

juergen

Autor: Uhu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Christian:

> ich wußte gar nicht, dass ich in so ein Wespennest steche mit
> meiner Vorliebe für Assembler.

Nimms leicht... mir kommt das zuweilen auch vor, als würden sich Esel 
und Langohren gegenseitig bekämpfen.

Für winzigkleine Hobby-Projekte ziehe ich auch ASM vor - macht einfach 
Spaß!

Bei größeren Sachen, oder gar im Beruf geht das einfach nicht.

Diejenigen, die das hier hobbymäßig betreiben, sind in der Beziehung 
natürlich keinen Zwängen unterworfen.

Denen, die mit dem Gedanken spielen, beruflich in das Fach einzusteigen, 
empfehle ich sogar, mit ASM und einem ganz kleinen Prozessor zu beginnen 
- man lernt damit, wie das Maschinenmodell eines Prozessors funktioniert 
und dem Größenwahnsinn ist ein physikalischer Riegel vorgeschoben.

Im Studium wird man von ASM nicht mehr viel mitbekommen, da kann man 
sich mit dem Hobby-Wissen einen 'Zugang von der anderen Seite' 
verschaffen, der im Zweifelsfall sehr nützlich sein kann.

Autor: Christian Meurer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo liebe Leute,

es kommt darauf an, was Gegenstand der Diskussion ist: die Frage, welche 
Programmiersprache die Beste ist - darüber kann man sich bis aufs Blut 
streiten- , oder doch was jeder für sich persönlich am Besten kann.

Wenn man sich für den µP interessiert und dessen Arbeitsweise verstehen 
möchte ist Assembler eindeutig die Sprache der Wahl. Dieser Weg ist auch 
nicht unbeding der langsamste ( Fußgänger zu Auto ). Wenn ich den 
Prozessor samt seiner Register etc. kenne, kann ich aus Assembler 
programmieren. Zumal die PICs ja RISC sind, da muss man sich nicht so 
viele Befehle merken ;-)

Gruß
Christian

Autor: Uhu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@jjk:

Hab ich das auf Dich bezogen? Kommt mir eher nicht so vor...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu wrote:
> @Peter:
> Und was ist daran absolut adressiert?
>
>> jmp init
>> ...
>> init:
>
> Garnichts. init ist eine symbolische Adresse.

Doch.

Absolut adressiert ist, wenn der Assembler schon die richtigen Adressen 
einträgt.
Relativ adressiert ist, wenn er erstmal 0x0000 einträgt und dann der 
Linker ranmuß, um das aufzulösen.

Perse müssen Programme, die aus mehreren Modulen bestehen, relative 
Adressen enthalten, da ja der Assembler Module getrennt übersetzt.
Außerdem muß man den Assembler per extern/public besänftigen, sonst 
geben die nicht aufgelösten Adressen nen fetten Error.

Aber wie gesagt, viele MC-Beispiele im I-net bestehen nur aus einem 
Modul und daher auch nur aus absoluten Adressen.

Z.B.:

http://www.nxp.com/files/products/standard/microco...

http://www.atmel.com/dyn/resources/prod_documents/AADC.EXE


Peter

Autor: jjk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu:

>@jjk:

>Hab ich das auf Dich bezogen? Kommt mir eher nicht so vor...

Ich hatte Ralph zitiert ;)

juergen

Autor: Christian Meurer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo liebe Leute,

wie sieht es denn nun aus? Wenn ich mal Bilanz ziehe wurden mir 3 
Möglichkeiten angeboten um mein Projekt zu realisieren:
1) C für PIC lernen
  -scheidet aus wegen Ablauf nach Zeit.
2) PIC ohne USB nehmen und UART-USB-Baustein anlöten
  -damit wäre mein schönes Layout dahin, war doch froh, dass es so schön
   einfach war und mit nur einem Layer auskam
3) CDC Firmware compilieren und mit den Objekt-Files im Assembler 
weiterarbeiten

3) ist für mich bisher die Beste Wahl. Was muss ich also tun, als 
"C-für-PIC-Ahnungsloser"?


Gruß
Christian

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"1) C für PIC lernen
  -scheidet aus wegen Ablauf nach Zeit. "

C ist auf jedem µC das gleiche, DAS ist ja der Vorteil von C.
Also wenn du C kannst, dann kannst du auch C-Code für den PIC schreiben.

Die unterschiede muss nur der Compiler kennen der aus dem C-Code den
Assemblercode erzeugt.

und zu Zeitablauf:
Verwende den SDCC Compiler, der ist opensource und kann auch Code für 
den PIC erzeugen.

Autor: Christian Meurer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

@Ralph:
ist dann dieser SDCC auch in der Lage mit der speziell für den C18 
geschriebenen Firmware etwas anzufangen? Was muss ich beachten?

Gruß
Christian

Autor: Uhu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Christian:

Gleich vorweg: Ich kenne den SDCC nicht aus eigener Anschauung, kann 
also nur generelle Tipps geben.

> ist dann dieser SDCC auch in der Lage mit der speziell für den C18
> geschriebenen Firmware etwas anzufangen? Was muss ich beachten?

Aber ja. C ist genormt und die wenigen compilerspezifischen #pragmas und 
Optionen, in denen sie sich unterscheiden, kann man i.d.R. durch 
aufmerksames Lesen und Vergleichen der Handbücher finden und anpassen.

Ob es sich um Firmware oder irgend ein Ballerspiel handelt, ist dem 
Compiler völlig Schnuppe; dem kommt es nur auf korrektes C an.

Ob der SDCC für Deinen Zweck geeignet ist, stellt sich sehr schnell 
heraus. Die Frage ist, ob Du die von Deinem ASM erzeugten Module mit 
denen des Compilers überhaupt zusammenbinden kannst - also ob die 
Formate der Moduldateien kompatibel sind.

Am einfachsten bekommst Du das heraus, indem Du ein kleines C-Programm 
schreibst, etwa mit folgendem Inhalt:
void test() {
   // Dies ist eine Funktion, die nicht macht.
}

Dann schreibst Du einen ASM-Modul, in dem Du test etwa folgendermaßen - 
entsprechend den Vorschriften des Assemblers natürlich - als extern 
vereinbarst:
extrn _test
call _test

Der Unterstrich wird von C-Compilern üblicherweise vor den Namen 
gesetzt.

Dann versucht Du Deinem Linker zu erklären, daß er den C-Modul zu Deinem 
ASM-Modul binden soll.

Wenn er dabei mit einer Fehlermeldung über einen inkompatiblen 
Objektmodul aussteigt, oder sonst wie ausrastet, kann man diesen Weg 
höchstwahrscheinlich abhaken.

Du könntest dann nachsehen, ob der Compiler vielleicht einen ASM 
mitbringt, der Deine ASM-Syntax versteht - wenn ja, hast Du gewonnen.

Mach das erst mal und poste ggf. die Fehlermeldungen - dann werden wir 
weiter sehen...

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian:

Ich hab den SDCC bisher nur für 8051 er benutzt, hab aber gesehen das er 
auch eine Configuration für PIC enthält.
Als IDE verwende ich da "Code:Blocks"

Welchen Umfang der SDCC für PIC unterstützt kann ich dir nicht sagen, du 
kannst es aber auf der Homepage des SDCC leicht rausfinden.

Dort gibt es ein Forum bei dem auch die Entwickler des SDCC erreichbar 
sind.




Autor: rebs88 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schön das sich jeder dritte Thread in die Streitigkeit von 
Programmiersprachen entwickelt.

C oder Assembler ---> Ihr solltet euch langsam entscheiden, es kann 
schließlich nur einen geben!

Autor: Jupp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nehme grundsätzlich nur LISP, es gibt nichts besseres und vor allem 
ist es schön kryptisch.

Autor: Christian Meurer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo liebe Leute,

so wie es aussieht kommt man bei der CDC-Firmware wohl nicht um C herum. 
Ginge es nur um Funktionsaufrufe, hätte man sicher auch mit Kenntniss 
der Schnittstelle, mit den Objekt-Files weiterarbeiten können.
ABER: Es gibt dermaßen viele C-Makros im CDC, die erstmal umgeschrieben 
werden müssen, dass die Sache richtig in Arbeit ausartet.

Notgedrungen werde ich wohl mal C für den PIC lernen. Genaugesagt den 
Umgang mit den Bibliotheken und Direktiven des Compilers.

Zum Kampf der Sprachen:
Was ist eigentlich aus Modula geworden?
Achja, C++ mag ich überhaupt nicht.
Und Java: pfui!!

Gruß

Christian

PS: Nicht alles zu Herzen nehmen, es ist nicht so ernst!!

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erstens mal: Das es die Sache nur in C gibt, hat auch einen guten Grund, 
abgesehen davon dich zu ärgern:
1. Das ganze ist vermutlich komplexerer Natur. Und die Programmierer bei 
Microchip wollten auch nicht jahrelang dran arbeiten. Mit C entwickelt 
sichs einfach schneller, also wird das genommen.
2. die Software Entwickler benutzen zu 99% auch C, weil sie damit eben 
ihre Projekte schneller fertig bekommen, und weils portabel und 
übersichtlich ist. Man stellt eben seine Bibliotheken für die 
Hauptzielgruppe, und nicht für Randgruppen bereit. Sonst müsste man noch 
ne Bibliothek für Pascal und sonstiges entwickeln ...
Außerdem lohnt sichs für Microchip wohl kaum viel Arbeitszeit (und damit 
auch Geld) in etwas zu stecken, was vermutlich keiner benutzt.

Das eigentliche Problem ist doch, dass der C-Compiler Geld kostet. 
Nunja, die Firmen wollen halt auch Geld verdienen, und für Firmen ist 
der Compilerpreis eher gering. Fürs private Vergnügen aber halt doof. Da 
gibts dann noch die Möglichkeit einen frei verfügbaren Compiler zu 
nutzen (kenn mich bei PIC aber nicht aus) und notfalls die Plattform zu 
wechseln. Oder halt doch einen FT232 nehmen und sich das ganze sparen.

Autor: pumpkin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu wrote:
> Im Studium wird man von ASM nicht mehr viel mitbekommen, da kann man
> sich mit dem Hobby-Wissen einen 'Zugang von der anderen Seite'
> verschaffen, der im Zweifelsfall sehr nützlich sein kann.

Blödsinn!

pumpkin

Autor: antworter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@pumpkin:

Ich nehme mir mal die Zeit, Deine wohlformulierten Argumente zu 
widerlegen:

Quatsch...

(Bin übrigens und tatsächlich voll und ganz Uhu's Meinung)

Autor: Christian Meurer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich muss sagen, dass ich im Studium eine ganze Menge µP-Technik und auch 
Assembler mitbekommen habe. Allerdings war das vor 10 Jahren

@Matthias
>Außerdem lohnt sichs für Microchip wohl kaum viel Arbeitszeit (und damit
auch Geld) in etwas zu stecken, was vermutlich keiner benutzt.

Also wenn USB für eine Randgruppe ist, dann weiß ich es auch nicht mehr. 
Das Problem ist ja, das den heutiogen PCs fast jegliche 
Legacy-Schnittstellen fehlen.
Übrigens was denkwürdig ist: Die Firmware für eine richtige 
Treiberentwicklung (Custom-Treiber) für ein Gerät, dass sich z.B. nicht 
als virtueller COM-Port ausgibt, ist komischerweise in Assembler 
geschrieben.
Da ich mich aber auf Windows-Ebene - und den damit verbundenen 
Verpflichtungen der Pflege neuer Versionen - nicht so weit herunter 
wagen will, nutze ich die COM-Emulation.

Grundsätzlich ist der USB-Bus eine Krux für Entwickler. Wenn man es 
recht einfach wünscht, kann man sich für eine RS232/COM - Emulation 
entscheiden. Damit unterliegt man aber einigen Einschränkungen, etwa, 
dass der Benutzer händisch einen COM-Port vergeben muss und die 
geringere Datentransferrate.
Möchte man aber ein richtiges USB-Gerät bauen, dann wird es richtig 
schwierig: Erstmal 500 Seiten USB-Spec verstehen, dann 
Windows-Treiber-Programmierung und API-Programmierung sowie natürlich 
auch die USB-Firmware des µP.

Gruß

Christian

Autor: tt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal zur Anfangsfrage:

Nimm den PIC C18 Compiler !  Die Einschränkungen nach 60Tagen sind kaum 
relevant. Ich benutze den beruflich den C18 Compiler und habe von den 
Einschränkungen bisher nichts gemerkt. Zumindest der freie TCP/IP-Stack 
von Microchip lässt sich damit problemlos verwenden. Ich habe zwar auch 
die Vollversion des Compiler im Schrank liegen, habe die aber bisher 
noch nie installiert.

Autor: zetti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
naja, viel installieren brauchst du da nich. es hängt alles an einer 
kleinen datei. und sieh wie lang 60 tage werden können...

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.