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?
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 ;-)
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!
1
volatileDevComSlave_t*slave=dcs_create(M3S_ADDR);
2
3
// RW-Output for DDR on Max485
4
slave->RWPort=&PORTD;
5
slave->RW_bp=PD2;
6
slave->RWPolarity=1;
7
8
dcs_start(UART0,(DevComSlave_t*)slave,F_CPU,500000);// Start @ UART0 with 0.5 MBaud
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.
