mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Basic für größere prozessoren


Autor: Rolfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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

Autor: harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Rolfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: Andreas Schwarz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Rolfi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das thema des threads?

Autor: Andreas Schwarz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wobei ich jetzt einfach mal behaupt, dass XP nicht auf den Prozessoren
läuft, um die es hier geht

Autor: Tobias Schneider (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

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.