Forum: Mikrocontroller und Digitale Elektronik uC - kennst du einen, kennst du alle


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von bloody_beginner (Gast)


Bewertung
-10 lesenswert
nicht lesenswert
Hallo.
Ich wollte mal fragen ob es stimmt, dass es relativ egal ist mit welchem 
Mikrocontroller man anfängt, solange es kein Arduino ist, da wenn man 
einen uC wirklich verstanden hat, es relativ einfach ist sich in andere 
einzuarbeiten.
Würdet ihr das so unterschreiben?

Wie lange braucht ihr um euch in einen neuen uC einzuarbeiten?

Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger 
heutzutage raten anzufangen?

Habe Elektrotechnik und Softwaretechnik Kenntnisse, könnte also sofort 
damit anfangen.

von Joachim B. (jar)


Bewertung
7 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> könnte also sofort
> damit anfangen.

wer hindert dich?

von Arduino Fanboy D. (ufuf)


Bewertung
10 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> solange es kein Arduino ist
Seltsame Einschränkung!
Denn es gibt keinen Arduino µC!

bloody_beginner schrieb:
> Wie lange braucht ihr um euch in einen neuen uC einzuarbeiten?

1/2 Jahr, bis 1 Jahr.
So ca. und ohne Gewähr, da stak abhängig von Type und Vorwissen.

von Erich D. (Gast)


Bewertung
7 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Ich wollte mal fragen ob es stimmt, dass es relativ egal ist mit welchem
> Mikrocontroller man anfängt, solange es kein Arduino ist

Der Arduino ist aber kein µC.
Auf einer Platine namens Arduino können verschiedene µC sitzen.

von bloody_beginner (Gast)


Bewertung
-7 lesenswert
nicht lesenswert
Bevor ich meine Frage gestellt habe, habe ich natürlich schon hier im 
Forum recherchiert und bin oftmals auf die Aussage gestoßen, dass man 
eine Abschlussarbeit bei der ein Arduino verwendet wurde, nicht ernst 
nehmen kann oder dass man sofort mit einem "uC" anfangen sollte.
Ok, Arduinos sind keine uC's, könnte man sie dann Launchpads nennen?
Ich dachte bis jetzt immer: uC = uP + Peripherie, also dass sie quasi 
wie ein Entwicklungsboard sind.

Joachim B. schrieb:
> bloody_beginner schrieb:
>> könnte also sofort
>> damit anfangen.
>
> wer hindert dich?

Niemand, ich möchte nur nicht "blind" damit anfangen. Beim 
Programmierenlernen war ich z.B. so dumm und wollte mit C++ und 
Assembler anfangen, hat nicht so recht geklappt. Hätte ich damals im 
Forum nachgefragt bevor ich damit gestartet hätte, dann wäre mir dieser 
Fehler wahrscheinlich erspart geblieben.

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
bitte nicht schon wieder. Suche hier nach 'Arduino Einsteiger' und du 
bekommst genug zu lesen für den kommenden Winter. Zuletzt noch hier:
Beitrag "AVR oder STM32 für Entwicklungsprojekt"

von bloody_beginner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:

> 1/2 Jahr, bis 1 Jahr.
> So ca. und ohne Gewähr, da stak abhängig von Type und Vorwissen.

Wenn ich fragen darf, wie kann man sich die Einarbeitung vorstellen?
Du bist ja während der Einarbeitung schon produktiv, nehme ich an.
Muss man dann übertrieben oft im Datenblatt nachschauen, während man 
sein Projekt realisiert und kämpft mit Bugs, die daher rühren dass man 
die Architektur noch nicht versteht?

Eine Masterarbeit dauert z.B. 6 Monate, wäre es realistisch in dieser 
Zeit ein mikrocontrollerbasiertes Projekt zu erstellen, zu einem uC den 
man noch nicht kennt, wenn man Vorwissen mitbringt?

von spess53 (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Hi

>war ich z.B. so dumm und wollte mit C++ und
>Assembler anfangen, hat nicht so recht geklappt.

Welcher Teil hat nicht geklappt?

MfG Spess

von bloody_beginner (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
spess53 schrieb:
> Hi
>
>>war ich z.B. so dumm und wollte mit C++ und
>>Assembler anfangen, hat nicht so recht geklappt.
>
> Welcher Teil hat nicht geklappt?
>
> MfG Spess

Assembler für Desktopanwendungen zu lernen war ziemlich hirnrissen :/

C++ beherrsche ich mittlerweile, aber so richtig bin ich ins 
Programmieren dann erst mit Java eingestiegen. Die Fehlermeldungen 
aufgrund von Templates und co. sind in C++ einfach nicht 
anfängerfreundlich.

von Alex G. (dragongamer)


Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Hi
>
>>war ich z.B. so dumm und wollte mit C++ und
>>Assembler anfangen, hat nicht so recht geklappt.
>
> Welcher Teil hat nicht geklappt?
>
> MfG Spess
Und vorallem welche Sprache wäre weniger dumm gewesen?
Willst du nur auf den "Mittelweg zwischen Asm und C++" hinaus: C?
Wenn die Aufgabe einfach ist, sieht C++ praktisch aus wie C, daher würde 
die Aussage eher wenig Sinn machen.


EDIT:
bloody_beginner schrieb:
> Assembler für Desktopanwendungen zu lernen war ziemlich hirnrissen :/
>
> C++ beherrsche ich mittlerweile, aber so richtig bin ich ins
> Programmieren dann erst mit Java eingestiegen. Die Fehlermeldungen
> aufgrund von Templates und co. sind in C++ einfach nicht
> anfängerfreundlich.
Jetzt sind wir aber weg von Mikrocontrolern, oder?
Ja, java ist schlicht anders als C und C++ und erst recht als Asembler.
Ist auch eine meiner Lieblingssprachen. Aber für uC verfügbar ist sie 
halt leider nicht.

Wenn man uCs programmieren will, muss man bereit sein zu leiden ;)
Hardwarenahes Zeug ist harter Tobak. Dafür hat dieser Bereich einfach 
Vorteile die man mit PCs wo Java und Co. läuft, prinzipiell nicht 
bewerkstelligen kann.


Studierst du irgendein allgemeineres Feld der Softwareentwicklung?
Also Software für Desktops und Server?
Wenn ja, würde ich nicht empfehlen als Abschlussarbeit, jetzt in den 
Mikrocontroelrbereich einzusteigen, auchw enn du hobbymäßig Erfahrung 
mit Elektronik haben solltest.
Es gibt schlicht andere Studiengänge für die so eine Arbeit viel eher 
angebracht wäre.

: Bearbeitet durch User
von Marc (Gast)


Bewertung
3 lesenswert
nicht lesenswert
bloody_beginner (Gast)
>Bevor ich meine Frage gestellt habe, habe ich natürlich schon hier im
>Forum recherchiert und bin oftmals auf die Aussage gestoßen, dass man
>eine Abschlussarbeit bei der ein Arduino verwendet wurde, nicht ernst
>nehmen kann oder dass man sofort mit einem "uC" anfangen sollte.

Geht so. Wenn Du so was hier als Abschlussarbeit machst, kommst Du auch 
mit dem Arduino durch:
https://en.wikipedia.org/wiki/ArduSat

von bloody_beginner (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Alex G. schrieb:
> Jetzt sind wir aber weg von Mikrocontrolern, oder?
> Ja, java ist schlicht anders als C und C++ und erst recht als Asembler.
> Ist auch eine meiner Lieblingssprachen. Aber für uC verfügbar ist sie
> halt leider nicht.
>
> Wenn man uCs programmieren will, muss man leider bereit sein zu leiden
> ;)
> Hardwarenahes Zeug ist harter Tobak. Dafür hat dieser Bereich einfach
> Vorteile die man mit PCs wo Java und Co. läuft, prinzipiell nicht
> bewerkstelligen kann.

Ja, das bezog sich nur auf die Frage "welcher Teil an meinem damaligen 
Vorhaben dumm gewesen ist". Also hätte ich im Forum nachgefragt, hätte 
mir wohl niemand ernsthaft empfohlen Assembler zu lernen, wenn ich 
Desktopanwendungen schreiben will. Bin auf die Idee gekommen wegen einem 
Artikel in dem Assembler hoch gelobt wurde, als die schnellst Sprache 
die nur echte Freaks beherrschen.. Aber lassen wir das :)

Bin davon ausgegangen die uC's in C zu programmieren.

von bloody_beginner (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Ich studiere Elektrotechnik aber habe bis jetzt noch nie einen uC 
angefasst.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Ich wollte mal fragen ob es stimmt, dass es relativ egal ist mit welchem
> Mikrocontroller man anfängt, solange es kein Arduino ist, da wenn man
> einen uC wirklich verstanden hat, es relativ einfach ist sich in andere
> einzuarbeiten.

Die verwendeten Prinzipien und Konzepte sind schon ähnlich, vor allem 
bei den µCs aus einer Ära. Aber zwischen einem alten PIC10 und einem 
aktuellen Cortex-H7 gibt es schon deutliche Unterschiede...

> Wie lange braucht ihr um euch in einen neuen uC einzuarbeiten?

Das hängt auch sehr davon ab wie tief Du da einsteigen willst.

Geht es nur darum, ein Programm sequentiell ablaufen zu lassen und ein 
bischen die Peripherie zu bedienen?

Oder willst Du Dein eigenes RTOS für den µC implementieren? Dann kämen 
zu der Peripherie noch die ganzen Details der Architektur hinzu, mit 
Interrupt-Prioritäten, verschiedenen Speicherbereichen, 
Speicherschutz,... - aktuelle ARM-Cortexe haben da schon ne ganze Menge 
Features wenn man mal etwas tiefer graben geht.

Für die meisten Projekte muss man aber nicht jede "dunkle Ecke" des µCs 
detailliert kennen.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Muss man dann übertrieben oft im Datenblatt nachschauen,

2 Monitore
Links das Datenblatt und sonstige Dokumentationen.
Rechts die IDE.
Ob das Übertreiben ist, überlasse ich deinem fachkundigen Urteil.

bloody_beginner schrieb:
> Du bist ja während der Einarbeitung schon produktiv, nehme ich an.
Wenn ich produktiv sein will/muss, nehme ich bekanntes.

bloody_beginner schrieb:
> Wenn ich fragen darf, wie kann man sich die Einarbeitung vorstellen?

Ich nehme mir ein Teilgebiet, z.B. ADC, DMA, Timer, und arbeite es aus, 
bis ich es hinreichend weit durchdrungen habe.

: Bearbeitet durch User
von Alex G. (dragongamer)


Bewertung
0 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Sprache die nur echte Freaks beherrschen..
Und das hat dich nicht abgeschreckt? ;)

Naja, fürchte Arduino Fanboy da oben hat Recht. grade durch die 
Hardwarenähe, muss man einiges auf dem Chip gemacht haben um ihn zu 
durchschauen und das Beste raus zu holen.
Im Berufsleben wirst du zwangsläufig schon in dieser Phase Produktiv 
sein müssen weil Projekte da kurzlebiger sind, als bei PC Software. 
Dafür ist der Umfang oft auch nicht vergleichbar.

Für eine Abschlussarbeit würde ich ehrlich gesagt etwas empfehlen was du 
am PC (auch in C) simulieren kannst. Also nichts was von 
Hardwarefeatures zwingend abhängig ist (wie Kommunikationsprotokolle), 
denn die EInarbeitung dahin ist zu langwierig.

: Bearbeitet durch User
von bloody_beginner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> bloody_beginner schrieb:
>> Sprache die nur echte Freaks beherrschen..
> Und das hat dich nicht abgeschreckt? ;)

Naja, ich verweise mal auf den 
https://de.wikipedia.org/wiki/Dunning-Kruger-Effekt
Mittlerweile wäre ich natürlich abgeschreckt, aber damals habe ich mich 
komischweise angesprochen gefühlt :)



Gerd E. schrieb:
> Das hängt auch sehr davon ab wie tief Du da einsteigen willst.
>
> Geht es nur darum, ein Programm sequentiell ablaufen zu lassen und ein
> bischen die Peripherie zu bedienen?
>
> Oder willst Du Dein eigenes RTOS für den µC implementieren?

von bloody_beginner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Alex G. schrieb:
>> bloody_beginner schrieb:
>>> Sprache die nur echte Freaks beherrschen..
>> Und das hat dich nicht abgeschreckt? ;)
>
> Naja, ich verweise mal auf den
> https://de.wikipedia.org/wiki/Dunning-Kruger-Effekt
> Mittlerweile wäre ich natürlich abgeschreckt, aber damals habe ich mich
> komischweise angesprochen gefühlt :)
>
> Gerd E. schrieb:
>> Das hängt auch sehr davon ab wie tief Du da einsteigen willst.
>>
>> Geht es nur darum, ein Programm sequentiell ablaufen zu lassen und ein
>> bischen die Peripherie zu bedienen?
>>
>> Oder willst Du Dein eigenes RTOS für den µC implementieren?

Also eher ersteres :)

Aber irgendwann muss man ja mal anfangen. Wenn nicht bei der 
Abschlussarbeit, dann ja im Beruf. Aber ich denke dann wäre es doch 
sicherlich besser schon in der Abschlussarbeit damit anzufangen. Wenns 
dann halt keine 1,0 wird, sondern eine 2,0, könnte ich auch noch damit 
leben.

von Michael B. (laberkopp)


Bewertung
3 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Wie lange braucht ihr um euch in einen neuen uC einzuarbeiten?

Kommt drauf am: Wie gut ist der Herstellersupport, gibt es Beispiele 
oder wurde absichtlich alles vercryptet dokumentiert damit man es auf 
die mühsame Art meistern muss, von Fehler zu Fehler.

> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger
> heutzutage raten anzufangen?

Arduino.

Nein, nicht wirklich, dessen Doku ist auch unter aller Sau, die 
Imkompatibilitäten (unterschiedlicher "Arduinos") schrecklich und ebenso 
undokumentiert, ausserdem macht ihn die Software schnarchlangsam und die 
IDE ist rudimentär.

8051 ?

Hat man wenigstens am meisten von, jeden besonders ausgestatteten uC 
gibt es zunächstmal immer mit 8051 Kern. Braucht man LCD mit 
Niedrigstrom 8051, braucht man Hochstrom SH79F3212, braucht man 12V 
Versorgungsspannung HVC22xyA, 24 bit A/D ADUC824, 200MHz TSCR8051L, 
braucht man Hochtemperatur bis 300 GradC HT83C51, das alles gibt es bei 
anderen uC-Familien nicht, billig für 5ct PMS150C, ausser man braucht 
einen uC der ab 0.25V läuft: EtaCore M3, der stammt nicht aus der 
8051-Familie sondern ARM-Familie, ein 8051 braucht 0.9V C8051F90. 
Allerdings ist 8051 nicht wirklich gut in C zu programmieren und auch 
nicht in Assembler.

ARM ?

Gerade ST mit seinen Cortex hat viele ARM Prozessoren, und die lassen 
sich ordentlich in C programmieren: Aber: Die Peripherie ist aufwändig 
und komplizierter, für Anfänger nicht so doll. Selbst wenn man sie 
Arduino-Style programmiert, sind die Inkompatibilitäten schwere 
Stolpersteine.

6805 ?

Solider von Neumann Prozessor, gut dokumentiert 
http://www.nxp.com/assets/documents/data/en/reference-manuals/M68HC05TB.pdf 
, leider alt.


Letzlich empfehle ich die AVR Famile über Atrmel Studio zu 
programmieren.

: Bearbeitet durch User
von Alex G. (dragongamer)


Bewertung
0 lesenswert
nicht lesenswert
Ja, wohl wahr. Wundert mich dass das noch nirgends im Studium gefordert 
war...
Da lob ich mir die Hochschule im vergleich zur Uni.


Aber das bringt uns zurück zu Joachim's Frage: Was hindert dich daran 
anzufangen?
Oder was spielt den Deine Frage bezüglich vergleichbarkeit für eine 
Rolle?
Du musst dich schließlich mit uCs befassen. So oder so.
Nur wenn du richtung Consulting gehst, kannst du vieleicht den 
Programmierteil umgehen...

: Bearbeitet durch User
von Andreas K. (andreas_k209)


Bewertung
0 lesenswert
nicht lesenswert
Früher hätte ich Dir einen C64/Amiga empfohlen - da habe ich Basic und 
Assembler mit "gelernt". Aber diese Zeiten sind lange vorbei.

Ansich bietet die Arduinoplattform einen schönen Einstieg (nur die kenne 
ich). Die Atmel-AVRs kann man auch mit Assembler füttern. Letztendlich 
fällte nach dem Compilieren eh eine Binärdatei an die auf den uC geladen 
wird.

Zu Deinen Fragen: "uC Egal?" ja, sind ähnlich.

"Einarbeitung?": Atmel-AVR (Arduino) für kleine Projekte: ein 
Wochenende.

Ich würde was kleines nehmen. Bei größere uC würde ich die eher in eine 
Hochsprache programmieren (MicroPython hatte ich mir auch mal 
angesehen).


"Anfangen mit?": Arduino-Plattform ;-)

Das wichtigste ist ein Ziel zu haben, der Rest geht wie von selbst. Ich 
hatte damals am C64 Relays ansteuern wollen und Grafik gemacht 
(Rasterbars, 3D-Strichgrafik).

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Aber irgendwann muss man ja mal anfangen. Wenn nicht bei der
> Abschlussarbeit, dann ja im Beruf.

Oder eben einfach mal privat, als kleine Bastelei.

Arduinos kann man übrigens auch ohne die Arduino-IDE und deren Framework 
benutzen. Dann ist das, was übrig bleibt, ein gut handhabbares 
Controller-Experimentierboard mit bisschen drumrum 
(Programmierschnittstelle bspw.).

Vorteil der kleineren AVRs, wie sie auf vielen Arduinos zu finden sind 
ist, dass die Hardware immer noch einigermaßen überschaubar ist. Von da 
auf einen größeren umzusteigen, dürfte leichter fallen, als gleich mit 
einem Cortex-M7 anzufangen, dessen Referenzhandbuch 2000+ Seiten 
umfasst.

von Alex G. (dragongamer)


Bewertung
0 lesenswert
nicht lesenswert
Michael B. schrieb:
> Arduino.
>
> Nein, nicht wirklich, dessen Doku ist auch unter aller Sau, die
> Imkompatibilitäten (unterschiedlicher "Arduinos") schrecklich und ebenso
> undokumentiert, ausserdem macht ihn die Software schnarchlangsam und die
> IDE ist rudimentär.
Das ist jetzt aber sehr hart ausgedrückt.
Den Grad an Kompatibilität, den Arduino erlaubt, als zu niedrig zu 
bewerten ist blödsinnig.
Dort hat man wenigstens die Chance, seinen Code mit wenig Anpassungen, 
auf einen anderen uC zu protieren.
Bei all deinen genannten Beispielen ist das nicht der Fall.

Was bleibt ist, dass man mit Arduino nicht so in die "Tiefe" gehen kann. 
Deswegen ist er was für Hobbyprojekte und selten in der Industrie 
anzutreffen wobei selbst die Industrie ihn zum Prototyping einsetzt. 
Seine Brötchen damit zu verdienen ist nicht ausgeschlossen.

von bloody_beginner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> Für eine Abschlussarbeit würde ich ehrlich gesagt etwas empfehlen was du
> am PC (auch in C) simulieren kannst. Also nichts was von
> Hardwarefeatures zwingend abhängig ist (wie Kommunikationsprotokolle),
> denn die EInarbeitung dahin ist zu langwierig.

Meinst du mit Kommunikationsprotokollen sowas: 
https://de.wikipedia.org/wiki/Serial_Peripheral_Interface
?

von Alex G. (dragongamer)


Bewertung
0 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Alex G. schrieb:
>> Für eine Abschlussarbeit würde ich ehrlich gesagt etwas empfehlen was du
>> am PC (auch in C) simulieren kannst. Also nichts was von
>> Hardwarefeatures zwingend abhängig ist (wie Kommunikationsprotokolle),
>> denn die EInarbeitung dahin ist zu langwierig.
>
> Meinst du mit Kommunikationsprotokollen sowas:
> https://de.wikipedia.org/wiki/Serial_Peripheral_Interface
> ?
Ja, SPI, I2C, 1-Wire und Canbus sind so die bekanntesten.
Darüber werden auch gern Abschlussarbeiten geschrieben auch wenn es 
eigentlich Redundant ist weil die schon so oft implementiert wurden (oft 
auch schon in Hardware).

von Christian S. (roehrenvorheizer)


Bewertung
0 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Arduino Fanboy D. schrieb:
>
> 1/2 Jahr, bis 1 Jahr.
> So ca. und ohne Gewähr, da stak abhängig von Type und Vorwissen.
>
> Wenn ich fragen darf, wie kann man sich die Einarbeitung vorstellen?
> Du bist ja während der Einarbeitung schon produktiv, nehme ich an.
> Muss man dann übertrieben oft im Datenblatt nachschauen, während man
> sein Projekt realisiert und kämpft mit Bugs, die daher rühren dass man
> die Architektur noch nicht versteht?
>


Schau mal hier rein und entscheide, ob Du damit zurecht kommst:

http://www.avr-asm-tutorial.net/

https://s-huehn.de/elektronik/

http://www.sprut.de/electronic/pic/index.htm

https://www.microchip.com/wwwproducts/en/ATtiny2313#datasheet-toggle


mfG

von Michael B. (laberkopp)


Bewertung
-2 lesenswert
nicht lesenswert
Alex G. schrieb:
> Das ist jetzt aber sehr hart ausgedrückt.

Die Realität kann manchmal hart sein, vor allem für Leute die die 
Realität nicht sehen wollen.

von Axel S. (a-za-z0-9)


Bewertung
-1 lesenswert
nicht lesenswert
Alex G. schrieb:
> Michael B. schrieb:
>> Arduino.
>>
>> Nein, nicht wirklich, dessen Doku ist auch unter aller Sau, die
>> Imkompatibilitäten (unterschiedlicher "Arduinos") schrecklich und ebenso
>> undokumentiert, ausserdem macht ihn die Software schnarchlangsam und die
>> IDE ist rudimentär.

> Das ist jetzt aber sehr hart ausgedrückt.

Es ist die Wahrheit. Die mag manchem bitter schmecken.

> Den Grad an Kompatibilität, den Arduino erlaubt, als zu niedrig zu
> bewerten ist blödsinnig.

Arduino mit µC zu vergleichen ist blödsinnig. "Arduino lernen" ist 
ungefähr wie "den Taxischein machen". "µC lernen" ist dann eher "ein 
Auto einmal komplett in Einzelteile zerlegen und wieder zusammenbauen 
können und es fährt immer noch". Hat zwar beides irgendwie mit Autos zu 
tun, aber das eine Mal bleibt man halt ganz an der Oberfläche.

> Dort hat man wenigstens die Chance, seinen Code mit wenig Anpassungen,
> auf einen anderen uC zu protieren.

Auf einen anderen Arduino. Was nur heißt, daß die eigentliche Portierung 
von jemand anderem gemacht wurde.

> Was bleibt ist, dass man mit Arduino nicht so in die "Tiefe" gehen kann.
> Deswegen ist er was für Hobbyprojekte und selten in der Industrie
> anzutreffen wobei selbst die Industrie ihn zum Prototyping einsetzt.
> Seine Brötchen damit zu verdienen ist nicht ausgeschlossen.

Klar. Nur sind das halt ganz verschiedene Berufe. So wie Taxifahrer und 
Kfz-Mechaniker.

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> Was bleibt ist, dass man mit Arduino nicht so in die "Tiefe" gehen kann.
Das bezweifle ich.
Man muss nicht unbedingt in die Tiefe gehen, um zu Ergebnissen zu 
kommen.
Ja.
Aber eine Grenze/Beschränkung legt es einem nicht auf.

Bedenke:
Manchmal sind Behauptungen so dermaßen falsch, dass noch nicht mal das 
Gegenteil richtig ist.

: Bearbeitet durch User
von Wegstaben V. (wegstabenverbuchsler)


Bewertung
4 lesenswert
nicht lesenswert
@bloody_beginner

bist du denn "algorithmisch" fit?

wie tief du in uC  einsteigen möchtest ist dir selbst überlassen. Ob du 
in "Hochsprache" oder eher in Assembler programmieren möchtest, hängt 
sicherlich von deinen Zielen und Vorstellungen ab.


Überlege dir folgende Übungs-Aufgabe (und "baue" sie nach)

Mach eine "reverse Engineering" eines Fahrrad-Tachos. Kauf dir einen für 
5 EUR (vielleicht hast du einen) und baue ihn nach. Da sind ein paar 
Anzeigen-Segmente, ein paar Tasten, ein Impulsgebr ... das wars schon. 
Die Funktion eines solchen Tachos ist vollständig beschrieben, es gibt 
also eigentlich nichts "unbekanntes" an solch einem Teil .

Nun versuche, die Software nachzubauen, d.h. zu beschreiben. 
Menueführung mit irgendwelchen Tastendrücken, Uhrzeit, Geschwindigkeit, 
zurückgelegte Strecke, Kalorienverbrauch, ...)

Du wirst auf dieser Reise mit Interupt-Routinen, Statemaschinen, 
zweckmäßigen (=kompakten) Arithmetik-Operationen und ähnlichen 
konfrontiert.

Wenn du das ganze in einer Metasprache formulieren kannst, prima. Setze 
es dann um in einer "Hochsprache" (z.B. C), und wenn du dir richtig die 
Kante geben möchtest, dann beschreibe das ganze in Assembler deines uC.

Wenn du damit durch bist, dann bist du schon ziemlich weit gekommen.

Dann kannst du dich mit deiner Master-Arbeit beschäftigen, und das 
Methodenwissen auf "unbekannten" Gebiet (z.B. die Lageregelung einer 
Kugel, welche im Magnetfeld schwebt) anwenden.

: Bearbeitet durch User
von A. S. (achs)


Bewertung
4 lesenswert
nicht lesenswert
Nim irgend etwas, was da ist und mindestens 1 LED hat. Das Demoboard von 
der Messe, das Standardprodukt Deiner Uni, oder das, was dein Nachbar 
hat.

Es ist egal, ob Du auf einem Hollandrad oder Mountainbike fahren lernst. 
Jeder ADC, jeder GPIO ist so verschieden, dass Du besser bis zur 
Abschlussarbeit schon Mal 3 Demoboard verschiedener Architekten (auch 
gern arduino) zum blinken gebracht hast, um Argumente anderer überhaupt 
verstehen zu können.

Und nein, auch nach 10 Jahren mit einem uC gibt es ganze Universen, die 
noch brach liegen, wenn es bisher keine Anwendung dafür gabt. Bei den 
einen ists capture compare, beim anderen adc-filter-modi, beim dritten 
DMA. Von speziellen Motorsteuergeräte-features wie Zündfunk Überwachung 
ganz zu schweigen. Und das geht bei der SW genauso weiter, von 
Linkerfragen über C++17-features zu Eclipse-einstellungen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Wegstaben V. schrieb:
> Mach eine "reverse Engineering" eines Fahrrad-Tachos.

Wobei man den Nachbau nun nicht gerade mit einem segmentweise 
anzusteuernden LCD machen sollte. Die sind schwer zu bekommen und werden 
eigentlich nur betrieben, indem man sie an speziell dafür vorbereitete 
Controller anschließt.

Für den Nachbau wäre es einfacher (und sinnvoller), ein 
Industriestandard-HD44780-LC-Display zu benutzen. Oder aber, man schafft 
sich, und steuert zeitmultiplex klassische LED-7-Segment-Anzeigen an. 
Das hat auch einen guten Lerneffekt.

von Michael B. (laberkopp)


Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
>> Was bleibt ist, dass man mit Arduino nicht so in die "Tiefe" gehen kann.
> Das bezweifle ich.

Du bist ja auch ein Arduino-Fanboy. Nennt man wohl betriebsblind.

Ja, das Gute ist: Man kann im Arduino-C-Sourcecode auch einfach den AVR 
(oder sonstigen Prozessor) direkt ansprechen, z.B. mit PORTB = 0xFF oder 
TIMSK = (1<<TOIE0).

Damit kommt man in die Tiefe. Es hat Ähnlichkeit, als ob man im 
C-Programm gewisse Routinen in Assembler schreibt, für mehr Tiefe, um 
eben Dinge erreichen zu können die in C nicht mehr gehen.

ABER: Das ist dann nicht mehr die Arduino-Schale, die ihn so berühmt 
gemacht hat, die Schale die einen abkapselt vor dem wirklichen 
Prozessor. Die will alles in Shields verpacken und nur über speziell 
(von anderen, wissenden Programmierern, die in die Tiefe gehen) 
geschriebene C++ Objekte ansprechbar haben.

Nur reine Arduino-Programme kann man portieren auf andere Arduinos 
anderer Prozessorfamilien. Leider geht in der Praxis nicht mal das.

: Bearbeitet durch User
von Manfred (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael B. schrieb:
>> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger
>> heutzutage raten anzufangen?
>
> Arduino.
>
> Nein, nicht wirklich, dessen Doku ist auch unter aller Sau, die
> Imkompatibilitäten (unterschiedlicher "Arduinos") schrecklich
> und ebenso undokumentiert, ausserdem macht ihn die Software schnarchlangsam und 
die IDE ist rudimentär.

Na ja ... es ist eine C++ Umgebung und damit eine Sprache, die in der 
Industrie umfassend eingesetzt wird.

Schnarchlangsam ist einfach Quatsch.

Die "rudimentäre IDE" bringt schon einmal alles mit, ein Kompilat zu 
erzeugen und in den Prof. zu spielen. Übel ist auf jeden Fall der 
Editor, aber da kann man problemlos einen ordentlichen Editor anbinden.

Falls es an Dir vorbei gegangen sein sollte: Auch in der Arduino-IDE 
kann man 'richtiges C++' einbinden und übersetzen.

> 6805 ?
> Solider von Neumann Prozessor, gut dokumentiert
> http://www.nxp.com/assets/documents/data/en/reference-manuals/M68HC05TB.pdf, 
leider alt.

Ein simpler Kern, wenn man Assembler programmieren möchte, mir noch gut 
bekannt.

> Letzlich empfehle ich die AVR Famile über Atrmel Studio zu
> programmieren.

Wo ist nun der große Unterschied, ob ich per Arduino-IDE den GCC 
übersetzen lasse oder er unter dem Atmel-Studio werkelt?

Jörg W. schrieb:
> Für den Nachbau wäre es einfacher (und sinnvoller), ein
> Industriestandard-HD44780-LC-Display zu benutzen.

Da wäre jetzt zu entscheiden, ob man eine fertige Library greift, das 
ist auch in kommerzieller Programmierung durchaus üblich, oder es von 
der Pike auf selbst erzeugt.

> Oder aber, man schafft sich, und steuert zeitmultiplex klassische 
LED-7-Segment-Anzeigen an.
> Das hat auch einen guten Lerneffekt.

Wie - in C++ oder auf Assemblerebene?

von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Michael B. schrieb:
> Damit kommt man in die Tiefe.
Also ist mein "betriebsblind" doch nicht so blind.

Oder anders:
Der Betreibsblinde sagt: Man kommt in die Tiefe!
Und der Kritiker bestätigt das.

Tipp, an dich:
Beschränkungen entstehen/existieren im Kopf.

: Bearbeitet durch User
von Wegstaben V. (wegstabenverbuchsler)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Wobei man den Nachbau nun nicht gerade mit einem segmentweise
> anzusteuernden LCD machen sollte.

Ich denke bei solchen Sachen eher "TopDown".

wenns ein Pixel-Display ist, dann ist es natürlich "ganz tief unten" 
anderes anzusteuern als eine 7-Segment Anzeige.

Die eigentliche "technische" Ansteuerung des Anzeige-Elements (einzelne 
Segmente, oder 7-Segment-Anzeigen, oder irgendwelche Pixel in einem 
Raster-Display) ist aber "ein wenig höher" im Programmablauf halt 
"einfach" irgend eine spezielle Ausgabe-Funktion welche man aufruft.

Wichtiger (und Vorarbeit) ist z.B. zu verstehen, dass man die Anzeige 
der ermittelten Größe "Geschwindigkeit"  und "Uhrzeit" im 
1-Sekunden_Wechsel auf der Anzeige darstellen soll, und die 
Geschwindigkeit (und Uhrzeit) im 1/10 Sekunden-Rythmus intern 
aktualisiert wird.

von Axel S. (a-za-z0-9)


Bewertung
3 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Alex G. schrieb:
>> Was bleibt ist, dass man mit Arduino nicht so in die "Tiefe" gehen kann.
> Das bezweifle ich.

Da hast du durchaus recht. Zum einen ist das Abstraktionslayer von 
Arduino ziemlich dünn und zum anderen auch sehr durchlässig. So kann man 
bspw. problemlos Direktzugriffe auf die Ports in den Code schreiben oder 
sogar eine Funktion main() in ein Sketch packen und damit die 
Arduino-main() überschreiben. Man könnte also in die Tiefe abtauchen.

Die Frage ist halt nur: wozu? Entweder stellt man sich auf den "Rainer 
Anwender" Standpunkt und will alles gemütlich und komfortabel haben. 
Dann will man gar nichts über main() oder Ports wissen. Ein Arduino 
hat "verdammt nochmal" Pins und die sind einfach durchnumeriert. Und 
mehr gibt es nicht zu wissen.

Oder du bist eher von der neugierigen Sorte. Nur warum solltest du dich 
dann überhaupt mit der rudimentären Arduino-IDE abgeben wollen, wenn du 
doch genauso Code::Blocks oder das AVR-Studio haben könntest. Mit einem 
Debugger und Syntax-Highlighting und kontextsensitiver Hilfe.

> Man muss nicht unbedingt in die Tiefe gehen, um zu Ergebnissen zu
> kommen.

Natürlich nicht. Wenn man nur Fahrgäste von A nach B bringen will, muß 
man nicht wissen, wie ein ABS funktioniert. Oder eine Lambdasonde. 
Andererseits gibt es jede Menge Leute, die gerade das deutlich 
spannender finden als die Frage, ob man vom Bahnhof zum Opernhaus besser 
durch Straße X oder durch Straße Y fährt.

von Michael B. (laberkopp)


Bewertung
-3 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Michael B. schrieb:
>> Damit kommt man in die Tiefe.
> Also ist mein "betriebsblind" doch nicht so blind.
> Oder anders:
> Der Betreibsblinde sagt: Man kommt in die Tiefe!
> Und der Kritiker bestätigt das.

Man kommt nur in die Tiefe, in dem man 'Arduino' um-geht.

> Tipp, an dich:
> Beschränkungen entstehen/existieren im Kopf.

Tip an dich:

Der Kopf ist auch für die Intelligenz da.

Wer sich Arduino-Fanboy nennt, aber keine Ahnung hat was Arduino 
kennzeichnet, ist einfach nur dumm.

Manfred schrieb:
> > ausserdem macht ihn die Software schnarchlangsam und die IDE ist rudimentär.

> Schnarchlangsam ist einfach Quatsch.

Schnarchlangsam beginnt damit, 8 bit eines value auszugeben:

for(bit=0;bit<8;bit++)
  digitalWrite(OUTPUTPIN0+bit,value&(1<<bit)?HIGH:LOW);

Das ist schnarchlangsam gegenüber einem PORTD=value;

Ja, das ist nicht so flexibel und portierbar, aber genau deswegen ist 
dieser Weg beim Arduino-Konzapt blockiert.

: Bearbeitet durch User
von Alex G. (dragongamer)


Bewertung
-1 lesenswert
nicht lesenswert
Michael B. schrieb:
> Schnarchlangsam beginnt damit, 8 bit eines value auszugeben:
>
> for(bit=0;bit<8;bit++)
>   digitalWrite(OUTPUTPIN0+bit,value&(1<<bit)?HIGH:LOW);
>
> Das ist schnarchlangsam gegenüber einem PORTD=value;
Bin mir ziemnlich sicher dass man dann eben so programmiert dass man 
nicht erstmal 8 verschiedene Outputs in eine einzelne variable rein 
pfercht...

Klar, es gibt sicher Fälle wo man solche Output Masken vorbelegen kann, 
um daraus wirklich nen Greschwindigkeitsvorteil zu ziehen.
Das ist aber seltener der Fall, als man vom Komfort profitiert, den 
digitalWrite ermöglicht.


Wir kommen langsam vom Thema ab...

von Agathe Bauer!!! (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger
> heutzutage raten anzufangen?

Mit gar keinem! Sonst bist du der Nächste, der zwar mit nem Controller 
zum Mond fliegen will, aber unglaublich dumme Fragen zur dennoch fast 
immer nötigen Analogtechnik stellt.

Hier im Forum finden sich vielleicht 5 threads, bei denen man jemandem 
zu einem µC raten sollte. Umgekehrt gibt es sicher 5.000.

von Arduino Fanboy D. (ufuf)


Bewertung
2 lesenswert
nicht lesenswert
Michael B. schrieb:
> Wer sich Arduino-Fanboy nennt, aber keine Ahnung hat was Arduino
> kennzeichnet, ist einfach nur dumm.

Nunja, du nennst dich "laberkopp"
Hat das keine Berechtigung?

Ja, du darfst mir "keine Ahnung" unterstellen.
Aber ob du damit richtig liegst, das Urteil, überlasse ich lieber 
anderen.

von bloody_beginner (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Agathe Bauer!!! schrieb:
> bloody_beginner schrieb:
>> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger
>> heutzutage raten anzufangen?
>
> Mit gar keinem! Sonst bist du der Nächste, der zwar mit nem Controller
> zum Mond fliegen will, aber unglaublich dumme Fragen zur dennoch fast
> immer nötigen Analogtechnik stellt.
>
> Hier im Forum finden sich vielleicht 5 threads, bei denen man jemandem
> zu einem µC raten sollte. Umgekehrt gibt es sicher 5.000.

Kann es sein das hier manche nur "auf Stress" aus sind?

Naja, an alle anderen: Danke für die Ratschläge.

Ich gehe dann mal schlafen :)

von Agathe Bauer!!! (Gast)


Bewertung
-6 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Kann es sein das hier manche nur "auf Stress" aus sind?

Keine Ahnung wen du meinst, ich habe nur gesagt, wie es tatsächlich 
aussieht. Wenn du solche Wahrheiten schon als stressig ansiehst, na dann 
wirklich gute Nacht...

von Gerhard O. (gerhard_)


Bewertung
4 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Agathe Bauer!!! schrieb:
>> bloody_beginner schrieb:
>>> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger
>>> heutzutage raten anzufangen?
>>
>> Mit gar keinem! Sonst bist du der Nächste, der zwar mit nem Controller
>> zum Mond fliegen will, aber unglaublich dumme Fragen zur dennoch fast
>> immer nötigen Analogtechnik stellt.
>>
>> Hier im Forum finden sich vielleicht 5 threads, bei denen man jemandem
>> zu einem µC raten sollte. Umgekehrt gibt es sicher 5.000.
>
> Kann es sein das hier manche nur "auf Stress" aus sind?
>
> Naja, an alle anderen: Danke für die Ratschläge.
>
> Ich gehe dann mal schlafen :)

Mal sehen ob Du wirklich schlafen gehst:-)

Auch wenn ich jetzt einen mißbilligendem Hurricane an Kritik auslöse, 
werde ich allen Unkenrufen zum Trotz für die ersten Schritte doch zum 
Arduino raten. Auch wenn es sich teilweise wie mit Windmühlenflügel zu 
kämpfen anfühlt:-)

Pro: Extrem billig Elektronik und narrensichere Installation. Man kann 
sofort loslegen. Installieren, einstecken und es ist "Ready for Action".

Da Arduino auf GCC als Toolchain aufgebaut ist, besteht der wesentliche 
Unterschied, daß beim Arduino die main() in einer eigenen Datei 
existiert und der Anwender im einfachsten Fall nur die Sketch Datei mit 
der "ino" Dateikennung. Für den Anwender existiert die traditionelle 
main Funktion lediglich in den zwei Funktionen setup und loop. Un diese 
wiederum befinden sich in einer versteckten main.cpp Datei. Neben ein 
paar Vereinfachungen (keine Funktion Prototypen im "ino" notwendig) kann 
man jetzt in stinknormalen C oder C++ loslegen.

Im einfachsten Fall belegt Arduino immer:
Timer0 als Zeitbasis für die millis() Funktion, PWM und den UART. Sonst 
kann man alles in normaler Weise durch direkten SFR Zugriff in gewohnter 
Weise beeinflussen und man ist nicht gezwungen Arduino Bibliotheken zu 
verwenden, wenn man nicht will. Bei den Serial Routinen fügt man sich am 
besten und verwendet die Serial.print Bibliothek. Ab diesen Zeitpunkt 
programmiert es sich im Arduino Umfeld auch nicht viel anders wie in 
nicht-Arduino Situationen.

Auch wenn die Arduino IDE von fast allen leuten von links bis rechts 
kritisiert wird(ob zu recht oder nicht, mag dahin gestellt sein), kann 
man durchaus zügig und effektiv damit arbeiten. Wie schon erwähnt 
funktioniert es auch mit externen Editor falls man so will. Ich habe das 
auch schon gemacht. Für kleinere Projekte mit nur einer ino Datei geht 
es auch in der Arduino IDE ganz zügig und bequem. Syntax Highlighting 
funktioniert ja und was will man Anfang wirklich mehr? Auch bei Arduino 
lohnt es sich zusammen mit dem Datenblatt/User Manual und App Notes zu 
arbeiten um nicht blind im Arduino Bibliotheken Kokon operieren zu 
müssen. Man hat ja mittels der SFR Register kompletten Zugang zur AVR 
Hardware und auch Inline-Assembler läßt sich einfügen. In der Hinsicht 
besteht wenig Unterschied zu anderen Entwicklungs Paradigmen.

Mein Rat: Probiers aus und bilde Dir Deine eigene Meinung. An 
garantierter Zuverläßigkeit und Billigkeit für den Anfang ist Arduino 
nicht überbietbar. Und man kann es sich so einfach oder kompliziert 
machen wie man will. 99% aller Real World Projekte lassen sich auch im 
Arduino Program Universum realisieren. Verfall nicht so wie viele in der 
berüchtigten "Analysen Paralyse". Go for it! Man muß nicht immer alles 
zu Tode diskutieren.

Für HW ausprobieren gibt es unzählige Bördchen in der Bucht mit denen 
mal viele Periphere Beschaltungen ohne großen Aufwand testen kann.

Später mit mehr Erfahrung kann man immer noch auf normale 
Entwicklungsumgebungen umsteigen.

Da gibt es ha noch viele andere Möglichkeiten, wie z.B. MSP430, STM32, 
um nur zwei zu nenen. Die Cortexen sind aber wesentlich anspruchsvoller 
in der Peripheriebenutzung.

Guck auch hier für Nützliches zum Thema:
https://www.mikrocontroller.net/articles/Mikrocontroller_Vergleich


Nur My two Cents worth...

: Bearbeitet durch User
von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
bloody_beginner schrieb:

> Also hätte ich im Forum nachgefragt, hätte
> mir wohl niemand ernsthaft empfohlen Assembler zu lernen, wenn ich
> Desktopanwendungen schreiben will.

Nicht einmal ich hätte das getan. Für kleine µC hingegen: auf jeden 
Fall.

> Bin auf die Idee gekommen wegen einem
> Artikel in dem Assembler hoch gelobt wurde, als die schnellst Sprache

Das ist so, zumindest potentiell. Allerdings: ein Anfänger wird es 
i.d.R. nicht schaffen, damit nennenswert schnelleren Code zu schreiben 
als ein guter C oder C++ Compiler liefert.

> die nur echte Freaks beherrschen..

So what? Es gibt auch nur vergleichweise wenige Leute, die wirklich C 
oder gar C++ umfassend beherrschen.

Diese Sprachen werden nur deswegen häufiger benutzt, weil man auch mit 
einer recht kleinen Teilmenge des Sprachumfangs noch Programme schreiben 
kann. Es sind dann beschissene, ineffiziente und häßliche Programme, 
aber, so lange sie das tun, was sie sollen...

von Frank K. (fchk)


Bewertung
1 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Hallo.
> Ich wollte mal fragen ob es stimmt, dass es relativ egal ist mit welchem
> Mikrocontroller man anfängt, solange es kein Arduino ist, da wenn man
> einen uC wirklich verstanden hat, es relativ einfach ist sich in andere
> einzuarbeiten.
> Würdet ihr das so unterschreiben?

Ja. Ich habe 1981 mit dem Z80 angefangen und ein halbes Jahr gebraucht, 
bis ich einigermaßen fit war. Für den nächsten, den 6502, habe ich dann 
nur noch 6 Wochen gebraucht, bis ich im Kopf assemblieren und Hexcode 
eintippen konnte.

Im Prinzip ist es egal, womit man anfängt.

fchk

von Niine (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger
> heutzutage raten anzufangen?

Mit einem 8-Bit PIC, zb. PIC16F18855


Begründung:

Arduino: Zu Abstrakt. Du weißt nicht was die eingebundenen Bibliotheken 
wildfremder Menschen machen und so richtig weißt du auch nicht was sonst 
noch so abgeht im Code. Arduino ist cool, aber nur für die ganz 
schnellen Frickelsachen.

AVR: Register direkt ansprechen und setzen, Datenblatt durchforsten, 
100x falsch konfiguriert bis es und du dann nach x-Stunden endlich 
deinen eigentlichen Code anfangen kannst zu schreiben.

PIC: Da gibt es in der MPLAB X IDE ein Add-on namens MCC (Microchip Code 
Configurator) und das funktioniert wirklich gut. Du kannst direkt alle 
Pins konfigurieren, alle Peripherals. Wie im AVR direkt als Register, 
kannst du dort deine Funktionen in Klartext konfigurieren. Beim USART 
zeigt er direkt die Fehlerrate an, beim ADC direkt die Conversion-Time. 
Und für jeden Ausgang gibts Abstraktere Funktionen wie RB3_toggle().
Timer, Interrupt Prioritäten, ADC, USART, SPI -> Alles schnell 
konfiguriert.
Der Code macht aber trotzdem genau nur das was du willst.


Fazit:
Der PIC bietet eine schöne Mitte zwischen AVR und Arduino und durch die 
angenehme Konfiguration einen frustfreien Start.
Protokolle, z.b. das Auslesen welchen Registers vom SPI eines Sensors, 
darfst du trotzdem selbst schreiben. Der MCC macht dir nur die 
allererste Konfiguration des Controllers.
Für eine Abschlussarbeit finde ich daher den PIC genau richtig.

VG Niine

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Würdet ihr das so unterschreiben?

Überwiegend ja, mit Ausnahmen. Die Arbeitsweise vom Parallax Propeller 
und den XMOS Typen ist recht anders.

von Marc (Gast)


Bewertung
2 lesenswert
nicht lesenswert
utor: Niine (Gast)
>Arduino: Zu Abstrakt. Du weißt nicht was die eingebundenen Bibliotheken
>wildfremder Menschen machen und so richtig weißt du auch nicht was sonst
>noch so abgeht im Code. Arduino ist cool, aber nur für die ganz
>schnellen Frickelsachen.

Du weißt es nicht? Was genau hindert Dich daran in den Code der 
Bibliotheken zu schauen?

von Joachim B. (jar)


Bewertung
2 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Ich studiere Elektrotechnik aber habe bis jetzt noch nie einen uC
> angefasst.

tja und?
kaufe einen ATmega 328p stecke den aufs Breadboard und du hast ihn 
angefasst.

Vor dem Studium E-Technik hatte ich das zwar schon gemacht (6502 / Z80) 
auch etwas programmiert, ASM und Basic (upps, böses Wort)

Im Studium mit µC LH5803 & C angefangen, war ein klacks (jedenfalls die 
Anfängerversion)

Jeder Weg beginnt mit dem ersten Schritt.

von Peter D. (peda)


Bewertung
6 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Ich wollte mal fragen ob es stimmt, dass es relativ egal ist mit welchem
> Mikrocontroller man anfängt, solange es kein Arduino ist, da wenn man
> einen uC wirklich verstanden hat, es relativ einfach ist sich in andere
> einzuarbeiten.
> Würdet ihr das so unterschreiben?

Nein.
Am Arduino-Konzept ist prinzipiell nichts auszusetzen. Es zwingt einen 
nicht, schlechte Programme zu schreiben. Es erleichtert dem Anfänger 
aber den Einstieg.
Jeder ist für seinen Programmierstil selber verantwortlich, die IDE kann 
überhaupt nichts dafür.

Die ARM sind einen erheblichen Zacken komplexer als die AVRs, daher ist 
der Einstieg damit mit Hürden gepflastert. Die Einarbeitungszeit ist 
deutlich höher.
Auch sind die Erratasheets oft sehr lang und enthalten wirklich 
kritische Bugs, z.B. beim LPC435X:
"Specifically, writes to I2C0, MCPWM, and I2S can affect C_CAN1. Writes 
to I2C1, DAC, ADC0, and ADC1 can affect C_CAN0."
Und man erlebt auch Überraschungen, die man von einfacheren MCs nicht 
gewohnt ist. Ein Kollege wollte das SPI mit Bitbanging benutzen, statt 
erst den Haufen SPI-Doku durcharbeiten zu müssen. Leider ist aber der 
SCK-Pin nicht als Output verfügbar, also geht nur HW-SPI.
Man kann sich auch nicht die Arbeit erleichtern und ungeprüft fremde 
Codebeispiele übernehmen. Z.B. hatte der Kollege Probleme mit dem CAN. 
Nach langer Suche stellte sich heraus, daß der Takt des CAN-Controllers 
zu hoch konfiguriert war.

Alles in allem halte ich daher die ARM nicht für Anfänger tauglich.

von Clemens L. (c_l)


Bewertung
0 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> wenn man einen uC wirklich verstanden hat, es relativ einfach ist sich
> in andere einzuarbeiten.

Jeder Hersteller verbaut andere Peripherie-Module. Die grundlegenden 
Konzepte sind die selben, die Details nicht.

Peter D. schrieb:
> Die ARM sind einen erheblichen Zacken komplexer als die AVRs

Was eigentlich nichts mit der CPU selbst zu tun hat. Der MSP432 
kombiniert eine ARM-CPU mit der 'guten alten' MSP430-Peripherie; gibt es 
so etwas auch von anderen Herstellern?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Niine schrieb:
> PIC: Da gibt es in der MPLAB X IDE ein Add-on namens MCC (Microchip Code
> Configurator) und das funktioniert wirklich gut. Du kannst direkt alle
> Pins konfigurieren, alle Peripherals.

Oh Gott, bloß nicht noch sowas ins Spiel bringen. :-o

Solche Codegeneratoren gibt es mittlerweile wohl so ziemlich für jeden 
Controller, das ist also erstmal gar kein Argument "pro PIC". Aber: 
damit lernt man nicht, einen Controller zu verstehen und zu 
programmieren, und beim nächsten Controller mit Codegenerator Y des 
Herstellers Z ist gleich mal wieder alles ganz anders.

Mithin so ziemlich der schlechteste Ratschlag für einen Einstieg, sowas 
zu benutzen. Dann ist ja das Arduino-Framework noch eher zu empfehlen, 
da hat man wenigstens eine riesige Community, die man fragen kann. 
(Allerdings würde ich dem TE dennoch eher "bare metal" empfehlen statt 
Arduino-Framework. Da lernt man mehr.)

von Stefan ⛄ F. (stefanus)


Bewertung
1 lesenswert
nicht lesenswert
"Kennst du einen - kennst du alle" trifft auf jeden Fall nicht zu.

Aber: Wenn man einen kennengelernt hat, fällt es meisten nicht sehr 
schwer, einen weiteren dazu zu lernen, weil es viele Gemeinsamkeiten 
gibt.

Wenn man in einer Hochsprache programmiert, sind viele Details gut 
abstrahiert so dass man sich mit dem CPU Kern eher selten bis gar nicht 
auseinander setzen muss. Dann kann man sich direkt auf die I/O 
Schnittstellen konzentrieren.

> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger
> heutzutage raten anzufangen?

Wenn du schnelle Erfolge brauchst, dann die AVR Serie (z.B. ATmega328P 
auf Arduino-Nano Board), ansonsten etwas mit ARM Cortex M3 oder M4 drin 
(z.B. STM32F103C8T6 auf Blue-Pill Board oder STM32F103RBT6 auf Nucleo-64 
Board).

Wir reden hier von rund 350 Seiten Lesestoff versus 2500 Seiten. Klingt 
krass, aber man muss ja nicht alles auf einmal Lesen und kann erstmal 
mit Tutorials anfangen. Ich halte beide genannten µC sowohl für 
anfängertauglich als auch Industrie-Typisch. Zweifellos gibt es noch 
viele weitere geeignete (einige wurden ja schon genannt).

: Bearbeitet durch User
von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
Marc schrieb:
> utor: Niine (Gast)
>>Arduino: Zu Abstrakt. Du weißt nicht was die eingebundenen Bibliotheken
>>wildfremder Menschen machen und so richtig weißt du auch nicht was sonst
>>noch so abgeht im Code. Arduino ist cool, aber nur für die ganz
>>schnellen Frickelsachen.
>
> Du weißt es nicht? Was genau hindert Dich daran in den Code der
> Bibliotheken zu schauen?

Das ist nicht der Punkt. Natürlich könnte ich in den Code schauen. 
Aber ich würde es vorziehen, wenn es dokumentiert wäre. Also eine 
offizielle und vollständige Variante von dem hier:

Gerhard O. schrieb:
> Im einfachsten Fall belegt Arduino immer:
> Timer0 als Zeitbasis für die millis() Funktion, PWM und den UART. Sonst
> kann man alles in normaler Weise durch direkten SFR Zugriff in gewohnter
> Weise beeinflussen

Denn natürlich ist das weder offiziell noch komplett. Es gilt auch nur 
für Arduino auf AVR.

Aber ich bin mir recht sicher, daß so etwas nicht kommen wird. Weil das 
gar nicht die Zielrichtung von Arduino ist. Die Zielgruppe von Arduino 
soll ausschließlich über das Framework auf die Hardware zugreifen. Ein 
Mix aus dem Framework hier und direkten Hardwarezugriffen dort wird 
weder als sinnvoll angesehen noch unterstützt.

Und weißt du was: da bin ich ganz bei den Arduino-Leuten. Das ist 
tatsächlich nicht sinnvoll. Wer direkten Hardwarezugriff will (vulgo: 
wer seinen µC verstehen will) der soll Arduino links liegen lassen und 
gleich direkt mit der Hardware sprechen.

Bei kleinen µC wie dem AVR halte ich Assembler für eine mögliche 
Einstiegs-Programmiersprache. Sonst halt C. Oder C++. Im Idealfall kann 
man schon eine Programmiersprache. Wenn es die für den µC gibt, dann 
halt die. Dann muß man nicht an mehreren Fronten kämpfen.

von Arduino Fanboy D. (ufuf)


Bewertung
3 lesenswert
nicht lesenswert
Axel S. schrieb:
> Die Zielgruppe von Arduino
> soll ausschließlich über das Framework auf die Hardware zugreifen. Ein
> Mix aus dem Framework hier und direkten Hardwarezugriffen dort wird
> weder als sinnvoll angesehen noch unterstützt.

Das hast du dir doch nur ausgedacht!
Oder?

Wo steht das geschrieben?
Irgendwo in der Arduino Doku?

Dann zeige mir bitte die Stelle.
Denn bisher ist mir das noch nicht unter gekommen.
Ich befürchte, das beruht alleinig auf deiner Einbildungskraft.

Nenne bitte die Quelle, auf denen deine Schlussfolgerung beruht.
Wenn es eine solche Quelle nicht gibt, dann kann deine Ansicht nicht 
mehr als eine Meinung sein. Und als solche ist sie dann recht 
willkürlich, da nicht auf belegbaren Fakten beruhend.

Das direkte Hardwarezugriffe nicht unterstützt werden ist übrigens eine 
Unwahrheit. Und bei Wiederholung eine Lüge.



Nöö...
Das halte ich für eins dieser Pseudoargumente, um einen Grund zu haben, 
das Arduino Gedönse ablehnen zu können.

Wühle dich bitte mal durch http://playground.arduino.cc/ .
Und wenn du dann immer noch deine Meinung vertrittst, dann kann ich dir 
auch nicht helfen. Dann muss das wohl weiter von dir in die Welt 
trompetet werden.

: Bearbeitet durch User
von Jens G. (jensig)


Bewertung
-2 lesenswert
nicht lesenswert
Michael B. (laberkopp) schrieb:

>braucht man Hochtemperatur bis 300 GradC HT83C51, das alles gibt es bei

Vor allem sein Preis ist voll anfängertauglich ...

@TO:
Ansonsten halte ich es wie die meisten anderen:
Wenn es Dir darum geht, generell das µC-Gebiet bzw. einen konkreten µC 
zu erforschen, dann meide Arduino u.ä. (oder besser, dessen Art des 
Programmierkonzepts), oder irgendwelche Codegeneratoren, denn deren Sinn 
ist es nun gerade nicht, das Innere eines µC kennenzulernen, sondern 
möglichst schnell und einfach irgendeine µC-Anwendung zum Laufen zu 
bekommen, indem man einfach irgendwelche Codekomponenten 
zusammenstöpselt. Da lernste aber eigentlich nix, was die µC-Welt im 
Inneren zusammenhält.

AVR und PICs wurden ja schon genannt, und sind vergleichsweise noch 
schnell zu überblicken. Damit hatte ich vor zehn, fuffzehn Jahren mal 
angefangen. Aber nicht einfach nur, um es bloß kennenzulernen, sondern 
ich hatte damals eins, zwei konkrete Projekte im Plan, die ich umsetzen 
wollte. Ich denke, da lernt man am besten und ambitionierter, wenn man 
ein Ziel hat, als nur sturr paar Beispiele durchzuarbeiten. Bis auf ein 
LED-Blinki-Blinki-Programm (was für den allerersten Test noch geklaut 
war ;-), welches ich dann noch zu einem LED-Lauflicht aufbohrte (ohne zu 
klauen ;-) - damit waren schonmal IO, Timer, Interrupts kennengelernt), 
bin ich dann direkt zu meinem ersten Projekt übergegangen, DB von vorn 
bis hinten durchgelesen (naja, nicht ganz ;-), und dabei überlegt, was 
man wie damit umsetzt, und parallel dazu Schaltplan entworfen, nachdem 
man geschnallt hat, welche Ports/Pins man wozu nutzen kann (ja, war 
damals noch klassisch mit Programmiergerät, und eigener Schaltung, kein 
Discoveryboard oder so).
Also kurz: denke Dir was konkretes aus, was Du umsetzen willst, und was 
später von Nutzen sein soll, und mache dann Learning by doing bei diesem 
konkreten Projekt (was zumindest für den Anfangs vielleicht nicht zu 
sehr aufgebläht sein sollte). Ob jetzt PIC, oder Atmel oder sonstwas, 
ist eigentlich eher egal (irgendso ein ARM/Cortex-Kram ist vielleicht 
nicht ganz so ideal für den Anfang).

von Johannes S. (jojos)


Bewertung
3 lesenswert
nicht lesenswert
Axel S. schrieb:
> Ein
> Mix aus dem Framework hier und direkten Hardwarezugriffen dort wird
> weder als sinnvoll angesehen noch unterstützt.

https://www.arduino.cc/en/Reference/PortManipulation

es wird unterstützt und da werden die Pros und Cons aufgelistet. Nur 
wird der Arduino Anfänger das nicht als erstes lesen, aber sowas gehört 
auch nicht in die erste Lektion.
Wenn es darum geht z.B. ein Display mit Parallel Port anzusteuern bleibt 
gar nichts anders mehr übrig das über direkte Zugriffe zu machen. In den 
bekannten Libs findet man das auch so und per defines ist es auch oft 
portabel gemacht weil Arduino nicht mehr nur AVR targets hat.
Also sind beide Wege absolut legitim, der Einsteiger bekommt schnell 
seine LED zum blinken und wenn er mehr Geschwindigkeit braucht muss er 
sich mit der Registerprogrammierung auseinandersetzen. So einfach ist 
das.

von Arduino Fanboy D. (ufuf)


Bewertung
-3 lesenswert
nicht lesenswert
Johannes S. schrieb:
> So einfach ist
> das.

Jawoll!

Diese Beschränkungen existieren nur in den hohlen Köpfen der selbst 
ernannten Arduino Experten.

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Axel S. schrieb:
>> Die Zielgruppe von Arduino
>> soll ausschließlich über das Framework auf die Hardware zugreifen. Ein
>> Mix aus dem Framework hier und direkten Hardwarezugriffen dort wird
>> weder als sinnvoll angesehen noch unterstützt.
>
> Das hast du dir doch nur ausgedacht!
> Wo teht das geschrieben?

Ich bin der gleichen Meinung. Es steht indirekt in der Doku, weil diese 
Möglichkeit dort konsequent verschwiegen wird.

von Arduino Fanboy D. (ufuf)


Bewertung
3 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Ich bin der gleichen Meinung. Es steht indirekt in der Doku, weil diese
> Möglichkeit dort konsequent verschwiegen wird.

Das ist eine Unwahrheit!
Eine Lüge.

Und wird in der Referenz widerlegt:
https://www.arduino.cc/en/Reference/PortManipulation

von Stefan ⛄ F. (stefanus)


Bewertung
-1 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Stefanus F. schrieb:
>> Ich bin der gleichen Meinung. Es steht indirekt in der Doku, weil diese
>> Möglichkeit dort konsequent verschwiegen wird.
>
> Das ist eine Unwahrheit!
> Eine Lüge.
>
> Und wird in der Referenz widerlegt:
> https://www.arduino.cc/en/Reference/PortManipulation

Ich habe die Seite anders in Erinnerung und kann sie gerade nicht 
aufrufen (timeout). Aber wenn sich das inzwischen geändert hat, freue 
ich mich darüber.

Die ursprüngliche Idee des Baukasten-Systems für Künstler ging ja nicht 
so ganz auf, stattdessen beschäftigen sich mehr Leute mit dem System, 
die etwas hardwarenäher programmieren wollen.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Eine Lüge.

Nö. Sinn des Frameworks ist es doch, möglichst losgelöst von der 
tatsächlichen Hardware arbeiten zu können. Wie auf einem Betriebssystem 
gewissermaßen, wo die Treiber auch die Hardware für dich abstrahieren.

Das ist ja kein Argument gegen Arduinos, sondern eins dafür. Nur 
halt nicht gerade etwas, was der TE so bräuchte.

Wenn man auf die Hardware zugreifen muss, braucht man natürlich direkte 
Zugriffe, das ist dann wie der OS-Treiber. Unterschied ist halt, dass es 
keine erzwungene Barriere zwischen beiden gibt.

von Jens G. (jensig)


Bewertung
-1 lesenswert
nicht lesenswert
Arduino Fanboy D. (ufuf) schrieb:

>Stefanus F. schrieb:
>> Ich bin der gleichen Meinung. Es steht indirekt in der Doku, weil diese
>> Möglichkeit dort konsequent verschwiegen wird.

>Das ist eine Unwahrheit!
>Eine Lüge.

>Und wird in der Referenz widerlegt:
>https://www.arduino.cc/en/Reference/PortManipulation

Nicht wirklich, eher das Gegenteil, denn dort steht:

"Why use port manipulation?

From The Bitmath Tutorial

Generally speaking, doing this sort of thing is not a good idea. Why 
not? Here are a few reasons:

...
..
.
"

Bei den Arduino Fanboys ist das also verpönt.

: Bearbeitet durch User
von Arduino Fanboy D. (ufuf)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Nö. Sinn des Frameworks ist es doch, möglichst losgelöst von der
> tatsächlichen Hardware arbeiten zu können. Wie auf einem Betriebssystem
> gewissermaßen, wo die Treiber auch die Hardware für dich abstrahieren.

Unser Stefanus hat gesagt, dass diese Möglichkeit auf die Hardware 
durchzugreifen in der Doku verschwiegen wird.
Das ist nicht wahr!

Ob man es Lüge, Unwahrheit, oder Irrtum nennt, ist zweitrangig.

Es ist eine Falschaussage.
Und es bleibt eine Falschaussage.

Und dein "Nö" ist in dem Zusammenhang deplatziert.
Ein Irrtum, eine Unwahrheit oder Lüge deinerseits.

Bedenke:
Diese Unwahrheit wurde hier identifiziert und widerlegt.

-----------


> Sinn des Frameworks ist es doch, möglichst losgelöst von der
> tatsächlichen Hardware arbeiten zu können. Wie auf einem Betriebssystem
> gewissermaßen, wo die Treiber auch die Hardware für dich abstrahieren.

Ist ja ok...
Und wenn einem das nicht reicht, dann muss man eben tiefer in die Kiste 
greifen.

Aber die Behauptung, das das nicht erwünscht ist, oder gar überhaupt 
nicht möglich sein soll, ist einfach nur absurd und falsch.
Irreführend.

von Stefan ⛄ F. (stefanus)


Bewertung
3 lesenswert
nicht lesenswert
Jedenfalls kann (und konnte man schon immer) am Arduino Framework vorbei 
programmieren, wenn man es denn will. Im Prinzip finde ich das gut, denn 
so hat man immer die Möglichkeit offen, Sachen zu implementieren, die 
von den Arduino Machern gerade nicht vorgesehen waren. Ist doch gut so.

von Johannes S. (jojos)


Bewertung
6 lesenswert
nicht lesenswert
Jens G. schrieb:
> Generally speaking, doing this sort of thing is not a good idea. Why
> not? Here are a few reasons:

Und dann hast du aufgehört weiterzulesen? Es folgen 3 Argumente Con und 
3 Pro.
Und wenn man die verstanden kann man selbst entscheiden.

: Bearbeitet durch User
von Arduino Fanboy D. (ufuf)


Bewertung
3 lesenswert
nicht lesenswert
Jens G. schrieb:
> Nicht wirklich, eher das Gegenteil, denn dort steht:
>
> "Why use port manipulation?
>
> From The Bitmath Tutorial
>
> Generally speaking, doing this sort of thing is not a good idea. Why
> not? Here are a few reasons:
>
> ...
> ..
> .
> "
>
> Bei den Arduino Fanboys ist das also verpönt.

Auch du liest scheinbar nur halb, und pickst dir dann das raus, was dir 
gefällt, deine Ablehnung bestätigt.

Du hast unterschlagen:
> Here are some of the positive aspects of direct port access:
Welche man durchaus als Empfehlung auffassen darf, wenn man auf die dort 
benannten Probleme trifft.

Dieser Teil der Arduino Doku beleuchtet also die Vor- und Nachteile des 
direkten Portzugriffs.


> Bei den Arduino Fanboys ist das also verpönt.
Falsche Schlussfolgerung, da nicht vollständig gelesen/verstanden.

von Arduino Fanboy D. (ufuf)


Bewertung
1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Jedenfalls kann (und konnte man schon immer) am Arduino Framework
> vorbei
> programmieren, wenn man es denn will. Im Prinzip finde ich das gut, denn
> so hat man immer die Möglichkeit offen, Sachen zu implementieren, die
> von den Arduino Machern gerade nicht vorgesehen waren. Ist doch gut so.

Dem kann ich vollumfänglich zustimmen.

von Hannes J. (hannes_j)


Bewertung
0 lesenswert
nicht lesenswert
Ich würde dir zu einem Atmega, z. B. 328P raten. Der ist natürlich nicht 
State of the Art aber noch einfach genug um sich Grundlagen auch ohne 
viel Vorwissen selbst zu erarbeiten. Kennst du einen kennst du alle 
würde ich so nicht sagen, aber das Grundverständnis hilft definitiv bei 
der Einarbeitung in neue Controller.

Arduino wäre dann quasi die passende Entwicklungsumgebung mitsamt 
Platine, wenn du eigentlich mit der µC-Technik möglichst wenig Kontakt 
haben, sondern schnell ein irgendwie funktionierendes Programm haben 
willst.

Ohne Arduino brauchst du erstmal ein Eval-Board. Ich habe das Atmel 
Evaluation Board von Pollin. Da hast du schonmal funktionierende 
Hardware. Zum Programmieren nimmst du z. B. einen AVRISP MKII. Der hat 
USB für deinen PC und ISP für den µC auf deinem Eval-Board. Als 
Entwicklungsumgebung benutzt du das aktuelle Atmel Studio. Hier kannst 
du dann zu Beginn deinen µC auswählen um einige wichtige Libraries 
automatisch einzubinden.

Jetzt hast du alles um anzufangen. Alles zum Aufbau des µC und der 
Umsetzung deiner Ideen findest du dann im Datasheet zu deinem µC und 
entsprechenden Application Notes des Herstellers.

von Jens G. (jensig)


Bewertung
-3 lesenswert
nicht lesenswert
@Johannes S. (jojos) + Arduino Fanboy D. (ufuf)

> Generally speaking, doing this sort of thing is not a good idea. Why
> not? Here are a few reasons:

Ich habe weder halb gelesen, noch lehne ich Arduino ab. Ich habe nur den 
einen Satz ins Spiel gebracht, der uns zu verstehen geben will, daß 
direkte Zugriffe nicht empfohlen (erwünscht) sind, egal ob da noch drei 
Pros aufgeführt sind.

Und das dies nicht wirklich erwünscht ist, sieht man mehr oder weniger 
daran, das der genannte Link ziemlich losgelöst ohne weitere Referenzen 
da steht. Von https://www.arduino.cc/reference/en/ (Language Reference) 
jedenfalls scheint es keinen Link auf 
www.arduino.cc/en/Reference/PortManipulation zu geben. Zumal die beiden 
oberen Verzeichnisebenen reference/en sich auf magische Art und Weise in 
/en/Reference verwandeln, wenn es um PortManipulation geht, damit man es 
ja nicht findet.

: Bearbeitet durch User
von Johannes S. (jojos)


Bewertung
1 lesenswert
nicht lesenswert
das Inhaltsverzeichnis vom Internet ist einfach schlecht...
https://playground.arduino.cc/Main/TutorialList#AVR
da wird es verlinkt und sowas sollte man einfach überflogen haben wenn 
man die ersten Schritte hinter sich hat.

von Jens G. (jensig)


Bewertung
-3 lesenswert
nicht lesenswert
> https://playground.arduino.cc/Main/TutorialList#AVR

Sowas gehört in die Reference, und nicht in eine Linksammlung ...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
>> Nö. Sinn des Frameworks ist es doch, möglichst losgelöst von der
>> tatsächlichen Hardware arbeiten zu können. Wie auf einem Betriebssystem
>> gewissermaßen, wo die Treiber auch die Hardware für dich abstrahieren.
>
> Unser Stefanus hat gesagt, dass diese Möglichkeit auf die Hardware
> durchzugreifen in der Doku verschwiegen wird.

OK, das hatte ich dann falsch aufgefasst.

Arduino Fanboy D. schrieb:
> Dem kann ich vollumfänglich zustimmen.

Dann sind wir uns ja alle völlig einig. :-)

von Axel S. (a-za-z0-9)


Bewertung
-3 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> Axel S. schrieb:
>> Die Zielgruppe von Arduino
>> soll ausschließlich über das Framework auf die Hardware zugreifen. Ein
>> Mix aus dem Framework hier und direkten Hardwarezugriffen dort wird
>> weder als sinnvoll angesehen noch unterstützt.
>
> Wo steht das geschrieben?
> Irgendwo in der Arduino Doku?

Das steht nirgendwo geschrieben. Insofern ist das meine Beschreibung für 
den vorgefundenen Zustand. Der Beginn und die Motivation des 
Arduino-Projekts sind ja gut dokumentiert. Der Rest ergibt sich mehr 
oder weniger direkt daraus.

> Nenne bitte die Quelle, auf denen deine Schlussfolgerung beruht.

Das nennt man die Realität.


Johannes S. schrieb:
> Axel S. schrieb:
>> Ein
>> Mix aus dem Framework hier und direkten Hardwarezugriffen dort wird
>> weder als sinnvoll angesehen noch unterstützt.
>
> https://www.arduino.cc/en/Reference/PortManipulation
>
> es wird unterstützt und da werden die Pros und Cons aufgelistet.

Das ist nicht das, was ich gemeint habe. Es wird selbstverständlich 
unterstützt in dem Sinne das es geht. Nur ist ist das keine Eigenschaft 
der Arduino-Umgebung, sondern nur eine durchscheinende Eigenschaft der 
Technologie, auf der Arduino aufgebaut ist. Hier: avr-gcc und avr-libc.

Wenn Arduino direkte Hardwarezugriffe an der Lib vorbei wirklich 
unterstützen würde (und das ist jetzt die Art Unterstützung, die ich 
weiter oben gemeint habe) dann würden sie dafür sorgen, daß 
Direktzugriffe nicht in Konflikt mit der Lib kommen können. Bspw. 
könnten sie den Direktzugriff auf Timer0 unterbinden und damit 
verhindern, daß der geneigte Arduino-Nutzer sich seine Infrastruktur 
unter dem Hintern wegballert. Als Minimum müßten sie klar dokumentieren, 
welche Teile der Hardware Tabu sind.

So wie es jetzt ist, haben sie da einen hüfthohen Zaun eingezogen. Die 
von dir gezeigte Seite ist das Schild "Hinter dem Zaun ist das Gras 
sogar noch grüner und in der einen Ecke wachsen sogar Blumen. Aber es 
gibt auch wilde Tiere. Betreten auf eigene Gefahr!"

> Wenn es darum geht z.B. ein Display mit Parallel Port anzusteuern bleibt
> gar nichts anders mehr übrig das über direkte Zugriffe zu machen.

Der Arduino-Nutzer im Sinne der (meinetwegen auch nur ursprünglichen) 
Zielgruppe verwendet dafür eine Lib. Abgesehen davon kann man natürlich 
auch mit digitalWrite() ein paralleles LCD ansteuern. Langsam wie Hulle, 
klar. Aber am Ende wahrscheinlich schnell genug <tm>

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Axel S. schrieb:
> So wie es jetzt ist, haben sie da einen hüfthohen Zaun eingezogen. Die
> von dir gezeigte Seite ist das Schild "Hinter dem Zaun ist das Gras
> sogar noch grüner und in der einen Ecke wachsen sogar Blumen. Aber es
> gibt auch wilde Tiere. Betreten auf eigene Gefahr!"

:-))

von Alex G. (dragongamer)


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Wenn Arduino direkte Hardwarezugriffe an der Lib vorbei wirklich
> unterstützen würde (und das ist jetzt die Art Unterstützung, die ich
> weiter oben gemeint habe) dann würden sie dafür sorgen, daß
> Direktzugriffe nicht in Konflikt mit der Lib kommen können. Bspw.
> könnten sie den Direktzugriff auf Timer0 unterbinden und damit
> verhindern, daß der geneigte Arduino-Nutzer sich seine Infrastruktur
> unter dem Hintern wegballert. Als Minimum müßten sie klar dokumentieren,
> welche Teile der Hardware Tabu sind.
Wie jetzt, du willst die Sicherheit die dir Android bietet und 
gleichzeitig völlige Freiheit zum Zugriff auf den uC?
Tja, beides kann man schlicht nicht haben.
Mittels ein paar Suchanfragen im Sourcecode der Core Libraries oder 
durch Durchlesen der realen main Funktion kannst du recht schnell 
rauslesen ob das was du grade maximal-maschinennah vor hast, mit Android 
kolidiert, oder nicht.

Gut, vieleicht scheint hier die Philosophie der "Maker" durch. Wir lesen 
lieber sourcecode statt Datenblätter.

: Bearbeitet durch User
von W.S. (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Jörg W. schrieb:
> :-))

Genau! Das hat der Axel doch schön gesagt, gelle?

Das Problem bei allem, was irgend jemand in bester Absicht vorgekaut und 
zum Benutzen vorbereitet hat, besteht eben darin, daß es recht vielen 
Benutzern den Weg in ein Technik-Gebiet öffnet, OHNE daß daran der 
eigentlich notwendige Lernprozeß gekoppelt ist.

Wer jedoch Arduino benutzt UND sich in die verwendete Technik einliest 
und selbst darin weiterbildet, dem ist das alles eine gute Hilfe - ABER 
es gibt offenbar sehr viele, die eben letzteres nicht tun und dennoch 
meinen, sie wüßten durch's schiere Benutzen schon genug. Siehe der 
Beitrag mit den offengelassenen ADC-Eingängen.

W.S.

von Jens G. (jensig)


Bewertung
1 lesenswert
nicht lesenswert
Axel S. (a-za-z0-9) schrieb:

>Das ist nicht das, was ich gemeint habe. Es wird selbstverständlich
>unterstützt in dem Sinne das es geht. Nur ist ist das keine Eigenschaft
>der Arduino-Umgebung, sondern nur eine durchscheinende Eigenschaft der
>Technologie, auf der Arduino aufgebaut ist. Hier: avr-gcc und avr-libc.

Aja, dann wird es auch für mich klar, warum es nicht in der Arduino-Ref 
erwähnt ist. Ist eben kein Feature von Arduino, sondern beruht nur auf 
der Umgehung deselben. So gesehen unterstützt es ja alles ...

von Axel S. (a-za-z0-9)


Bewertung
-1 lesenswert
nicht lesenswert
Alex G. schrieb:
> Axel S. schrieb:
>> Wenn Arduino direkte Hardwarezugriffe an der Lib vorbei wirklich
>> unterstützen würde (und das ist jetzt die Art Unterstützung, die ich
>> weiter oben gemeint habe) dann würden sie dafür sorgen, daß
>> Direktzugriffe nicht in Konflikt mit der Lib kommen können. Bspw.
>> könnten sie den Direktzugriff auf Timer0 unterbinden und damit
>> verhindern, daß der geneigte Arduino-Nutzer sich seine Infrastruktur
>> unter dem Hintern wegballert. Als Minimum müßten sie klar dokumentieren,
>> welche Teile der Hardware Tabu sind.

> Wie jetzt, du willst die Sicherheit die dir Android bietet und
> gleichzeitig völlige Freiheit zum Zugriff auf den uC?

Gott, nein. Ich verwende Arduino nicht. Und zwar nicht, weil ich es 
schlecht oder häßlich finden würde, sondern weil es schlicht kein 
Problem löst, das ich hätte. Und in diesem Thread rede ich darüber auch 
nur deswegen, weil das gleiche für den TE gilt. Für das, was er vorhat, 
ist (das) Arduino(framework) keine Hilfe. Die Hardware könnte er 
natürlich trotzdem verwenden. Ich nehme auch gerne Arduino-nano Klone 
aus China. Die sind kaum größer als ein mega328 in DIP und haben den 
USB-UART schon an Bord. Sehr praktisch.

> Tja, beides kann man schlicht nicht haben.

Man könnte schon. Aber es würde Arbeit machen. Man könnte nicht einfach 
nur Compiler und libc von jemand anderem nehmen und eine handvoll 
C-Funktionen als Abstraktionsschicht drüber stülpen. Man müßte die 
Hardwareresourcen so wegkapseln, daß man den Zugriff einschränken kann. 
Lustigerweise würde C++ als Sprache dafür ja sogar Mittel und Wege 
bereitstellen.

> Mittels ein paar Suchanfragen im Sourcecode der Core Libraries oder
> durch Durchlesen der realen main Funktion kannst du recht schnell
> rauslesen

Klar könnte ich. Aber es ist nichts, was mich weiterbringt. Im Zweifel 
bin ich ohne Arduino schneller am Ziel.

von Joerg W. (joergwolfram)


Bewertung
5 lesenswert
nicht lesenswert
Man muss halt auch sehen, viele von uns blicken schon auf eine längere 
"Elektroniklaufbahn" zurück. Meiner Erfahrung nach gab es schon immer 
eine Art Dreiteilung.

Den größten Teil der Menschheit interessiert Elektronik nur soweit, dass 
sie mit fertigen Sachen mehr oder weniger umgehen können. Dann gibt es 
die, für die es nur "Mittel zum Zweck" ist. Die haben halt früher 
Schaltungen nur aus Büchern/Zeitschriften nachgebaut oder Bausätze 
gekauft, um das Ganze dann halt in einem anderen Zusammenhang (z.B. 
Modellbahn) einzusetzen. Das Äquivalent dazu ist meiner Meinung nach 
heute der Arduino und die ganze Szene drumherum.

Und dann gibt es die, für die der Weg das Ziel ist, die in die Materie 
eintauchen wollen. Früher wurden alle möglichen Schaltungen konstruiert, 
berechnet und ausprobiert, heute sind es die Register und Bits in den 
Controllern. Dafür können sie auf so "unnötigen Schnickschnack" wie 
Gehäuse gerne verzichten, denn das erschwert nur den Zugang zur 
Debug-Schittstelle und Aufbauten bleiben oft nur so lange bestehen, bis 
man die nächste Idee hat...

Doch anstelle sich zu ergänzen, wird lieber aufeinander eingehackt. 
Manche Dinge ändern sich halt nie...

von Karl B. (gustav)


Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich verstehe nichts mehr.

Also, erst einmal ein "schlaues" Buch lesen, um sich mit den Grundlagen 
vertraut zu machen, dann geht es ans Evaluation Board,
und dann kann man ein bisschen was in ASM eingeben oder so dann 
Debuggen, im Simulator Käsekästchen hin- und herschieben lassen, etc.

Achtung joke/Und dann fährt mir diese verflixte Arduino in die Parade,
und nichts geht mehr./ joke end

Beitrag "Re: ArduinoISP - Wieso wird das Programm nicht."

Also aus Erfahrung auch mit 8051-ern-> Atmel Studio und ein EVA Board, 
also meins war damals STK500, da gibt es jetzt auch modernere. Und 
ATtiny4313 oder eben ein MEGA und mit Adaptersockel sogar 32-er Megas.

(Wenn die ersten LEDs blinken, sprechen wir uns wieder.) ;-)

ciao
gustav

von Gerhard Z. (nertsch)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bloody_beginner schrieb:
> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger
> heutzutage raten anzufangen?
>
> Habe Elektrotechnik und Softwaretechnik Kenntnisse, könnte also sofort
> damit anfangen.

bloody_beginner schrieb:
> C++ beherrsche ich mittlerweile, aber so richtig bin ich ins
> Programmieren dann erst mit Java eingestiegen.

Also wenn Du C++ beherrschst und Kenntnisse in Elektrotechnik hast, dann 
bist Du kein blutiger Anfänger.
Nachdem ich letzte Woche auch das erste mal einen Arduino in der Hand 
hatte kann ich die sagen, dass es ca. 15 min dauert bis Du dein erstes 
lauffähiges Arduino-"Hello World"-Programm geschrieben hast. Als 
Einführung würde ich folgendes Video empfehlen: 
https://www.youtube.com/watch?v=nL34zDTPkcs

Wirst sehen, es ist ganz einfach...

Der einzige Knackpunkt bei der Sache ist, wie hier schon im Thread 
angemerkt wurde, die ganze Analogtechnik die Du um den Arduino herum 
brauchst...

Das ist auch mein Problem, dass ich in der Analogtechnik nicht sehr 
bewandert bin und praktisch nur über (ein bisschen) Grundwissen verfüge, 
mit dem ich keine praxistauglichen Ananlogschaltungen entwickeln kann.


Gruß
Gerhard

: Bearbeitet durch User
von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joerg W. schrieb:
> Und dann gibt es die, für die der Weg das Ziel ist, die in die Materie
> eintauchen wollen.

..und dann gibt es noch die, die damit Geräte entwickeln und bauen. Zum 
Teil beruflich für die Brötchen, die man zu essen gedenkt, zum Teil 
hobbymäßig, um sich das Equipment zu schaffen, das man für's Hobby 
braucht.

Es ist dann wohl eine Vierteilung.

W.S.

von Joerg W. (joergwolfram)


Bewertung
0 lesenswert
nicht lesenswert
Wenn man "kommerzielle" Tätigkeiten mit einrechnet, reicht dann eine 
Vierteilung nicht mehr. Die Leute bei den Chipherstellern oder ATE 
sitzen meist noch ein Stück näher am Silizium. Und am anderen Ende wird 
mit dSPACE oder Vector Tools gearbeitet, gegen die ich Arduino noch als 
"hardwarenah" bezeichnen würde. Und dazwischen tausende von 
Schattierungen.

Selbst meine "Dreiteilung" bei den Hobbybastlern ist schon grenzwertig, 
weil es natürlich auch da fließende Übergänge gibt.

von Manfred (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Michael B. schrieb:
> Schnarchlangsam beginnt damit, 8 bit eines value auszugeben:
>
> for(bit=0;bit<8;bit++)
>   digitalWrite(OUTPUTPIN0+bit,value&(1<<bit)?HIGH:LOW);
>
> Das ist schnarchlangsam gegenüber einem PORTD=value;

Das ist in der Masse aller Anwendungen ein theoretisches Problem. Du 
hast durchaus recht, dass man mit dem direkten Zugriff etliche Zyklen 
sparen kann, zu je 63 Nanosekunden @ 16MHz. Ich bin fast geneigt, sowas 
mal zu schreiben und ein Scope dran zu hängen.

Hannes J. schrieb:
> Ohne Arduino brauchst du erstmal ein Eval-Board. Ich habe das Atmel Evaluation 
Board von Pollin.

Selbst schuld :-)

> Da hast du schonmal funktionierende Hardware.

Aus diesem Grunde kaufen etliche Leute Arduino-Boards aus Fernost. Alle 
haben den ISP-Anschluß drauf und lassen sich so auch ohne das 
A*-Framework verwenden.

W.S. schrieb:
> ..und dann gibt es noch die, die damit Geräte entwickeln und bauen.
> Zum Teil beruflich für die Brötchen, die man zu essen gedenkt,

Und auch diese klempnern nur noch selten auf der Assemblerebene, sondern 
schreiben in C.

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

die Art der Hardwarezugriffe sind Anfangs erstmal egal ob nah oder fern. 
Ein Programm besteht nicht nur aus Hardwarezugriffen. Sie müssen auch 
verarbeitet werden. Genau hier liegt in meinen Augen die Kunst des 
Programmieren lernen. Wie formuliert man ein Problem und wandelt es in 
den Code um der dann am Ende hoffentlich fehlerfrei funktioniert und 
nicht nur paar Minuten. Das ist offensichtlich völlig unabhängig der IDE 
oder des Controllers.

Und wegen dem Arduio Framework. Nüchtern betrachtet sind das alles 
Komfortfunktionen. Ich meine wir schreiben uns doch selber auch 
Funktionen oder ganze Librarys um uns selbst die Arbeit zu erleichtern. 
Damit sind wir beim digitalWrite u.ä. Komfortfunktionen. Es gibt bis 
heute keine Alternative die 1:1 benutzbar schneller funktioniert. Man 
kann sich ein Array für irgendwelche Pins anlegen und mittels 
Indexdurchlauf und digitalWrite drübergehen. Geht in der einfachen Form 
sonst nicht. Weil Komfort immer Zeit kostet, der muss anderes schreiben 
wenn ihm das zu langsam ist. Das ist aber schon immer so gewesen und 
nichts neues.

Und was schon oft geschrieben wurde und gern wiederholt werden muss ist. 
Man muss die Arduino IDE und/oder dessen Komfortfunktionen nicht nutzen. 
Man kann die Boards auch als reine praktische Entwicklerboards 
verwenden.

von Marc (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Manfred schrieb
>Das ist in der Masse aller Anwendungen ein theoretisches Problem. Du
>hast durchaus recht, dass man mit dem direkten Zugriff etliche Zyklen
>sparen kann, zu je 63 Nanosekunden @ 16MHz. Ich bin fast geneigt, sowas
>mal zu schreiben und ein Scope dran zu hängen.

Es gibt ja kein Problem, das man nicht mit einer Library lösen könnte. 
Hier eine unter vielen:

https://github.com/mmarchetti/DirectIO

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Das Pollin Board ist eine billige Alternative für das STK500. Beide 
wollen ganz viele Stecksockel für viele unterschiedliche AVR Modelle 
bereit stellen.

Das halte ich aber für wenig sinnvoll. Denn innerhalb der AVR Serie kann 
man tatsächlich sagen "Kennst einen, kennst du alle". Die sind sich 
wirklich sehr ähnlich.

Das Argument "Ich kann das Eval Board auch als Programmieradapter 
verwenden" zählt für mich kaum, denn normalerweise programmiert man 
diese Chips eben nicht in einem Programmier-Sockel sondern direkt in der 
Zielschaltung.

Nur die kleinen 8-Pinner programmiere ich häufig außerhalb der 
Zielschaltung. Dafür braucht man aber kein komplettes "Board". Als 
Bastler wird man es wohl noch schaffen, einen 8 poligen IC Sockel mit 6 
Drähten ab einen Pfostenstecker oder ein paar Dupont Kabel zu löten.

: Bearbeitet durch User
von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> normalerweise programmiert man
> diese Chips eben nicht in einem Programmier-Sockel sondern direkt in der
> Zielschaltung.

Die neueren ATmega4808 brauchen nur eine Leitung zum Programmieren und 
debuggen (UPDI).

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Arduino Fanboy D. schrieb:
> bloody_beginner schrieb:
>> Wie lange braucht ihr um euch in einen neuen uC einzuarbeiten?
>
> 1/2 Jahr, bis 1 Jahr.
> So ca. und ohne Gewähr, da stak abhängig von Type und Vorwissen.

Ganz unrecht hat der OP nicht ... Ich  hab lange Zeit mit AVRs 
gearbeitet und bin dann auf STM32 quasi umgestiegen.

Es hat 2 Wochen gedauert sich da einzuarbeiten und das angestrebte 
Projekt zur Funktion zu bringen.

Aber selbst mehr als 1 Jahr später tauchen immer noch Sachen auf, mit 
denen man bisher keine Berührpunkte hat (z.B. DMA Transfer mit 
Ringpuffer und den Half-Full/Half-Empty Interrupts). Mit anderen Sachen 
hatte ich nie was zu tun - wie z.B. CAN.

Wäre daher der Meinung, dass man mit µC Vorwissen schneller voran kommt, 
aber länger mit neuen µCs arbeiten muss, bis man sie wirklich kennt.

Beitrag #5622730 wurde vom Autor gelöscht.
von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Marc schrieb:
> Es gibt ja kein Problem, das man nicht mit einer Library lösen könnte.
> Hier eine unter vielen:
>
> https://github.com/mmarchetti/DirectIO

Hallo,

alle diese Libs sind zwar schnell, ersetzen aber nicht die
Funktionalität 1:1 von digitalWrite mit
Parameterübergabe/Parameteränderung zur Laufzeit. Die Pins werden mit
Objektnamen vorher festgenagelt und steif geschalten. Eigentlich fast
nichts anderes als wenn man das mit den sbi/cbi markro machen würde.

: Bearbeitet durch User
von Alex G. (dragongamer)


Bewertung
0 lesenswert
nicht lesenswert
Veit D. schrieb:
> Hallo,
>
> alle diese Libs sind zwar schnell, ersetzen aber nicht die
> Funktionalität 1:1 von digitalWrite mit
> Parameterübergabe/Parameteränderung zur Laufzeit. Die Pins werden mit
> Objektnamen vorher festgenagelt und steif geschalten. Eigentlich fast
> nichts anderes als wenn man das mit den sbi/cbi markro machen würde.
Nein, die Library ermöglicht auch dynamische Pin variablen. Wie hoch da 
die Beschleunigung zu Digitalwrite ist, steht leider nicht, aber null 
wird sie nicht sein, sonst wäre das ja sinnlos.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> Wie hoch da die Beschleunigung zu Digitalwrite ist, steht leider nicht,
> aber null wird sie nicht sein, sonst wäre das ja sinnlos.

wird nicht auch manchmal sinnloses gemacht?

Wer will sich davon freisprechen, oft glaubt man ja sein eigener Weg ist 
der bessere.

von Veit D. (devil-elec)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,

okay, ist zwar nicht 100% 1:1, aber geht in die richtige Richtung. Ist 
eben etwas anders in der Benutzung, man muss 2 Schritte machen. Ist ja 
nicht schlimm. Man muss sich nur umgewöhnen.  :-)
Danke für den Hinweis. Ich hatte es leider nur überflogen.
Dann wird https://github.com/NicksonYap/digitalWriteFast es ähnlich 
machen.
Wenn ich mal viel Zeit & Lust habe werde ich das gegeneinander testen.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Das Argument "Ich kann das Eval Board auch als Programmieradapter
> verwenden" zählt für mich kaum

Ich nutze das regelmässig, so lange der uC in DIP und nicht SMD ist.

War neulich angenehm überascht dass das Pollin-Board mit avrdude ponyser 
auch ATtiny13a programmieren konnte obwohl der nicht in der Doku stand.

Und wenn ein SMD in der Schaltung programmiert wird, steckt das andere 
Kabelende im Pollinboard.

Ich achte aber drauf, dass mein PC noch richtige seriell und parallel 
Ports hat.

von Karl B. (gustav)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Ich achte aber drauf, dass mein PC noch richtige seriell und parallel
> Ports hat.

Hi @MaWin,
fullest ack.
Irgendwie bin ich von den USB-seriell-Adaptern nicht so überzeugt.


ciao
gustav

von Jens G. (jensig)


Bewertung
0 lesenswert
nicht lesenswert
>Irgendwie bin ich von den USB-seriell-Adaptern nicht so überzeugt.

Funktioniert aber einwandfrei (steht dort ;-)

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> Ich achte aber drauf, dass mein PC noch richtige seriell und parallel
> Ports hat.

Das funktioniert aber nur, wenn du höchstens XP drauf fährst.

Abgesehen davon sieht es mit nachträglich eingebauten Parallelports 
ausgesprochen mau aus. Die Dinger, die es auf Einsteck-Karten gibt 
(NetMos usw.), haben unübliche I/O-Adressen ($4000 oder $4800 und so) 
und damit kommen viele Programme, die nur die drei alteingesessenen 
Adressen kennen, nicht mehr zurecht.

W.S.

von Karl B. (gustav)


Bewertung
0 lesenswert
nicht lesenswert
Jens G. schrieb:
> Funktioniert aber einwandfrei (steht dort ;-)

Hi,
bekomme es nicht gebacken, ein STK500 (Rs232) mit USB-Adapter über 
USB-Port zum Laufen zu bringen. Irgendein USB-Treiber oder so etwas 
fehlt da. FLIP verstehe ich nicht.
Vielleicht hilft mir jemand auf die Sprünge.

W.S. schrieb:
> Das funktioniert aber nur, wenn du höchstens XP drauf fährst.

geht auch mit mehr als WinXP und sogar 64-Bitter.

Kommt wohl auf die Karte an.
Zitat:
MCS9835 -- PCI to Dual Serial and Single Parallel Controller
The MCS9835CV-BA is a PCI based single function I/O Adapter. /Zitat

ciao
gustav

: Bearbeitet durch User
von Jens G. (jensig)


Bewertung
0 lesenswert
nicht lesenswert
>bekomme es nicht gebacken, ein STK500 (Rs232) mit USB-Adapter über
>USB-Port zum Laufen zu bringen. Irgendein USB-Treiber oder so etwas
>fehlt da. FLIP verstehe ich nicht.
>Vielleicht hilft mir jemand auf die Sprünge.

Zuallererst gucken, ob es neuere Treiber für den Adapter gibt. Hat 
zumindest bei mir damals bei irgend so einem Prolific-Adapter mal 
weitergeholfen

von W.S. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Manfred schrieb:
> W.S. schrieb:
>> ..und dann gibt es noch die, die damit Geräte entwickeln und bauen.
>> Zum Teil beruflich für die Brötchen, die man zu essen gedenkt,
>
> Und auch diese klempnern nur noch selten auf der Assemblerebene, sondern
> schreiben in C.

Das ist NICHT das Thema. Es geht hier nicht um Assembler oder 
C/Pascal/forth/sonstwas, sondern um das Thema der geistigen Stellung zum 
Thema Mikrocontroller, also darum, welche Menschen-Gruppe welche 
Position dazu einnimmt:
- reine Benutzer (Telefon, Radio, Computer)
- Bausatz-Bastler (für die Modelleisenbahn, Quadcopter usw)
- Steckbrett-Bastler (Steckbrett: was aufbauen und gucken, ob man's 
hinbekommt)
- Geräteentwickler (Ziel: verkaufsfähiges Gerät)

Wer da wofür welche Programmiersprache benutzt, ist wirklich egal.
Kleines Beispiel: der frühere Antennen-Analysator in Funkamateur: 
programmiert mit BASCOM, und war ein Verkaufsschlager.

W.S.

von spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi

>bekomme es nicht gebacken, ein STK500 (Rs232) mit USB-Adapter über
>USB-Port zum Laufen zu bringen.

Vielleicht hast du nur den/die falschen? Ich habe unter WIN7(64 Bit) 
diesen

https://www.reichelt.de/usb-2-0-konverter-a-stecker-auf-rs-232-delock-61460-p78847.html?&trstct=pos_8

im Einsatz. Extra für das STK500 gekauft.

MfG Spess

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Karl B. schrieb:
> Kommt wohl auf die Karte an.
> Zitat:
> MCS9835 -- PCI to Dual Serial and Single Parallel Controller
> The MCS9835CV-BA is a PCI based single function I/O Adapter. /Zitat

Eben NICHT.
Man kann solche Karten durchaus einbauen und sie werden auch bei 
Vorhandensein passender Treiber vom Betriebssystem akzeptiert - aber der 
Zugriff von einem Anwendungs-Programm aus ist so ab Win7 nicht mehr 
frei. Selbstverständlich könnte man dort einen echten Drucker 
anschließen und auch drüber drucken, aber hier geht's um das Anschließen 
von Programmier-Geschirre anstelle des Druckers.

W.S.

von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Karl B. schrieb:
>> Kommt wohl auf die Karte an.
>> Zitat:
>> MCS9835 -- PCI to Dual Serial and Single Parallel Controller
>> The MCS9835CV-BA is a PCI based single function I/O Adapter. /Zitat
>
> Man kann solche Karten durchaus einbauen und sie werden auch bei
> Vorhandensein passender Treiber vom Betriebssystem akzeptiert - aber der
> Zugriff von einem Anwendungs-Programm aus ist so ab Win7 nicht mehr
> frei. Selbstverständlich könnte man dort einen echten Drucker
> anschließen und auch drüber drucken, aber hier geht's um das Anschließen
> von Programmier-Geschirre anstelle des Druckers.

Hmm. Dann habe ich mit meinem Setup wohl ein glückliches Händchen 
bewiesen. Der Parallelport ist auch so eine PCIe Karte. Da hängt ab und 
zu ein Galep3 dran. Die Software läuft allerdings nicht direkt auf dem 
Eisen, sondern in VMWare. Und das emuliert den Parallelport auf der 
Standard-Adresse, obwohl er auf dem Host ganz woanders liegt. Läuft 
alles ganz normal.

von Karl B. (gustav)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Jens G. schrieb:
> Zuallererst gucken, ob es neuere Treiber für den Adapter gibt. Hat
> zumindest bei mir damals bei irgend so einem Prolific-Adapter mal
> weitergeholfen

Hi @all,
erst mal danke für Antworten.
Irgendwie habe ich heute eine riesen Dachlatte vorm Kopf.
OK. Im Bildchen links ist Bord noch nicht eingeschaltet. Aber die Frage 
ging dahin,
bei USB sieht das STK auch irgendeinen von den COM-Anschlüssen, die im 
Menü aufgelistet sind? Oder auf Auto gehen?

Bei "richtigem" COM-Port läuft es super.

ciao
gustav

: Bearbeitet durch User
von spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi

>Aber die Frage ging dahin,
bei USB sieht das STK auch irgendeinen von den COM-Anschlüssen, die im
Menü aufgelistet sind?

Das ist eigentlich die Liste der COM-Ports die das AVR-Studio abfragt.

>Oder auf Auto gehen?

Ja.

MfG Spess

von Karl B. (gustav)


Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
>>Oder auf Auto gehen?
>
> Ja.
>
> MfG Spess

Hi,
der andere USB-Konverter wird alsbald ausprobiert.
Melde mich dann, wenn es geklappt hat.
Schon mal vielen Dank für den Tip an @Spess.

ciao
gustav

Beitrag #5623279 wurde von einem Moderator gelöscht.
von c-hater (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Stefanus F. schrieb:

> Denn innerhalb der AVR Serie kann
> man tatsächlich sagen "Kennst einen, kennst du alle". Die sind sich
> wirklich sehr ähnlich.

Ähemm. Jain. Einerseits neige ich dazu, dir zuzustimmen, denn es gibt 
tatsächlich sehr, sehr viele Gemeinsamkeiten zwischen den vielen 
AVR8-Inkarnationen. Leider gibt es aber eben auch Unmassen Unterschiede 
und viele davon haben halt durchaus das Potential, auf dem einen Device 
eine beabsichtigte Nutzungsart unmöglich zu machen, die auf anderen 
problemlos funktioniert.

> Das Argument "Ich kann das Eval Board auch als Programmieradapter
> verwenden" zählt für mich kaum, denn normalerweise programmiert man
> diese Chips eben nicht in einem Programmier-Sockel sondern direkt in der
> Zielschaltung.

So isses. Evalboards braucht man eigentlich nur für "erste Schritte" in 
der jeweiligen Zielarchitektur, um die jeweilige Toolchain an's Laufen 
zu bringen und die ersten Erfahrungen mit ihrer Benutzung und der der 
Zielarchitektur zu sammeln. Danach kann man ein Evalboard höchstens noch 
nutzen, um Teil-Lösungen zu testen, aber selten für wirklich optimierte 
vollständige Anwendungen. Entweder sind sie zu groß oder zu klein für 
das Evalboard oder die vorhandene Schaltung des selbigen stört bezüglich 
der beabsichtigten Ziel-Anwendung.

von Karl B. (gustav)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Karl B. schrieb:
> der andere USB-Konverter wird alsbald ausprobiert.
> Melde mich dann, wenn es geklappt hat.
> Schon mal vielen Dank für den Tip an @Spess.

OK,
der Delock 62589 wird im Windows unter Anschlüsse  (COM&LPT) als COM3 
geführt. Und im STK500 sowohl unter Auto als auch (natürlich) unter COM3 
erkannt.
Das Einzige, was unschön ist, dass erst ein Male-Male und Female-Female 
Gender Changer hintereinander gesteckt werden müssen, weil die Muttern 
sonst blockieren.

Danke nochmals für den Tip @Spess !

ciao
gustav

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Karl B. schrieb:
> weil die Muttern sonst blockieren

Einfach welche rausschrauben (die aus dem STK500 lassen sich auf jeden 
Fall lösen).  Die sind doch nicht wichtig.

von spess53 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi

>Das Einzige, was unschön ist, dass erst ein Male-Male und Female-Female
>Gender Changer hintereinander gesteckt werden müssen, weil die Muttern
>sonst blockieren.

Entschuldige bitte, da ist mir ein kleiner Irrtum unterlaufen: Ich 
meinte eigentlich diesen

https://www.reichelt.de/usb-2-0-konverter-a-stecker-auf-rs-232-delock-61425-p121151.html?&trstct=pos_19

hier. Der Inhalt vom Delock 62589 dürfte identisch mit den des Delock 
61425 sein. Beide mit FTDI-Chips.

MfG Spess

von Alexander S. (alesi)


Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Entschuldige bitte, da ist mir ein kleiner Irrtum unterlaufen: Ich
> meinte eigentlich diesen
>
> 
https://www.reichelt.de/usb-2-0-konverter-a-stecker-auf-rs-232-delock-61425-p121151.html?&trstct=pos_19
>
> hier.

Hallo,

zur Info, so einen Konverter gibt es auch mit Kabel:
 https://www.reichelt.de/delock-usb-2-0-konverter-a-stecker-auf-rs-232-delock-65840-p219960.html?&trstct=pos_0
Allerdings ganz schöner Aufpreis für das Kabel.

Suche nach "DELOCK USB 2.0 Konverter A Stecker auf RS-232"
https://www.reichelt.de/index.html?ACTION=446&LA=446&q=delock%20usb%202.0%20konverter%20a%20stecker%20auf%20rs-232

von Karl B. (gustav)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Ich
> meinte eigentlich diesen

Hi,
überhaupt kein Problem. Hatte noch zwei Gender-Changer auf die Schnelle, 
sonst die Muttern rausschrauben, geht auch.
Hauptsache das Ding funktioniert neben der so wie so installierten 
I/O-Karte.
Deswegen der COM3 dann als Zuordnung.
Was mich wunderte war, dass im Gerätemanager nichts im Bereich der 
USB-Hubs zu sehen ist, aber bei Anschlüsse  (COM&LPT) da ist er zusehen.

Und Zum Test ein "Read" vom Flash klappt auch.:-)
Jetzt kann es ja weitergehen, nachdem diese Hürde genommen wurde.

Nochmals Danke an @Spess

ciao
gustav

von Karl B. (gustav)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
hier noch Auszug aus der Spec. Interessant auch der Warnhinweis vor 
Fakes.

ciao
gustav

von Oldmax (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi
Nun ja, die Discussion scheint dem ursprünglichen Thema doch 
wegzulaufen. Wenn ein blutiger Anfänger nach einem Einstiegscontroller 
fragt, dann sind Beiträge über ARM nicht hilfreich. Gut, im Detail hab 
ich nicht alles gelesen, aber wenn man anfängt zu laufen, dann ist es 
sehr selten, das es Tanzschritte sind. Meist ist es Stolpern und richtig 
Fällen. Ich hab mit dem Polinboard, einem AtMega8, AVR Studio und 
PoniProg angefangen. C könnte ich nicht und die Pascalcomputer verstand 
das Studio nicht. Also Assembler.Das ist einfacher als man denkt. Aber 
eben nur auf Controllerebene. In einem PC gelten andere Regeln. Zum 
Thema. Elektrotechnik hat nicht unbedingt etwas mit yc zu tun.Klar sind 
die überall drin, aber repariert wird da nicht mehr. Also bleibt es beim 
eigenen Interesse, diese Bauteile zu verstehen und da ist es hilfreich, 
eine Anwendung zu haben, ein Projekt. Etwas, was es zu kaufen so nicht 
gibt oder zu teuer ist. Und Zeit. Zeit und Geduld, denn ein Controller 
hat eine eigene Art, Befehle die man sich ausdenkt, zu befolgen.Such dir 
ein Projekt, einen geeigneten Controller mit entsprechender 
Programmierschnittstelle und Fang an. Vernünftig Gehen lernt man beim 
Laufen und irgendwann kann Mann dann auch tanzen.
Gruß oldmax

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Oldmax schrieb:
> Elektrotechnik hat nicht unbedingt etwas mit yc zu tun.

Kleiner Tip: AltGt-M macht ein µ

Und unter Linux macht AltGr-Shift-Q ein Ω

von Alexander S. (alesi)


Bewertung
1 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> Und unter Linux macht AltGr-Shift-Q ein Ω

So allgemein stimmt das nicht. Das hängt stark von der 
Linux-Distribution, Terminal oder GUI, Konfiguration von X, keymap, etc. 
ab.

von Karl B. (gustav)


Bewertung
0 lesenswert
nicht lesenswert
bloody_beginner schrieb:
> Mit welchem Mikrocontroller würdet ihr einem blutigen Anfänger
> heutzutage raten anzufangen?

Oldmax schrieb:
> Such dir
> ein Projekt, einen geeigneten Controller mit entsprechender
> Programmierschnittstelle und Fang an.

Hier gibt es Infos:
https://www.mikrocontroller.net/articles/AVR-Tutorial:_Equipment

Hier gibt's die verschiedenen Studio IDE-Versionen:
https://www.microchip.com/mplab/avr-support/avr-and-sam-downloads-archive

Dann eben den USB-zu Rs232 Konverter, der auch mit den "höheren" Windows 
zurechtkommt. Den Delock62589 habe ich getestet.

Dann gibt es da schon kleine Programme in ASM. Auch hier:
https://www.mikrocontroller.net/articles/Kategorie:AVR-Tutorial

Viel Spaß!

ciao
gustav

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Alexander S. schrieb:
> Stefanus F. schrieb:
>> Und unter Linux macht AltGr-Shift-Q ein Ω
>
> So allgemein stimmt das nicht. Das hängt stark von der
> Linux-Distribution, Terminal oder GUI, Konfiguration von X, keymap, etc.
> ab.

Jein, das ist seit einiger Zeit im deutschen Keyboard-Layout von X.org 
so drin, und damit ziemlich unabhängig von der Linux-Distribution. 
Funktioniert auf meinem FreeBSD bspw. genauso.

Aber das ist natürlich nur unter X11 mit einem deutschen Layout 
erstmal so der Fall, das ist richtig.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Karl B. schrieb:
> Hier gibt es Infos:

Nach einer knappen Woche an Diskussion brauchst du glaub' ich nicht 
wieder völlig von vorn anfangen, ohne auf die restlichen Beiträge 
einzugehen.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Aber das ist natürlich nur unter X11 mit einem deutschen Layout
> erstmal so der Fall, das ist richtig.

Dann muss ich irgendwas falsch machen, denn auf meinem Laptop 
funktioniert die Tastenkombination sowohl unter X11 als auch unter 
Wayland - einfach so ohne spezielle Konfiguration.

: Bearbeitet durch User
von Oldmax (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi
Ich hab meinen Beitrag mit einem Tablet geschrieben,daher das "y". 
Sorry. Gruß oldmax

von c-hater (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Oldmax schrieb:

> Ich hab meinen Beitrag mit einem Tablet geschrieben,daher das "y".

Auch auf Tablets und Smartphones kann man üblicherweise durchaus ein "µ" 
eingeben. Man muss eben nur LERNEN, wie das jeweils geht...

Ja, dazu ist Eigeninitiative und Eigenintelligenz erforderlich, sorry...

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Stefanus F. schrieb:
> sowohl unter X11 als auch unter Wayland

OK, Wayland kenne ich nicht. Weiß nur, dass es das gibt.

Vermutlich haben sie da einfach mal viele Defaults von X11 übernommen. 
Das wollte ich damit nicht ausschließen, sondern eher sowas wie die 
normale Textconsole.

von Beobachter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Oldmax schrieb:
>
>> Ich hab meinen Beitrag mit einem Tablet geschrieben,daher das "y".
>
> Auch auf Tablets und Smartphones kann man üblicherweise durchaus ein "µ"
> eingeben. Man muss eben nur LERNEN, wie das jeweils geht...
>
> Ja, dazu ist Eigeninitiative und Eigenintelligenz erforderlich, sorry...

Ja. Du bist wirklich sorry:-)

Das Sprichwort sagt aber, dass Bilder mehr als 1000 Worte sprechen... So 
waere es nett von Dir gewesen, vielleicht einen Link zu posten, wie.z.B. 
hier um die restliche Welt zu erleuchten:

https://www.imore.com/how-type-special-characters-and-symbols-your-iphone-or-ipad

mfg

von Oldmax (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi
Dank eurer hilfreichen Beiträge weiß ich jetzt auch, wie Umlaute auf dem 
Tablet gefunden werden und auch das μ. ?
Gruß oldmax

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]
  • [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.