AtxMega oder doch lieber Atmel ARM

Simon schrieb:
> bisher dachte ich ich fahre mit einem XATXmega32A4 und dem ENC28J60
> sowie noch einem RTC ganz gut.

Warum Du an den Xmega noch einen externen RTC ranhängst, ist mir ein 
Rätsel. Vermutlich aus alter Gewohnheit vom vorigen Jahrhundert. Nur die 
ganz alten AT90Sxxx hatten noch keinen Power-Save Mode.

Bei ARM mit Ethernet muß man aufpassen, die haben oft nur ein halbes 
Ethernet (MAC ohne PHY) drin.
Volles Ethernet haben z.B. die ARM Cortex M3 von TI (Luminary).


Peter

Simon schrieb:
> ich benötige, 1xSPI, 1x Ethernet, 1x RTC.
>
> bisher dachte ich ich fahre mit einem XATXmega32A4 und dem ENC28J60
> sowie noch einem RTC ganz gut.
>
> Nur jedesmal wenn ich auf der Atmel Seite die SAMxx Serien sehe.. die
> haben das
> alles schon mit integriert.
>
> Da stelle ich mir einfach die Frage, warum nehme ich einen ATXMega, wenn
> der
> SAMxx das meiszte schon mit bringt.

Das frage ich mich bei vielen Projekten hier auch.

Wie viel Rechenleistung brauchst Du?

Wenn es nur darum geht, ein paar I/Os zu schalten, nehme ich einen 
PIC18F67J60. Das ist die billigste und einfachste Ethernet-Lösung auf 
dem Markt, praktisch ein ENC28J60 mit eingebautem Prozessor, also 
wirklich eine Ein-Chip-Lösung. Billiger geht es nicht, und der 
Microchip-Stack ist leistungsfähiger als das übliche Zeugs von Adam 
Dunkels (uip/lwip).

Die größeren Prozessoren wie die PIC32MX6xx/7xx oder die von Dir 
erwähnten Atmel SAM-Serien haben den Ethernet MAC, also den Digitalteil 
bereits eingebaut. Der PHY, also der Analogteil ist fast immer ein 
separater Chip, weil es von der Fertigung her schwer ist, die 
unterschiedlichen Halbleiterprozesse auf einem einzigen Chip 
unterzubringen. Der obige PIC ist da eine seltene Ausnahme, es gibt noch 
ARMs von TI und einen Coldfire-Chip von Freescale.

> Wie sieht es hier in sache schwierigkeit aus? bietet Atmel einen TCP
> Stack für seine SAM serien?

Atmel hat hier nix selber gemacht im Gegesatz zu Microchip, die gut für 
ihre User sorgen, hier nimmst Du die üblichen uip oder lwip Stacks, die 
alle verwenden, aber so ihre Schwächen haben. Ich habe die Kombination 
TI ARM+uip/lwip (ich habe beide durchprobiert) in einem Projekt auch 
verwendet, aber der Microchip-Stack mit seinem Webserver auf dem kleinen 
PIC war echt fixer in den Antwortzeiten als der eigentlich deutlich 
schnellere ARM, der nach dieser Erfahrung rausflog.

> Wie sieht es mit Entwicklungstools aus, ich kann wohl kaum mein AVRISP2
> nehmen.

nein. Für ARM nimmst Du am Besten einen Segger JLink, für die 
Microchip-Controller (egal ob 8,16,32 Bit) ein PicKIT3 oder den 
schnelleren ICD3.

> Kann man hier auch den AVR-GCC nehmen?

Der ist, wie schon der Name vermuten lässt, ausschließlich für AVR. Für 
ARM gibts einen eigenen, und für die PICs wirst DU die 
Microchip-Compiler verwenden.

> DIe nächste Frage ist die Preisfrage, so ein SAM kostet doch maximal 3
> oder 5 EUR mehr, was mir für mein Projekt egal wäre.

Eben bei Farnell geschaut: 10'er Nettopreise

ATXmega32A4 3,45€
ENC28J60    2,33€
Summe:      5,78€

PIC18F67F60 3,56€

LM3S6911    9,28€ (ARM mit Ethernet Mac+Phy)

Bei den SAM's habe ich auf die schnelle keinen passenden gefunden, aber 
gehe davon aus, dass Du mit den externen PHY in etwa so bei 7-10€ landen 
wirst.

fchk

Simon schrieb:
> Mooooooment, heißt es ich kann im Powersave einen Takt mitlaufen lassen?

Ja.
Nur der Timer am 32kHz Quarz läuft, der Rest des MC schläft.

Simon schrieb:
> nur woher bekomme ich die Kalender funktion etc?

Im Interrupthandler einfach ein paar Variablen zählen. Oder die Sekunden 
als 32Bit und dann umrechnen.


Peter

Simon schrieb:

> Wenn ich jetzt den wechsel zu Microchip mache, da stehe ich doch wieder
> bei 0 da, sowohl von der Erfahrung als auch von der benötigten Hard und
> Software.

Das ist bei ARM nicht anders. Jeder Hersteller macht sein eigenes Zeugs. 
Aber Du lernst auch einiges dabei, und bei der n-ten Architektur weißt 
Du dann, wie es geht.

> Die Frage ist natürlich auch hier wenn ich nun ein paar Microchips
> bestelle + den Programmieradapter ob ich da schneller und zufriedener am
> Ziel bin als jetzt den Ulrich Radig TCP/Ip Stack auf den ATXMega zu
> protieren und dann vielleicht enttaeuscht festzustellen das es nicht
> anständig funktioniert.

Ob DU dann zufriedener bist, weiß ich nicht.

>> Der ist, wie schon der Name vermuten lässt, ausschließlich für AVR. Für
>> ARM gibts einen eigenen, und für die PICs wirst DU die
>> Microchip-Compiler verwenden.
>
> Und die gibts nur für windows?

Nein, das neue MPLABX und die neuen Compiler gibts auch für Mac OSX und 
Linux. Das ist allerdings noch nicht so gut abgehangen wie die älteren 
Sachen, und deswegen bleibe ich persönlich erstmal beim alten MPLAB8 und 
den alten Compilern. Ich bin da etwas konservativ, allerdings verdiene 
ich damit auch mein Geld.

Eine Motivation, Microchip-Zeugs hier einzusetzen, ist auch, das 
Microchip ein extrem zuverlässiger Lieferant ist. Du kannst heute immer 
noch die alten PIC16C54 von 1983 kaufen, als Microchip noch General 
Instruments hieß und unter anderem die AY-8910 und AY-8912 Soundchips 
für die Atari ST und Amstrad/Schneider CPC fabriziert hat. Einige Kunden 
haben ganz gerne Liefergarantien von 10 Jahren und mehr. Da traue ich 
mich nicht, Atmel einzusetzen.

fchk

Alleine schon eine 16- oder 32- Bit Variable im Interrupt beschreiben zu 
können, und um Hauptprogramm auszulesen, ohne extra die Interrupts 
sperren zu müssen, ist schon ein starkes Argument für 32-bitter. Wenn 
man dazu noch die tausend verschiedenen ATMEL Programmer betrachtet, die 
gerade alle anderen Typen programmieren können, aber genau den benutzten 
Typ nicht, hat man ein weiteres Argument. Und für Arm spricht noch die 
weite Verbreitung kostengünstiger In-Circuits Debugger.

Simon schrieb:
> Ich bin gerade auf den Microchip Seiten unterwegs,
> also die bieten da auch in sachen USB fertige Beispiele an.
> USB Stick Treiber und FAT32 alles kein Thema da.

Weißt Du jetzt, was ich mit Herstellersupport meine?

Und Du darfst das alles auch kommerziell benutzen, ohne Dir über solche 
Sachen wie GPL und Offenlegung Deines Codes Gedanken machen zu müssen.

fchk

Simon schrieb:
> Ich hab gerade bemerkt es gab schon einige einträge im Forum zu dem
> Thema,
> im groß und ganzen, will die mehrheit den ATxMega irgendwie nicht.

Stimmt. Er ist zu spät, zu langsam und zu teuer, und die ersten hatten 
ziemlich ärgerliche Bugs. Gut, letzteres ist keine Spezialität von 
Atmel, auch andere Hersteller können das Gut, z.B. Luminary (jetzt TI), 
wo bei den meisten LM3S-ARMs die Hibernate Unit nicht funktioniert.

> Jetzt frage ich mich natürlich wenn ich einen ARM nehmen möchte,
> von welchem Hersteller sollte ich das tun wenn mir wichtig ist das es
> unter linux mit dem gcc compiler wirklich tadellos funktioniert?

Es ist völlig egal. Der CPU-Kern und die Debug-Einheit ist immer das 
gleiche. So lange der gcc neu genug für den entsprechenden Kern ist, 
spielt der Rest keine Rolle. Achte darauf, dass der JTAG-Adapter nicht 
nur JTAG, sondern auch SWD kann, d.h. Zweidraht-JTAG. Speziell bei 
kleineren Chips hast Du sonst ein Problem, und JTAG braucht 
normalerweise ziemlich viele Pins (zu den üblichen TMS/TCK/TDI/TDO kommt 
oft noch RTCK und TRST dazu, das sind schon 6 Pins, die Du dann nicht 
mehr anderweitig nutzen kannst).

> oder wie Christian schon sagte BeRTOS und den SAM3X?

Auch das ist ein normaler ARM, und RTOSe gibts mehr als eines.

> Es muss doch eine Möglichkeit geben, hier schnell und einfach zu einem
> TCP/IP fähigem Controller zu kommen. Es gibt doch auch sonst immer für
> alles Beispiele die out-of-the-box funktionieren.

out-of-the-box ist nicht die Stärke der ARMs, weil zu viele Dinge aus zu 
vielen verschiedenen Ecken kommen: der Chip von A, der Debug-Adapter von 
B, der Compiler von C, dazu die IDE von E und Bibliotheken von F, G und 
H.

Bei den PICs kommt alles von M, und damit hast Du es am Anfang 
wesentlich einfacher.

fchk

Simon schrieb:

> Nehmen wir mal an ich möchte was von Microchip, was für ein
> Programmieradapter könnte man mir empfehlen?

PicKit3 für den kleinen Geldbeutel, ICD3 für höhere Ansprüche. Mehr 
Auswahl hast Du ohnehin nicht.

> Frank sagte schon er soll mindestens SWD können, auf welche trifft das
> zu?
Das gilt nur für die ARMs und trifft auf Microchip nicht zu.

> Welchen Microchip nehme ich am besten?
> MAC lieber im Microcontroller oder doch eher getrennt?
> http://www.microchip.com/pagehandler/en-us/technology/ethernet/technology.html

Immer intern, wenn Du es schnell haben willst.

Auszug aus der Doku zum Microchip TCP/IP-Stack: UDP-Durchsatz in 
kBytes/s
PIC18F97J60+interner MAC/PHY(*): 113
PIC18F8722+ENC28J60: 63

PIC32MX795F512L+ENC28J60 (SPI, 10 MBit/s): 456
PIC32MX795F512L+ENC624J600 (SPI, 100 MBit/s): 784
PIC32MX795F512L+ENC624J600 (16 Bit Parallel PMP, 100 MBit/s): 2071
PIC32MX795F512L+interner MAC (100 MBit/s): 8449

Du siehst:
1. Bei den kleinen 8-Bittern ist der PIC mit integriertem Ethernet 
doppelt so schnell wie der mit externem Ethernet über SPI. Der CPU-Kern 
und die Rechenleistung der beiden Chips ist exakt gleich.
2. Beim PIC32 siehst Du den Effekt der externen Anbindung. Zwischen SPI 
und dem internen MAC liegt fast ein Faktor 10, und bei 8.5MByte/s ist 
Fast Ethernet fast völlig ausgelastet.

> Das ganze soll nur stabil laufen.
> 1x Ethernet  (HTTP Client)
> 1x USB Host (zum speichern auf USB Stick)
Ich empfehle Dir DRINGEND, den USB-Stick durch eine SD-Karte zu 
ersetzen. Das reduziert den Softwareaufwand um zwei Zehnerpotenzen, was 
Zeit und Codegröße angeht). Ein USB Host ist sehr komplex, und ohne 
passendes Werkzeug wirst Du scheitern.(**)
> 1x SPI
>
> Performance ist ansich auch kein thema,
> ich übertrage übers Ethernet nur sehr wenig an Daten.

(*) Der 18F97J60 ist die 100Pin Version des 18F67J60. Hier sind 2 UARTS 
und 2 MSSPs (SPI/I2C) herausgeführt. Es gibt noch eine 80-Pin Version 
18F87J60. Mit Ausnahme der Pinanzahl und damit der I/O-Ports sind die 
drei Chips identisch.
(**)  Ein USB Device hingegen ist eine Zehnerpotenz einfacher.

fchk

PicKit3 und ICD3 können so ziemlichalle aktuellen 8, 16 und 32 Bit PICs 
programmieren und debuggen.

Der ICD3 ist halt schneller.

fchk

Simon schrieb:
> Wenn der compiler der gcc ist, so kann ich doch auf das MPLAB doch auch
> verzichten oder nicht.

Nein, das brauchst Du, da da der Debugger drin ist. Du hast in diesem 
Fall keine Alternative. Wenn Du das nimmst, was Du nehmen sollst, ist es 
sehr einfach. Ansonsten sehr schwierig. Die Microchip-Compiler haben 
spezielle Anpassungen für die Chips drin. Die PIC32 haben zwar einen 
MIPS-Kern, aber damit das alles anständig schnell läuft, muss der 
Compiler MIPS16 Code erzeugen können, und ein normaler gcc kann das 
nicht. Außerdem darfst Du die Libraries rein lizenztechnisch nur 
zusammen mit den Microchip-Compilern verwenden.

> ich hatte hier bisher avr-gcc und avrdude, die zwei muss es doch für
> microchip auch geben sowas wie micro-gcc und micro-dude :-)

Ich kann meinen dringenden Rat nur wiederholen: Nimm das Zeugs von 
Microchip und benutze es so, wie es vorgesehen ist, ansonsten bist Du 
völlig auf Dich alleine gestellt, und Du verlierst jeglichen Support.

> Ich hab mir nun den:
>
> PIC32MX664F064H
> http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en552070
>
> das Teil erfuellt mir viele wünsche auf einmal,
> z.B. ist da Ethernet MAC und auch ne RTCC drinne, was will man also
> mehr.

Reíchelt hat die Teile.

fchk

Den ENC28J60 würde ich nicht mehr nehmen, zu verbuggt und zu 
stromhungrig. Als Alternative bietet sich der KSZ8851-SNLI von Micrel 
an, der noch dazu mit 100MBit daher kommt. Zusammen mit einem XMEGA 
kommt da schon eine gute Performance zusammen.

Simon schrieb:
> Was spricht gegen einen PIC18F97J60 mal abgesehen davon das es eine 8Bit
> MCU ist, hat er doch den MAC und PHY gleich mit drinne oder?

Ja. Siehe Bilder. Wenn Du nur einzelne Bits schalten willst, brauchst Du 
nicht mehr.

fchk

Simon schrieb:
> Was mich ein wenig wundert, der PIC18F97J60 hat im Datenblatt was von
> 21mA bei 40MHz. und der Ethernet Teil? incl Magnetics?

Steht ein paar Seiten weiter ("Module Differential Currents")

> Ich finde auch keine Beispiele für den PIC, die ganzen Beispiele
> beziehen sich immer auf einen PIC32 mit externem PHY.

Die Microchip Application Libraries enthalten alles, was Du brauchst. 
Der Stack ist für 8, 16 und 32 Bit PICs identisch, sprich es ist 
derselbe Quellcode.

fchk

Simon schrieb:
> Ja nur inzwischen sage ich mir, Microchip bietet echt feine sachen an,

Ja, wer´s glaubt. Wir mussten aufgrund hoher Stromaufnahme, 
EMV-Problemen und immer neuer/anderer Bugs per Revision des ENC28J60 ein 
Design kippen. Haben es gegen XMEGA und KSZ8851 ausgetauscht und waren 
entschieden glücklicher damit.

Simon schrieb:
> ooh das sieht aber gut aus das Teil.
>
>
> Gibt es für diese Platine die du da hast eventuell einen Schaltplan
> oder/und vielleicht auch den code dazu?

Nimm das hier:

https://www.olimex.com/Products/PIC/Proto/PIC-P67J60/

Das ist im Prinzip das gleiche in anderer Bauform.

Wenn Du einen 18F97J60 anstelle des 18F67J60 haben willst, nimm das 
hier:

https://www.olimex.com/Products/PIC/Development/PIC-MAXI-WEB/

Das hier soll ein 1:1-Ersatz vom PicKit3 sein. Ich habe das nicht 
getestet (habe selber einen originalen ICD3), daher das "soll".

https://www.olimex.com/Products/PIC/Programmers/PIC-KIT3/

fchk

Simon schrieb:
> hast du da Beispielcode/Schaltplan für den aufbau mit ATXMega?

Schaltplan ist einfach, der KSZ2251 hört auf SPI, dazu kommen noch eine 
Interruptleitung, Reset und Power-Management. Den Stack hat mein Kollege 
geschrieben. Aber es existieren im Netz noch einige Codesegmente, siehe 
hier:

Beitrag "Ethernet-Controller KSZ8851SNL, Erfahrungen?"

Das Schöne an dem KSZ8851 ist, dass einige nervige Arbeiten 
(CRC-Berechnung und Überprüfung zum Beispiel) bereits im Chip und bis 
zum IPv6-Header integriert sind. AUTO MDIX kann er auch.

Simon schrieb:
> Ein Frage hätte ich noch:
>
> "PIC18F97J60+interner MAC/PHY(*): 113"
>
>
> Wie sieht es da mit der Auslastung von der MCU aus?
>
> ist der da 100% beschäftigt mit ethernet? und alles andere bleibt
> hängen?

Als Testprogramm lief nur ein UDP-Sender (ist in den Demos enthalten), 
sonst nichts, und der hat natürlich alle Rechenzeit bekommen. Normal 
bist Du dafür verantwortlich, dass alles weiterläuft. Du musst den Stack 
periodisch aufrufen, damit er Pakete empfangen und verarbeiten kann. Das 
siehst Du aber in der Doku.

fchk

Simon schrieb:
> Auf dieser Seite hier gibt es leider kein PIC Einsteiger Howto,
> kennt jemand noch paar Resourcen,
> für die primitiven Funktionen,
> wie z.B. Einfache Port I/O, UART, SPI?

Beim C18 Compiler ist eine Peripheriebibliothek dabei. Musst nur mal in 
die Doku schauen.

fchk

Wird wohl. Ich entwickle nur unter Windows, weil ich noch das alte 
MPLAB8 und die alten Compiler verwende und aus Supportgründen auch 
verwenden muss, und die sind eben Windows-only.

Linux wäre auf diesem Entwicklungsrechner für mich nur zusätzlicher 
Aufwand, aber kein Mehrwert, zumal ich noch andere Windows-only Software 
benutze. Spezifische Fragen zu Microchip und Linux kann ich Dir also 
nicht beantworten, das wirst Du selber herausfinden müssen. Lade Dir das 
Zeugs einfach runter und installiere es und schau gefälligst selber, 
anstelle andere die Arbeit machen zu lassen.

fchk

Ich hätte zu diesem Topic nochmal eine Frage.

Frank beschreibt ein Demo board mit einem

Ich habe mir mal die PIC18 demo herunter geladen und compiled,
der PIC18F67J60 ist damit zu 99% voll, ist das normal?


Da würde ich lieber auf einen PIC32 wechseln, kann ich den noch mit dem 
PICKit3 Programmieren?