OK, ich werd mich dann mal ans Programmieren machen.
Hab mir gedacht, dass ich das mit VC++ am besten gebacken bekomme und ich dafür eine gute Comunity hinter mir hab !
Werd euch auf dem Laufenden halten ...

MFG
FatalError

PS: Grafische Oberfläche und Synthax-Highlighting sind versprochen

[ Diese Nachricht wurde geändert von: FatalError am  2 Jun 2003 21:07 ]

So, die grafische Benutzerpberfläche ist (soweit) fertig und das Synthax-highliting funktioniert auch schon.
Wenn noch jemand Vorschläge hat, immer her damit !!!

MFG
FatalError

die idee ist wzar net neu aber gut

gute compiler fuer mikrokontrolelr (samma kannd er opera nimmal ein mü schreiben ) sind imemr noch rar, meist nur c oder asm,da käme sowas wie egrufen,besonders wenn man damait auch einfach multitaskin und i/o proggen kann

Ich hab für diese Sprache ungefähr 10-20 Befehl eingeplant.
Kann nochmal jemand zur Sicherheit posten, was man dem µC alles sagen müsste?
Also ich hab bisher die folgenden (µC speziefischen) Befehle eingeplant:

setbit ("n", x)= y : setzt am Port -n- das Bit -x- auf -y-(y = 1 oder 0)
y = readbit ("n", x) : ließt aus, ob der Schalter an Bit -x- am Port -n- offen oder geschlossen ist. Das Ergebnis wird in -y- ausgeben.Ist -x- gleich null, dann wird ausgegeben, welche Bits am Port gesetzt sind.
setio ("n") = y : legt fest, ob der Port -n- als Eingang(n =0) oder als Ausgang (n=1) genutzt werden soll.

Und natürlich noch verschiedene Programmablaufbefehle(for-next, do-loop, etc.)

Was bräuchte man noch so?


MFG
FatalError

[ Diese Nachricht wurde geändert von: FatalError am  6 Jun 2003 23:18 ]

Hi,

was Du oben an Befehlen bisher genannt hast, sind die harmlosen Brüder. Wenn man nur die braucht, kann man gleich in Assembler bleiben.
Eine höhere Programmiersprache soll ja den Programmierer entlasten. Aber das nimmt dann sofort ganz schöne Ausmasse an...
Wenn im bedenke, wie gut der IAR C Compiler das für den Atmel in der Regel hinkriegt (wenn man nicht gerade zu viele Pointer Operationen gleichzeitig macht), frage ich mich, wie man das als einzelner übertreffen will.
ODer habe ich da was falsch verstanden?

DoS

Genau deswegewn Frag ich ja, damit ich genau weiß, was das Proggi alles können muss!
Nagut, ich könnte genausogut n paar Tuts in Sachen µC Progging durchlesen. Das geht bestimmt schneller als hier, weil dort nicht jedes zweite Tut mit Kritik vollgestopft ist.

Werd mich mit dem Resultat wieder melden. Achja, ihr habt bestimmt gemerkt, das auch Variablen mit zum Einsatz kommen.

MFG
FatalError

Schau dir mal die Bascom-Hilfe an, was da Mark Albert alles so drinn hat.

Die Adresse: http://www.mcselec.com/download_avr.htm
_________________
mfg Jornbyte
Für weitere Fragen Bitte auch den Chat nutzen.
Es handelt sich bei dem Tipp nicht um eine Rechtsverbindliche Auskunft und
wer Tippfehler findet, kann sie behalten.

[ Diese Nachricht wurde geändert von: Jornbyte am  7 Jun 2003 11:30 ]

@ Jornbyte:
Ja und genau sowas will ich mit meinen Programmer eben NICHT !!!
"µC proggen mal ganz einfach" lautet der Slogan und mit den 50 Befehlen dieses "Bascom AVR" ist das wohl kaum zu realisieren.
Man soll damit keine riesigen Projekte verwirklichen können, sondern einfach nur kleinere Sachen aufbauen und ablaufen lassen.
Denn mal ehrlich wer hat schon lust, nachdem er sich ein kleines Projekt vorgenommen hat, erst ein haufen Tutorials zu wälzen ???
Genau da soll mein "µC BasicCoder" zum Einsatz kommen.
Er wird einfach zu bedienen und auch Anfänger sollen schnell hinter die Sprache kommen.
Vielleicht werd ich aber doch einiges übernhemen, mal sehen, wie sich alles entwickelt...

MFG
FatalError

Hi,

sorry, aber ich halte den Ansatz für falsch. Wenn man einen MC programmieren will, muss man wohl oder übel das Handbuch lesen.
"Was hat der überhaupt an Peripherie drinne? Welche Ports kann ich wie benutzen? WElche Baudrate erlaubt der UART mit welchem Quarz ..."
Wenn man das gelesen und kapiert hat, ist imho der AVR Assembler schon recht schnuckelig.
Die AVR Befehle sind an sich ja auch schon recht logisch - sie wurden meines Wissens nach in Zusammenarbeit mit Compilerbauern (na wer wohl) festgelegt...

DoS

[ Diese Nachricht wurde geändert von: dos6510 am  7 Jun 2003 18:36 ]

Ja, ich hab ja auch nicht von Datenblättern der µC gesprochen, sondern von Tutorials für Assembler.
Diese erst durchzulesen ist ziemlig nervig, an Datenblättern kommt man wirklich nicht vorbei.

Hab mal noch n Screenshot der (fast) fertigen Oberfläche mit geladenem Beispielprogramm geupped.
Die Position der Buttons unten werd ich nochmal überdenken(oder löschen) und das Menü wird noch erweitert.

MFG
FatalError

Uploaded Image: bsp pic.jpg

Nun muss ich aber mal Dumm Fragen, da ich in deinem Beispiel keinen Hinweis auf den verwendeten Controller gesehen habe, für was für ein Type ist dein Proggi?
Nun schreibe aber nur nicht einfach Pic oder Atmel, da die Palette der Risc-Proz relativ groß und nicht alle Hochsprachen tauglich sind.


_________________
mfg Jornbyte

Es handelt sich bei dem Tipp nicht um eine Rechtsverbindliche Auskunft und
wer Tippfehler findet, kann sie behalten.

Jetzt muss ich mal eben dumm gegenfragen :
Sind denn nicht ale µC mit asm programmierbar? Also nachdem man diese Files(*.asm) in eine Hexadezimale Datei umgewandelt hat? Eigentlich schon, oder?
Mein Proggi soll diesen Basic-Code erst in asm und dann in hex umwandeln. Muss dann doch eigentlich gehen.

MFG
FatalError

Ja, das ist schon richtig. Mit *.Hex werden die Teile gebrannt. Nur haben die PIC und Atmel einen unterschiedlichen Befehlscode. Bei der Verwendung von Variablen muss der interne Ram herhalten, da ein Register mit mehreren Variablen belegt werden kann. Nun hat aber nicht jeder µController einen internen Ram. Denke auch an den Stackpointer, der benötigt auch Ram. Auch ist die interne Hardware der µController unterschiedlich. Das musste alles beachten. Das erklärt nun auch die erste Zeile eines Proggis (.include "8515def.inc")

_________________
mfg Jornbyte

Es handelt sich bei dem Tipp nicht um eine Rechtsverbindliche Auskunft und
wer Tippfehler findet, kann sie behalten.