fastavr-basic

[pebisoft]

man muss im leben auch sehr harte kritik entgegen nehmen können,
abr die junge genaration und mittlerenalter generation ist verweichlicht, empfindlich und voll frust, können nicht mehr belastet werden, ziehen sich zurück und meckern nur noch aus dem hinterhalt ohne das man sie sieht.
mfg pebisoft

[PicNick]

...junge genaration ..verweichlicht, empfindlich ...

Es tut mir wirklich leid, wenn das deine vorwiegenden Erfahrungen sind, wirklich.

Kannst du dich erinnern ? Über unsere Generation haben sie das damals aber auch gesagt.

WIR waren ja in den 60-ern die Rocker, die Hippies und die Studenten auf der Straße.

[Frank]

Um wieder zur Sache was zu sagen:
Auch solche Dinge stimmen nicht pauschal:

wer sich noch nie mit winavr-c auseinander gesetzt hat kennt auch nicht die nähe von asm. diese nähe zum asm-code findert man nur in winavr-c oder fastavr. da ich diese asm-nähe brauche für meine Projekte habe ich mich für den kauf entschlossen.

Ich kenne mich mit C schon aus. Ich habe im Lauf der Jahre mehr C Programme als Basic Programme geschrieben (auf PC). Und WINAVR hab ich mir auch angeschaut, wenn auch nur kurz.
Auch Assembler ist mir nicht unbekannt, es gab Zeiten da war sowas sogar auf dem PC noch angesagt und sinnvoll. Auch in ersten Bascom Programmen habe ich schon I2C Routinen mal in Assembler verwirklicht (weils damals noch einen Bug in den Libarys gab). Allerdings bin ich da sicher kein Experte und die Registerstruktur liegt mir nicht so sehr, aber notfalls krieg ich da auch was zusammen, dauert halt nur! Aber es ist halt wirklich selten notwendig.

Ich finde es viel wichtiger das man in einer Hochsprache Assembler in den Quelltext einbinden kann und das ist bei WinAvr als auch bei Bascom der Fall. Ich hab in dem Thread immer noch nicht erfahren ob das überhaupt in FastAvr der Fall ist. Das nachträgliche einbinden in compilierte Programme bringt wenig, der Grund wurde hier ja schon genannt.
Also mehr Fakten wären angesagt wenn der Thread ne Aussage haben soll

Gruß Frank

[pebisoft]

hier kurz eine demo mit fastavr , mit asm als sub und wert einlesen als zahl , weiterhin eine sub und wert einlesen als übergebene variable.
hier sieht man auch, wie klar die programmierdisziplin ist.
es wird die gleiche disziplin verlangt wie bei winavr-c, darum ist fastavr-basic auch genause schnell wie winavr-c, wie ich festgestellt habe.
man braucht nur einmal den asm-code gegenüberstellen. fast kein unterschied.
mfg pebisoft

$Device= m16      
$Stack = 32      
$Clock = 8  
$Baud  = 19200
$Source= On   

Dim wert As Byte
Dim wert_adr As Word
Dim wert_1 As Byte
Dim wert_adr_1 As Word

Declare Sub test()
Declare Sub test_1()

wert_adr=VarPtr(wert) ' adr der variable im sram
wert_adr_1=VarPtr(wert_1)

wert_1=123 

Do

test()
Print wert
WaitMs 250

test_1()
Print wert
WaitMs 250

Loop

End

' können auch in einer sub declariert werden
$Asm
.def pebi_1=r24 
$EndAsm

' zahl 77 direkt einlesen
Sub test()
$Asm	
	ldi    pebi_1,77 
	STS wert, pebi_1 
$EndAsm	
End Sub

' wert_1 als variable einlesen
Sub test_1()
$Asm
	lds   pebi_1,wert_1
	STS wert, pebi_1
$EndAsm
End Sub

[Frank]

Danke, das ist doch mal ein Fakt. Nun gut, man kann Assembler einbinden. Aber das geht ja in Bascom alles sehr ähnlich. Wo siehst du nun den großen Vorteil?

Gruß Frank

[DIYLAB]

Moin,

vielleicht könnte ja Pebi ein Stückchen seiner professionellen Programmierkunst zum Besten geben und uns wenigstens ein kleeeeines bisschen in seine Meisterwerke reinschnuppern lassen?
Wie sollen wir uns denn sonst ´ne Meinung bilden?

Der gepostete Codeschnipsel ist ja nicht der Brüller, also los Pebi, lass Dich nicht lumpen und gib uns bitte ein paar Profi-Tipps!!

LG,
Bruno

[pebisoft]

nee, nee. das müsst ihr schon selber machen. ihr sollt euch keine meinung bilden. beschäftigt euch erst einmal mit winavr-c und wenn ihr da etwas zustande bekommen habt, dann seit ihr schon ein kleines stück näher.
ich habe in winavr-c folgende Sensoren geproggt:
- lcd-display 2x20
- lcd-display von pollin 128x64 pixel in text und grafik
- cmps03 compasmodul
- srf04 ultramodul
- srf08 ultramodul
- sharpsensor
- tsop 1736 (empfängercode selber erstellt)
- ir-sendediode rc5 (sendecode selber erstellt)
- i2ceeprom 24x256
wenn ihr das in winavr-c geschafft habt, dann können wir uns noch einmal unterhalten, über die feinheiten des programmierens.
habe alles schon in fastavr umgesetzt, natürlich profimässig. geile sache.
der küchenbrettroboter rollt mit fastavr-basic.
na, denn,schlaft schön .

"Der gepostete Codeschnipsel ist ja nicht der Brüller, also los Pebi, lass Dich nicht lumpen und gib uns bitte ein paar Profi-Tipps!!"
diese aufforderung sieht so nach einer schlappen form aus.

so, jetzt muss ich mich erst einmal wieder mit meiner 135 euro teuren cmucam2 beschäftigen, geiles ding, kann ich euch sagen. habe schon die ersten erfolge auch mit fastavr und der cmucam2, toll. die raum-werte eines vorher eingegebenen farbigen gegenstandes werden jetzt schon als daten umgesetzt. wenn ich den gegenstand bewege zeigt er mir die x,y an und die kleinerwerdende box an, die signalisiert, das sich der gegenstand entfernt. ist garnicht so schwierig, wenn man weiss wie. ich schätze in 4tagen fährt mein küchenbrettroboter nach den daten.
die gameboycam habe ich noch nicht am robby gestestet, kann das bild, das mit fastavr gesendet wird aber schon mit meinem selbsterstellten visual5.0 programm vom tischboard und AVR auf dem pc empfangen.
wie ihr seht, laufen mehrere Projekte bei mir. mein usb-easyfunkmodul (70 euro) kann auch schon mit mit dem easy-funkmodul auf dem robby verbindung aufnehmen mit fastavr. die 3x srf04, 2x sharpsensoren und cmps03 compassmodul gehen zufriedenstellend mit fastavr auf dem küchenbrettroboter.
mfg pebisoft

[pebisoft]

"Aber das geht ja in Bascom alles sehr ähnlich. Wo siehst du nun den großen Vorteil?"
ein stück hähnchenfleisch schmeckt auch so ähnlich wie ein stück kaninchenfleisch. beide machen satt, haben aber verschiedene einweisswerte und andere inhaltsstoffe.
hallo frank, beschäftige dich mal mit fastavr, dann erkennst du die vorteile.
mfg pebisoft

[Frank]

Guten Morgen Pepisoft,

na staun! Gestern Abend sah dein Beitrag ja noch ganz anders aus. Du hast ihn ja inzwischen stark entschärft und das Niveau gegenüber dem ersten Beitragsentwurf wieder angehoben. Ein Glück für Dich das bei uns im Ort das komplette Internet in dem Moment ausgefallen war als ich dir die passende Antwort schreiben wollte. So bist du auch einer Verwarnung noch gerade so entschlüpft.
Du weist sicher selbst das du wieder nah an Verwarnung dran bist, einige deiner letzten Anmerkungen zu Usern sind schon auf einem bedenklichen Niveau. Es fehlt also nur noch ein I-Tüpfelchen.
Übrigens, wir haben auch eine Zitat-Funktion. Da du ja sehr viel Zeit hast wie du immer sagst, solltest du dich vielleicht auch mit den Forum Funktionen beschäftigen.

Dies war eine sachliche Frage zu der Assembler-Einbindung:

Aber das geht ja in Bascom alles sehr ähnlich. Wo siehst du nun den großen Vorteil?"

Ich wollte wissen wo du die Vorteile bei der direkten Assembler Einbindung siehst. Generell ist die in der Tat fast identisch auch bei Bascom vorhanden. Ich hatte eigentlich eine sachliche Antwort erwartet.

Wie schon gesagt, ich hab mir FASTAVR schon angeschaut und hab auch schon beschrieben das die für mich wichtigen Dinge mir bei Bascom wesentlich besser gefallen haben. Welche Dinge das waren wurde auch schon gesagt. Dennoch kann in einigen weniger wichtigen Dingen FASTAVR sicher auch ein paar Stärken haben, ich dachte du wolltest hier überzeugen. Nachfragen müssen daher erlaubt sein, man ist ja neugierig. Wenn du nicht überzeugen als auch keine Punkte nennen willst die dir positiver erscheinen, wozu dann der Thread.

Gruß Frank

[pebisoft]

hallo, guten morgen.
meine neue idee ist es einen asm-codemodulkasten zu bauen für alle wichtigen routinen der Sensoren und abläufe. dieser ist mit fastavrbasic nicht schwer zu realisieren, da er ein fein strukturierter mit text versehender asm-courcode für den asm32avr herauskommt.
die ersten ansätze wollte ich schon einmal nur mit asm-code-assembler alleine machen, war mir zu komplex. fastavr ist die "allergrösste hilfe" dafür. für fastavr-basic braucht man auch keine hilfe und fragen, wie fastavr funktioniert sondern hier tauchen nur fragen auf: wie setze ich das register tccrb1 um ein togglebit zu erzeugen oder wie setze ich jenes register , fragen wie bei Bascom auch. aber fragen hinsichtlich der fastavr-basic-befehle , wie sie in Bascom auftauchen gibt es nicht. hier geht es eigentlich nur noch um den sensor und rein um die avr-struktur.
eingentlich müsste Bascom in den befehlen auch leicht sein und es dürften keine Bascom fragen über die befehle auftauchen sondern eingentlich auch nur noch strukturfragen über den AVR oder über den sensor, aber leider ist das nicht so. z.b. wundere ich mich wie langsam Bascom ist wenn das compasmodul cmps03 angesprochen wird. es kommt daher, weil die warteschleifen für den internen i2c-ablauf (register befüllen) 5x so gross sind als man für das modul braucht (man spricht auch davon Bascom arbeitet wie ein büffel (dran-drüber-drauf)), darum ist es auch problemlos und der anwender sagt : du, Bascom schluckt alles).
bei mir dauern die internen i2c-wartezeiten 5us bei Bascom über 25us.
das gleiche tritt auch beim abfragen des tsop1736 auf mit getrc5.
da werden daten auf den stack gepopt, wo man sich fragt, junge das brauch doch Bascom normal nicht machen und auch hier werden die wartecyklen auf auf das 4fache verlängert. Bascom ist halt ein büffel.
sicherheitsfaktor für die ausführungssicherheit um die oberflächliche interne asm-struktur nicht zerbrechen zulassen. ich kann hier noch viele dinge aufzählen. wie ihr merkt geht es nicht um +,-, *, / sondern um das ausführen von befehlen für die sensoren. der ir-sendebefehl ist noch schlimmer mit der zeitvergeudung. schnappt mir sogar auf dauer einen interrrupt weg. so, genug geschrieben.
bis bald.
mfg pebisoft