Einstieg finden CC²-ATmega oder doch besser 8051

Wed Feb 17, 2010 9:44 pm   

Joerg wrote:


Die Cypress Chips sind schön, aber der 8051 Kern den die verwenden, ist
schnarchlangsam. Daher setzt Cypress ja auch mit der PSoC 5 Architektur auf
ARM Cortex-M3. Der VW Käfer wird seit 2003 nicht mehr gebaut, heutzutage
ist VW Golf angesagt :-)

--
Frank Buss, fb_at_frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Wed Feb 17, 2010 10:29 pm   

Frank Buss wrote:


Schon klar, die haben auch Raketen. Oft reicht jedoch ein schnarchlanger
uC aus. Hierzulande ist es manchmal wichtiger dass man moeglichst vor
Ort Leute bekommen kann die das programmieren. Bei einigen Projekten
haben wir uns dabei fast ein Bein ausgerissen. Ist nicht ganz so schlimm
wie bei Analogelektronik, aber demnaechst droht sich an dass wir einen
MSP430 Spezi mit etwas Wireless Erfahrung in der Gegend von Houston
finden muessen. Ein wenig graut es mir jetzt schon davor, die Auswahl
duerfte bei weitem nicht so sein wie fuer ein 8051 Projekt. Sag Bescheid
wenn Dir die kalten Winter in Koeln zuviel werden :-)



Aber den hier gibt's noch frisch ab Werk:

http://www.volkswagen.com/br/pt/modelos/kombi.html

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Wed Feb 17, 2010 11:25 pm   

Joerg wrote:


Meist kann man mit einer klein wenig größeren CPU problemlos alles in C
machen. Ich habe bisher noch nie größere Dinge kommerziell in Assembler
gemacht, das letzte mal auf dem C64 (wurde an ein Disk-Magazin verkauft)
und da mit einem guten Macro-Assembler. Hängt aber natürlich vom Projekt
ab. Wenn man wirklich den letzten Cent sparen will, muß man in Assembler
programmieren. Fragt sich, ob sich der Entwicklungsaufwand lohnt. Dafür muß
die Stückzahl hoch sein und die CPU-Kosten einen großen Teil ausmachen.

In die Register und Features einer CPU einarbeiten kann sich ein guter
Programmierer nebenbei, wenn er schon ein paar andere Microcontroller
kennt.


Letztens in den Nachrichten sah es in New York auch nicht besonders
gemütlich aus. Aber ein Ausflug nach USA wäre mal nicht schlecht, bin aber
mindestens bis Ende dieses Jahres noch mit mehreren Projekten beschäftigt
und komme aktuell noch nicht mal dazu die Software für meinen
Frequenzzähler zuende zu schreiben und zu testen. Vielleicht mal an einem
Wochenende, wenn ich keine Lust auf Klavier spielen habe :-)

--
Frank Buss, fb_at_frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Wed Feb 17, 2010 11:48 pm   

Frank Buss wrote:

Die meisten 8051 Projekte mit denen ich zu tun hatte wurden vom
Programmierer auch in C geschrieben. Normalerweise mit dem Keil Compiler
verwurstet.



Das schon, allerdings wird das bei meinen Chosen oft eklig. Da laufen
Routinen zeitsynchron zu irgendwas draussen ab, die Zeit wo er in
dormant Mode geht und wieder rauskommt muss auch synchronisiert sein,
und so weiter. Wenn man das mal eben auf einen anderen uC umfriemeln
will kommt echt Stress auf.

Bei den aelteren 8051-Leuten ist es schoen, wenn die einem sagen "Also
wenn wir das so und so machen dauert das ungefaehr xxx Takzyklen,
kriegen wir hin".



Da herrscht gerade Global Warming in Reinkultur :-)

Obwohl auch in Florida einem Bekannten ein unterirdisches
Hauptwasserrohr gefroren und geplatzt ist. Das hatte bis diesen Winter
selbst unter den alten Bewohnern niemand fuer moeglich gehalten.

Eines sollte man bei allem Schwaermen vom Urlaubsklima was dort
normalerweise herrscht nicht verschweigen: Die hohe Luftfeuchte. Ab 25C
faengt das bei manchen Leuten an richtig auf den Kreislauf zu gehen. Ist
beinahe so wie in Puerto Rico, wo ich mal mit einem Bekannten zum
Fruehstueck ging. Im Gegensatz zu mir ein voll durchtrainierter
Sportler. Nach wenigen Minuten lief dem die Bruehe das Gesicht runter,
das Hemd voll durchgeoelt und er fragte "Mensch, wie haltet ihr sowas
bloss aus?"

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.

Thu Feb 18, 2010 12:32 am   

Joerg wrote:


Die Keil Compiler sollen gut sein, da lohnt sich Assembler gar nicht, auch
bei 8 bittigen CPUs.


Klar, wenn du da schon was hast, dann kann das Sinn machen, einen MSP430 zu
nehmen. Moderne ARM-Microcontroller haben dagegen viele neue Möglichkeiten,
z.B. Fast Interrupts mit Register Bank Switching usw., was dann auch
kritische Timingsachen einfacher macht, wenn man beide für Architekturen
was neues implementiert.


Ja, um das sicher einschätzen zu können, braucht man schon Erfahrung. Ich
probiere sowas gerne aus. Wenn ungefähr klar ist, was gemacht werden soll,
dann ein Eval-Kit mit der CPU kaufen und ein paar projektkritische Routinen
testen, um zu sehen, ob es leistungsfähig genug ist. Wenn nicht, dann einen
größeren Microcontroller nehmen :-)

--
Frank Buss, fb_at_frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Thu Feb 18, 2010 1:30 am   

Moin,

Frank Buss <fb_at_frank-buss.de> writes:


Das stimmt. Bei mir ist bisher nur der Startup-Code in Assembler. Der
Keil optimiert so sauber und den Startup-Code liefert der auch noch für
alle Typen mit, da muss man selten mal ran.

73 de Tom
--
DL7BJ * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19 * http://www.dl7bj.de

Sat Feb 20, 2010 9:13 pm   

Thomas 'tom' Malkusschrieb:
"


Also auch der Bastler will sicher mal, wenn er über den Anfängerstatus
mit LED blinken usw. hinausgekommen ist, ein Display o.ä. anschließen.
Dann ist es aus mit 8bit und 8051. Dann wird es selbst für einen
16bitter schwierig.

Wenn ich schon 16bit-Register habe (Timer, Capture/Compare, PWM), dann
würde ich schon ganz gern auch mit 16bit rechnen. Zumal der
Preisunterschied für einen Bastler zwischen 8-/16- und 32bit völlig
unerheblich ist.

Als nächstes stellt sich dann die Frage, ob ich stumpfsinnige
Kernelfunktionen schreiben (nochmal neu erfinden), oder doch lieber
gleich zu einem embedded OS greife und mich lieber um meine
Applikation, also meine eigendliche Anwendung kümmern will.


Dirk

Sat Feb 20, 2010 10:14 pm   

Am 20.02.2010 20:13, schrieb Dirk Ruth:


Du meinst man sollte, wenn AVR's genommen werden,
die verh...sten von C...ad nehmen?

Wenn man sich die Compiler anschaut und die existierenden kostenfreien
Bibliotheken, so kann man bei modernen Entwicklungswerkzeugen fast vom
System sprechen. (Außerdem kann man das Rad nicht mehr neu erfinden,
http://www.hl7.org.au/docs/Australian%20Patent%202001100012.pdf)

Sat Feb 20, 2010 10:37 pm   

Dirk Ruth <d.ruth_at_itecnet.de> writes:


Das kann der Bastler auch gerne tun. Ich werde keinen 32 Bit Controller
für eine Steuerung einsetzen, bei der ein 8 Bit Controller ausreichend ist.


Es gibt Anwendungen, die brauchen keine 32 Bit, keinen 16 Bit und auch
kein Embedded OS. Ich verwende auch 32 Bit ARM Controller mit Linux als
OS. Aber deswegen setze ich das nicht für jede kleine Steuerung ein,
mal abgesehen davon, dass ein OS auch höchst hinderlich sein kann.

Es gibt genügend Anforderungen für 8 Bit Controller, es gibt genügend
neue Controller mit 8051er Kern und entsprechend Second Source.

Aber die Leute, die mit den Controllern umgehen können werden immer weniger,
weil alle Welt 32 Bit mit Embedded OS und Superdisplay haben will.

Mir nur recht

73 de Tom
--
DL7BJ * DL-QRP-AG #1186 * AGCW-DL #2737 * DARC OV I19 * http://www.dl7bj.de

Sat Feb 20, 2010 10:48 pm   

On Sat, 20 Feb 2010 20:13:04 +0100, Dirk Ruth wrote:


Das führt dann zur Gretchen-Frage:
Welche Randbedingungen hat die angepelite Anwendung?
Um einen Sensor auszulesen und den Wert zur gefälligen Betrachtung auf
einem Display darzustellen, benötigt man nicht wirklich ein
Betriebssystem. Wenn die Messwerte in Formeln integriert und über
Ethernet abgefragt werden sollen, sieht es schon anders aus. Und wenn es
um zeitkritische Messungen geht, hat man es mit einem anderen BVündel von
Schlangen zu tun.

---<(kaimartin)>---
--
Kai-Martin Knaak
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53

Sun Feb 21, 2010 4:56 am   

Stefan Englerschrieb:
"

Was für Buchstaben muss ich da jetzt einsetzen? Ist das ein
Einstellungstest?



Schöner Link )


Dirk

Sun Feb 21, 2010 5:31 am   

Thomas 'tom' Malkusschrieb:
"

Das schrub ich auch nicht.


Das schrub ich auch nicht.


Ein OS bietet vor allem gute generische, elegante und sehr
übersichtliche Lösungen für immer wiederkehrende Probleme auf einem
Controller bei denen auch gestandene embedded Programmierer immer
wieder auf die Nase fallen. Das habe ich oft genug auch in
mittelständischen Firmen gesehen, wo Leute schon seit 15 Jahren jeden
Tag Software entwickeln. Da gibt es einige klassische Probleme, wo
immer wieder ohne Ende irgend etwas zusammengemurkst wird, weil es
ohne OS einfach keine guten generischen Lösungen gibt. Einige
Beispiele könnte ich hier nennen.



Auch die hier oft empfohlenen AVR-Seiten im Internet sind fast
ausnahmslos ein Quell vermurkster Software, die nur funktioniert, wenn
es auf den Controller läuft, dessen Header oben includiert ist und der
am gleichen Quarz läuft. Da sieht man dann tolle Software-Beispiele,
wo sich über Seiten immer eine Zeile echten Codes mit einer
while-Schleife für ein delay abwechselt. Wenn man solchen Müll einem
Anfänger gibt, dann kann man auch nicht erwarten, dass der irgenwann
mal besseren Code schreibt. Wenn man sieht, dass auf der
Applikationsebene irgendwelche Bits in irgendwelchen
Hardware-Registern gedreht werden, dann kann einem einfach nur noch
schlecht werden.
Hatte auch schon so einige Projekte, die über ein paare Jahre
gewachsen waren und schon den ein oder anderen Prozessorwechsel hinter
sich hatten. Da blieb dann nur noch alles wegzuschmeißen und komplett
neu anzufangen, weil durch den vermurksten Code neu machen einfach
billiger war. Schade um die Zeit die da drin steckte.

Gute generische und portable Lösungen zu entwickeln ist weitaus
schwieriger, als irgendwelchen Code, den man gerade in Gedanken hat
runter zu tippen, vielleicht noch in Kombination mit Timings, die man
ebend mal schnell mit dem Scope ausgemessen hat.


Einem Anfänger würde ich sowieso erstmal empfehlen, bevor er einen
Compiler installiert, sich ein gutes Style-Guide zu besorgen und sich
mal durch MISRA zu arbeiten.
Arbeitsweisen die sich bei den Profis durchgesetzt haben können sicher
auch für einen Anfänger von Vorteil sein.
Das ist dann so, als wenn der Heimwerker mit gewerblichen Werkzeugen
arbeitet.



Dirk

Sun Feb 21, 2010 10:16 am   

Der Autor dieses bekannten Buches:
http://en.wikipedia.org/wiki/The_Mythical_Man-Month
weist dann aus Erfahrung hin auf:
http://en.wikipedia.org/wiki/Second-system_effect
\ second-system effect ... refers to the tendency,
\ when following on from a relatively small, elegant,
\ and successful system, to design the successor
\ as an elephantine, feature-laden monstrosity.

Das ist dann wohl die "generische Lösung" die
Portabilität, Einheitlichkeit & viele andere
Sekundärtugenden propagiert.

MfG JRD

Sun Feb 21, 2010 10:24 am   

Dirk Ruth <d.ruth_at_itecnet.de> schrieb:


....bei weitem nicht immer notwendig. Eine generische und portable
Lösung kostet einfach mal ein Mehrfaches an initialem Aufwand, und
gerade für des Bastlers Einzelgerät ist dieser Aufwand schwer zu
rechtfertigen: der wird das nicht in drei Jahren nochmal mit einem
völlig anderen Controller und entsprechend anderer Peripherie neu
bauen müssen. Selbst wenn: der Aufwand für die saubere generische
Lösung wäre selbst dann noch nicht gerechtfertigt, wenn er die zweite
Implementierung komplett nochmal von vorn schreibt.

Lass mal die Kirche im Dorf. Hier ging es nicht um Produkte, die in
Tausender Auflagen über 10 Jahre hinweg zu bauen und zu pflegen sind.


MISRA scheitert für einen Hobby-Anfänger schon daran, dass es Geld
kostet. Außerdem kenne ich auch in der Industrie keinen, der das
freiwillig verwendet. Es gibt eine Reihe von Leuten, für die es
gemacht worden ist und die es nehmen müssen, es gibt viele sinnvolle
Dinge da drin, aber es gibt auch viele Regeln, die aus den
Unzulänglichkeiten von C-Compilern des letzten Jahrtausends entstanden
sind und in der dort geforderten strikten Form keinen Sinn mehr haben.
Selbst die neueren des aktuellen C-Standards (der ja auch noch aus dem
letzten Jahrtausend stammt) haben dort noch keinen Einzug gehalten,
damit kann ich das Teil einem Anfänger nicht mehr als "große
Leitlinie" guten Gewissens vorsetzen. Ich weiß, es gibt auch
genügend Compiler-Hersteller, die zu faul sind, sich dieses
C-Standards mal anzunehmen. Den sollten aber die Kunden, die
schließlich dafür Geld zahlen, mal auf die Finger klopfen, dass sie
das auch haben wollen, nachdem Opensource das ja nun schon eine ganze
Weile hat.

--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL

http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for.

Sun Feb 21, 2010 12:57 pm   

Joerg Wunsch wrote:

Definiere "generisch und portabel". Ich baue, wenn möglich, meine
Programmmodule generell so, dass sie z.B. mit
#ifdef TEST
int main() {
assert(...);
assert(...);
}
#endif
enden und auf dem PC als Unit-Tests übersetzt werden können. Zugegeben,
für eine LED-Blink-Schaltung ist das vielleicht nicht so relevant. Seit
ich das tue, ist die Zahl der Module, die ich ins Produktivsystem auf-
nehme und die einfach funktionieren, deutlich gestiegen. Außerdem hab
ich keine Lust auf Konstanten im Code ("UART_DLL = 17; UART_DLH = 3;"),
also baue ich die Module so, dass Quarz-Takt und gewünschter Ausgangs-
takt Eingangsgrößen sind.


Unter
<http://portal.automotive-his.de/images/pdf/SoftwareTest/his_subset_misra_c_1.0.3.pdf>
bekommt man einen Teil der Regeln in knapper Form. Außerdem gibt es
unter <http://www2.research.att.com/~bs/JSF-AV-rules.pdf> auch noch
einen Satz Codierregeln.


Insbesondere sieht man MISRA recht gut an, dass es vielleicht für die
Implementation von Motorsteuergeräten gedacht ist, aber nicht für
Größeres wie das Infotainment-Gedöns oder generell irgendwelche Dinge,
die Text anzeigen. MISRA verbietet z.B. eigentlich stdio, errno usw.;
deswegen schmeiß ich aber nicht all meinen (portablen!) Code weg und
implementier den fehlerträchtig mit einem eigenen Dateisystem-API neu.


Stefan