[Umfrage] Evaluationsboards AVR, PIC, STM32

[Thomas B. (nichtessbar)]

Hallo,

[######## Zusatzinfo]
bin, wie bereits der ein oder andere vl. schon durch andere Beiträge 
meinerseits mitbekommen hat am Fertigstellen einer static library für 
diverse Prozessoren und dynamic libraries PCs (C#, C++, .NET generell, 
Java in Arbeit) die dann veröffentlicht wird. Hauptbestandteil wird ein 
Kommunikationsstack für multiprotokollfähige Bussysteme (RS485, ..) als 
auch End-to-End Verbindungen (USB>UART, RS232, ..) sein. Ziel dahinter 
ist die Kommunikation nur noch auf Applikationsebene abzuwickeln zum 
Preis eines kleinen Overheads. Adressierung, Fehlerbehandlung, 
Sendewiederholung etc. wird alles "intern" abgewickelt (und bitte jetzt 
keine Verweise auf CAN oder ähnliche Lösungen, die sind mir bekannt und 
geläufig, hab meine Gründe für ein eigenes Protokol ;))

Teilnehmer dieser Komunikation können sowohl PC (Windows, Linux) also 
auch Mikroprozessoren (hauptsächlich 8bit AVR+xmega, aber auch 
Portierung auf PIC und STM32 ist bis zur Veröffentlichung noch 
angedacht)

Ich möchte damit das ganze leicht verständlich wird und jeder schnell 
schaun kann ob das was für seine Zwecke ist oder nicht, für einige 
gängige Evaluationssysteme die eine möglichst große Masse daheim liegen 
hat Minianwendungen (a la LED-Schalten, Ports schalten, Speicher 
schreiben oder so...) zur Verfügung stellen zur schnellen Evaluation und 
zum Kennenlernen.

[######### /Zusatzinfo]


Würd mich interessieren welche (gängigen) Evaluationsboards ihr benutzt, 
diese Frage ist auch speziell an die Anfänger hier gerichtet! (Pollin 
Boards, Xplains, PIC Eval Boards, STM32-Discovery, ....).

Gerne auch Vorschläge für gern gesehne Demoprogramme, aber denke LED 
togglen ist da am ehesten verständlich auch wenn das nicht unbedingt die 
Möglichkeiten(derzeit wird an Filetransferprotokoll auf SD-Karte via 
Xmega gearbeitet, IIC-Tunneling am AVR) ausschöpft?

[Roland H. (batchman)]

ARM:
- lpc1343 Quick start board, LPCXpresso 1769
- stm32vldiscovery, stm32f4discovery

PIC32:
- PIC32 Pinguino Micro

AVR:
- atmega32u4-Module, z. B. von Reusch. Gibt aber inzwischen noch viele 
andere Anbieter
- atxmega-Module von ALVIDI
- atmega in DIP direkt auf Steckbrett

Die oben genannten Module bekommt man auch irgendwie auf eines oder zwei 
Steckbretter.

Weniger gängig, da "relativ" teuer; auch nicht "steckbrett-kompatibel":

Renesas RX:
- EVBRX62N von Glyn. Suche aber noch etwas, das im Preisbereich <= 25 
EUR liegt - kennt da jemand eines?

MSP430
- msp-ts430pz100b. Suche auch hier noch etwas, das im Preisbereich <= 25 
EUR liegt. Das Launchpad bzw. die msp430-DIPs haben für mich zu wenig 
Peripherie

Sind alle im Einsatz (GCC cross compiler, auch für PIC32, alles unter 
Linux). Jedes hat seine Mini-Macke(n), aber das ist Gejammere auf hohem 
Niveau. An den Dingern liegt es nicht, wenn die LED nicht blinkt ;-)

> Gerne auch Vorschläge für gern gesehne Demoprogramme

Pin toggle ist der beste Anfang - sofern das ".zip" komplett ist: 
Makefile, linker script, startup. Das Sahnehäubchen ist "clock setup" + 
"uart". Auspacken - make eintippen - fertig.

> hauptsächlich 8bit AVR+xmega

Angesichts der ARMada von 32-Bit-Prozessoren würde ich darüber nochmals 
nachdenken :-). AVR - insbesondere mit GCC - hat da einen sehr schweren 
Stand. Außer persönlich angesammeltem Know-How sehe ich keine 
Gründe/Vorteile für diese Plattform. Lass mich aber gerne überzeugen ;-)

[Thomas B. (nichtessbar)]

Danke Roland für die ausführliche Antwort.

Zu den 8bittern: Ist derzeit bei dieser Bibliothek neben dem PC das am 
besten unterstützte Gerät weil unsere gesamte Produktpalette in der 
Firma auf den Atmegas aufbaut (Atmega88/168 und die Tinys sind doch mit 
unter 1€ noch recht preiswert für kleinere Stückzahlen und wir bauen 
fast nur Sonderlösungen). So hatte ich eine gute Möglichkeit das ganze 
auch in der Praxis (Outdoor, Indoor, industrielle Umgebungen, ..) zu 
testen.
Plus im Hobbybereich sind die auch sehr beliebt, wenngleich jetzt glaub 
ich speziell mit STM32 ein 32bitter Hype startet, und das Rasperry PI 
wird glaub ich auch Einzug in viele Hobbywerkstätten finden. Vernünftige 
Rechenleistung wird zum Glück mittlerweile gut leistbar =)

Wird aber definitiv die 32bit Portierungen auch geben, auch wenns a 
bisserl dauert.


Das Sahnehäubchen ist zumindest beim normalen AVR+Xmega derzeit zum 
Preis eines kleinen Overheads bereits in der API enthalten:

Wobei mich das Parametrisieren der gewünschten UART auf den Atmegas 
ziemlich viel Nerven gekostet hat... aber es läuft schlussendlich!

volatile DevComSlave_t* slave = dcs_create(M3S_ADDR);
  
// RW-Output for DDR on Max485
slave->RWPort       = &PORTD;
slave->RW_bp       = PD2;
slave->RWPolarity     = 1;
  
dcs_start(UART0,(DevComSlave_t*)slave, F_CPU, 500000);  // Start @ UART0 with 0.5 MBaud

[Michael S. (Firma: electro-tester) (michael0307)]

Hallo Thomas,

Hatten wir hier schon mal :-)

Guckst du -> Beitrag "Womit programmiert ihr eure µCs?"

Grüße...

[Thomas B. (nichtessbar)]

Hey Michael,

den Thread kannte ich schon, mir gehts aber weniger um verwendete 
Sprachen und Programmer (die sind dafür eh mehr oder weniger ganz 
egal...) sondern um fertige Experimentierboards die man so daheim 
herumstehen hat.

Möchte eben für die gängisten Beispielprogramme zur Verfügung stellen 
die die Peripherie am Experimentierboard/Evaluierboard nutzen (sei es 
jetzt LEDs, Relais, eine SD-Karte, ...).

Von Atmel weiß ich zum Beispiel dass das Pollin AVR-Board (V2) relativ 
gern hier im Forum empfohlen wird, AVR-NET-IO ist auch einigermaßen 
häufig, Xplain Boards werden eher von Firmen verwendet und von Atmel 
auch gerne mal an ihre gewerblichen Kunden verschenkt als Muster.

Speziell bei den PICs bin ich nicht so bewandert und weiß nicht was da 
üblich ist... Deshalb meine Frage hier, vl. lässt sich ein Trend 
ableiten

Alternativ dazu geht natürlich für unterschiedliche Prozessoren und eine 
einfache Steckbrettschaltung was anzubieten, aber wenn ich mir eine 
Bibliothek anschaun will ob die für meine Zwecke genügt, möchte ich 
nicht erst a Schaltung stecken oder Software auf eine bestehende 
portieren müssen. Lieber a Ding das 100% funktioniert ausm Regal nehmen, 
flashen mit einem Demoprogramm das es schon gibt und ausprobieren und 
erst wenns sich was tut dann mal schaun wie das ganze im Hintergrund 
funktioniert, wie ich das adaptieren kann usw.