Hallo, bei einigen anwendungen kommt man ja nicht um prozessoren drumrum, die mehr als nur 8 bit haben. Aber wenn man sich einmal an bascom gewöhnt hat ist es sehr schwer mit c anzufangen, wenn man es noch nie benutzt hat. Kennt jemand was bascom ähnliches für arm oder v850? Oder sogar 386er (ohne das man ein dos starten muss)
"bei einigen anwendungen kommt man ja nicht um prozessoren drumrum, die mehr als nur 8 bit haben." Welche wären das ? Ich vermute mal, Du bist mit der Geschwindigkeit von Bascom nicht zufrieden. Da ist kein Umstieg auf 16 Bit nötig, ein Umstieg auf C bringt schon ne ganze Menge. Oft hilft aber auch schon eine bessere Strukturierung des Programms. Man sollte Programme vor allem auf versteckte CPU-Leistungsvernichter überprüfen. Das sind grundsätzlich alle Delays und Warten auf irgendwelche Bedingungen. Diese schreibt man dann so um, daß das Main trotzdem weiterläuft, d.h. alle anderen Sachen. Peter
hi, mittlerweile gibt's doch für (fast) jeden uC einen basic-COMPILER. der umstieg von basic auf c bringt in sachen avr weissgott nicht mehr tempo, dieses ammenmärchen gehört in die zeiten, als basic nur als interpreter lief. ein compiler erzeugt aus einer hochsprache (welche auch immer) einen maschinencode, der meist nicht hirn- und gnadenlos generiert wird, sogar in sachen wie bascom steckt einiges an hirnschmalz. probier mal spasseshalber 'ne zeitzmessung für die anweisungen "incr x" in c und bascom. guckst du - ausführungstempo gleich. was schliessen wir daraus? sowohl c als auch bascom als hochsprache werden perfekt in den korrekten, minimal notwendigen, maschinencode compiliert. wie der code denn letztendlich zustandekommt ist egal, wichtig ist nur, dass die compilation optimal läuft. guckst du mal fast-avr, kompakteren maschinencode kriegst du auch (für timing-unkritische anwendungen) mit assembler nicht hin. wenn das timing zum problem werden könnte, z.b. bei video-anwendungen, kannst du getrost auf basic und c verzichten, das ist halt nur nach festen zyklen machbar und das geht am besten in assembler. grüssens, harry
MMHH habe jetzt das problem, dass ich ein pwm signal lesen muss, was eigentlich mit v850 prozessoren kein problem ist, mit dem avr bist de da schon an der grenze. übertaktet läufts prima, aber das will ich nicht dauerhaft. Das bascom nicht langsamer ist als C wurde ja schon mehrfach getestet, und als nichtig abgetan. Klar hat vielleicht der eine oder andere compiler bestimmt verbesserungsmöglichkeiten, aber es will mir doch keine erzählen das er perfekt asm proggen kann
@Harry "der umstieg von basic auf c bringt in sachen avr weissgott nicht mehr tempo" Rein Compilermäßig mag das ja stimmen. Aber in der Regel sind C Programme strukturierter (mehr Unterfunktionen, direkte Parameterübergabe, mehr lokale Variablen) und dadurch sind sie deutlich schneller. Peter
@Rolfi, "dass ich ein pwm signal lesen muss, was eigentlich mit v850 prozessoren kein problem ist, mit dem avr bist de da schon an der grenze." erzähl doch mal näher, warum der AVR das nicht können soll. Einen Nachteil haben die AVRs natürlich, daß es keine Interruptprioritäten gibt. Es darf also keine langsamen Interrupts geben. Absolut alle Interrupts müssen so schnell sein, daß sie den eiligsten nicht ausbremsen. Aber das ist keine Frage ob 8 oder 16 Bit, die meisten 8051-er haben ja auch 4 Interruptprioritäten. Peter
Hatte schon viele Anwendungen, wo man einen I2C bus mitsniffert und da war der AVR einfach an der grenze. der hatte nix anderes zu tun, als auf high/low zu warten und zu bewerten. am ende auf rs232 ausgeben. bei 16mhz lief es gerade so. was wenn man mal was schnelleres mitschneiden will, oder mehr flash benötigt? Gibt es nun basic ähnliche interpreter für arm und v850??
"probier mal spasseshalber 'ne zeitzmessung für die anweisungen "incr x" in c und bascom. guckst du - ausführungstempo gleich. was schliessen wir daraus? sowohl c als auch bascom als hochsprache werden perfekt in den korrekten, minimal notwendigen, maschinencode compiliert." Nein, daraus kannst du höchstens schließen dass beide für "incr x" den minimal notwendigen Code erzeugen - was leider überhaupt nichts aussagt. Interessanter wäre ein Vergleich bei echten Algorithmen, z.B. Samplen eines Pins, ein Filter mit Ringpuffer, Entprellung eines Drehgebers, usw.
Rolfi: Basic wird überwiegend im Hobbybereich verwendet, und da sind "größere" Prozessoren noch eher selten anzutreffen. Deshalb glaube ich nicht dass du einen brauchbaren Compiler findest.
Hallo, bin vor wenigen Wochen auf PureBasic gestossen.... schaut es Euch mal an. Mache damit Programme, welche unter XP tadelos laufen !!! Alles Gute von Jürgen....
Wobei ich jetzt einfach mal behaupt, dass XP nicht auf den Prozessoren läuft, um die es hier geht
Hi, Hatte schon viele Anwendungen, wo man einen I2C bus mitsniffert und da war der AVR einfach an der grenze. der hatte nix anderes zu tun, als auf high/low zu warten und zu bewerten. am ende auf rs232 ausgeben. bei 16mhz lief es gerade so. Wenn du so programmierst sollte das kein Wunder sein. Da nützt auch ein größerer Prozessor nichts, wenn man 99,9 % seiner Rechenzeit damit zubringt auf eine Flanke zu warten. Dazu benuzt man externe flankengetriggerte Interrupts, mit denen man soetwas effizient machen kann ohne irgendwelche Schleifen zu verwenden ,die nur dazudienen, die Hauptschleife auszubremsen. Unterstuezt Bascom überhaupt Interrupts? Gruß Tobias
@Rolfi "Hatte schon viele Anwendungen, wo man einen I2C bus mitsniffert und da war der AVR einfach an der grenze." Na dann wirst Du aber mit dem ARM Dein blaues Wunder erleben, der könnte sogar noch langsamer sein. Schon ein simpler Interrupteintritt ist mit riesen Getöse verbunden. Lies Dir mal hier die ARM-Threads durch. Beim Bitschubsen ist er warlich keine Leuchte. Nur wenn Du zich MByte RAM ansprechen willst oder haufenweise 32Bit-Berechnungen hast, dann kann er punkten. Meine Frage, wobei Du Dir bei nem 32-Bitter Vorteile versprichst, habe ich schließlich nicht aus Jux gestellt. Für nen I2C-Sniffer nimm einfach den ATTiny2313. Der hat ein halbes Hardware-I2C ohne Adreßerkennung, damit kannst Du ganz einfach jedes I2C-Paket mitlesen. Und der kommt auch bei 400kHz nicht ins Schwitzen. Peter
@ tobias aber sicher unterstützt bascom interrupts, warum denn auch nicht? int's sind ja eine reine hardwarenummer, ein prog muss doch nur auf ein sich ändernders flag reagieren. der basiccode lässt sich ja auch wunderschön mischen, willst du's bequem weil du ein fauler mensch (wie ich) bist, nimmst du den basic-kruscht, brauchst du das 'richtige leben' läuft der kram eben direkt über register oder asm ab, is' doch herrlich. zu pure-basic: mir ist selten ein effizienterer compiler untergekommen, maxi-leistung bei mini-exe's bei mini-code, klasse. grüssens, harry
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.