Wer zu tief gräbt, muss zahlen

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.

> 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.

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

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.

Ach ja,

dir auch schöne Grüße :)

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...

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

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.

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

>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.

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

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?

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ß

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?

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...

> Ist mir einfach zu kryptisch.

LOL was bitte ist an C kryptisch???

/funein
Echte Progammierer programmieren nur in Assembler :o)))
/funaus

>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?!?

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.

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

@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.

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

@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.

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

> 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!

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...

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.

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...

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

>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

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

@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?

>@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

@ 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.

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

@jjk:

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

Uhu:

>@jjk:

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

Ich hatte Ralph zitiert ;)

juergen

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

"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.

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

@ 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:

1

void test() {

2

   // Dies ist eine Funktion, die nicht macht.

3

}

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

1

extrn _test

2

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...

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.

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!

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

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!!

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.

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

@pumpkin:

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

Quatsch...

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

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

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.

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