[Projekt] Perni's Langzeitprojekt "frozenControl"

Stand der Dinge...

ich bin mit meinen Layouts noch nicht zufrieden. Darum erstmal ein bisl was anderes. Ich möchte schon gerne, daß man die Module auch solo einsetzen kann, sprich ohne das Control-Modul. Es muß also ein USB-Port mit drauf.


Ein bisl Theorie...

zur Kommunikation der Module untereinander favorisiere ich einen 3-Pin-Lüfter-Stecker. Um es möglichst flexibel zu halten läuft das ganze über UART mit einem Paket basiertem Protokoll. Auf diese Weise braucht man keine Bus-BackPlane und kann (nahezu) beliebig viele Module anschließen. Außerdem gibt es auch keine Größenbeschränkung der Platinen (wobei es dafür Richtwerte geben sollte).
Das ganze ist also ähnlich dem System von AC.


Was denkt ihr darüber?
 

Anhänge

  • frozenBus.png
    frozenBus.png
    24,5 KB · Aufrufe: 80
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Aaaalso...

Zunächst einmal würde ich gerne wissen warum du die Module eigentlich solo einsetzen möchtest? Nicht das ich da jetzt grundsätzlich was dagegen habe, ich kann nur noch nicht ganz nachvollziehen welchen Vorteil das bringen soll. Wenn man natürlich auf jedes Modul ein oder mehrere Lüfterkanäle packt und dann noch ein paar Temperatureingänge, dann kann ich das ein wenig nachvollziehen. Trennt man die Sachen aber komplett, dh. ein Modul für die Lüfter, ein Modul für die Pumpe usw., dann bringt das für mich nur Mehraufwand auf einer Platine, den so gut wie niemand nutzen wird. IMHO

Damit komm ich gleich zum nächsten Punkt. Und zwar die Sache mit der Verbindung der Module. Die Sache mit der Backplane ist vllt nicht der Weisheit letzter Schluss, aber ich denke man hat hier zumind. den Vorteil, dass die Sachen nicht überall im Gehäuse rumkullern und man vermeidet zusätzliches Kabelgewirr, da man halt alles auf die Hauptplatine stecken kann.

Dann würde mich gerne interessieren warum du UART verwendest und kein I2C. Im I2C ist immerhin die Adressierung schon in Hardware vorhanden. Bei UART müsste man das ganze dann halt noch mit Software nachbauen. Ich persönlich würde hier ganz klar auf I2C setzen.

Außerdem würde ich noch eine Art Interupt-Leitung mit integrieren, damit man ggf unnötige Kommunikation vermeiden kann, dh Slave (Modul) zieht die Leitung auf High und der Master (Control-Modul) fragt dann halt die Daten ab.


Das soll jetzt nicht so klingen als ob ich hier alles schlecht reden möchte, aber wenn ich denke, dass man es anderst eventuell besser lösen könnte, dann muss ich einfach meinen Senf dazugeben ;)

MfG

Alex
 
zu i²C ... ist ganz schlecht für größere Datenmengen (z.B. Firwareupdate, Logdaten) ... außerdem haben nahezu alle Controller Probleme/Bugs im Slave-Betrieb (auch die AVR's), sprich auch hier muss man mit Software nachhelfen

zum Solo-Einsatz ... ich möchte es halt einfach universell gestalten ... der User kann ja dann selbst entscheiden wie er was, wo und in welcher Kombination montiert ... es soll Leute geben, die nicht alles in die Laufwerksschächte packen möchten und die Module dann iwo verstecken

zum IRQ ... im Grunde ne gute Idee ... allerdings sollte man überlegen, obs wirklich gebraucht wird, i.d.R. können alle Module die einen Status abgeben können mehrmals pro Sekunde abgefragt werden ... mir fällt halt nix ein, wo man innerhalb von Millisekunden reagieren müsste ... (btw. eine IRQ-Leitung ist i.d.R. Low-Aktiv)

Und keine sorge, solange es konstruktive Kritik ist, immer her damit ;)
 
Zuletzt bearbeitet:
zu i²C ... ist ganz schlecht für größere Datenmengen (z.B. Firwareupdate, Logdaten) ... außerdem haben nahezu alle Controller Probleme/Bugs im Slave-Betrieb (auch die AVR's), sprich auch hier muss man mit Software nachhelfen
Meinst du da jetzt Hardware-Bugs im I2C? Hast du da vllt was zum nachlesen parat? Würde mich persönlich wirklich interessieren, da ich da jetzt noch gar nicht sowas gelesen habe.

zum Solo-Einsatz ... ich möchte es halt einfach universell gestalten ... der User kann ja dann selbst entscheiden wie er was, wo und in welcher Kombination montiert ... es soll Leute geben, die nicht alles in die Laufwerksschächte packen möchten und die Module dann iwo verstecken
über die Anschlussmöglichkeit sollte man wirklich nochmal drüber nachdenken wie man Laufwerksschacht und Verstecken kombinieren kann. Aber ich bin weiter der Meinung, dass ein realer Solo, dh ein USB-Anschluss auf dem Modul zu viel des Guten ist. Ggf könnte man ja auch einen Mini-Master realisieren, der dann sogar in nen Usb-Stecker passt. Ich denke halt, dass man sich dann auch in der Controller-Auswahl künstlich beschränkt, da ja dann schon Hardware-USB vorhanden sein sollte..

zum IRQ ... im Grunde ne gute Idee ... allerdings sollte man überlegen, obs wirklich gebraucht wird, i.d.R. können alle Module die einen Status abgeben können mehrmals pro Sekunde abgefragt werden ... mir fällt halt nix ein, wo man innerhalb von Millisekunden reagieren müsste ... (btw. eine IRQ-Leitung ist i.d.R. Low-Aktiv)
ja das stimmt wohl. Ich weiß gar nicht mehr warum ich das integriert habe. Wahrscheinlich hatte ich eine automatische Adressvergabe über I2C im Gedächtnis. So wirklich notwendig ist es jetzt aber wirklich nicht, da hast du recht.

Und keine sorge, solange es konstruktive Kritik ist, immer her damit ;)
Wie du vllt schon gemerkt hast, liegt es mir schon ein wenig am Herzen ;). Allein sowas "großes" durchzuziehen ist dann doch schon recht schwer, von daher versuch ich was konstruktives beizutragen :p

MfG

Alex

Edit:
Irgendwie müsste man das hier ein wenig bekannter machen. Gerade bei den "grundlegenden" Design-Entscheidungen sollte man möglichst viele Meinungen einholen. Sonst haben wir nur unsere beiden Standpunkte. Ich halte das für recht wichtig, erst recht wenn das später mal Open-Source werden soll.
 
Zuletzt bearbeitet:
zu den TWI/I²C-Controllern und den Bugs/Problemen ...

AT91 ARM-Controller von Atmel:
- nur der SAM7S16 hat überhaupt einen SlaveMode
- ein paar kleine Bugs kannst hier nachlesen (AT91-TWI - Mikrocontroller.net)

AVR:
- genaueres ist mir nicht bekannt weil ich mit den AVR's nicht näher beschäfftigt habe, ich seh nur ständig in den Foren das es da massig Probleme gibt, gerade auch bei der Master/Slave Geschichte

----

Das Protokoll für die Serielle Kommunikation kann sehr einfach ausfallen, ein Beispiel dafür kann ich gern mal Skizzieren .. die Auswertung ob ein Paket für das Modul ist, ist auch sehr simpel .. das ganze sollte eig. recht wenig Ressourcen verbraten und läuft komplett in einer ISR
 
Okay bei den ARMs scheint es ja wirklich Probleme zu geben die Hardware bedingt sind. Aber bei den AVRs halte ich die Aussage für, sagen wir mal, sehr gewagt ;). Gibt App-Notes von Atmel, fertige Bibliotheken und nirgens steht etwas von Hardware-Fehlern. Also ich beschäftige mich schon ne weile mit AVRs (habe dehalb auch nicht die Erfahrung mit nem ARM) und mit I2C hatte ich noch überhaupt keine Probleme (gut solche Sache wie Pull-Ups vergessen zähle ich jetzt nicht dazu. Falls wirklich Bugs aufgetreten sein sollten, dann hätte Atmel das sicher irgendwo im Datenblatt vermerkt. Bei den Problemen in Foren handelt es sich ja meist um Implementierungsfehler.

MfG
 
hehe ... ich geb ja zu ... ich mag die AVR nicht wirklich ;) mag sein, das sich dadurch einige Forenberichte bei mir festgesetzt haben
 
Woher kommt denn diese Abneigung? Bist du eher der PIC-Freund? Klar so leistungsfähig wie ein ARM sind sie nicht, aber für solche Regelungssachen usw reichen sie oftmals dicke aus. Und unterschätzen sollte man sie auch nicht ;)

MfG

Edit:
Mir ist noch was zu der I2C-Sache eingefallen. Zum einen hätte das den Vorteil, dass man halt auch direkt ICs anklemmen könnte auf die man keine Software aufspielen kann und zum anderen bräuchte man für die angeschlossenen µC nicht mal unbedingt eine genaue Taktquelle, sondern könnte ggf auf den internen Oszillator zurückgreifen. Ist jetzt zwar nicht sooo wichtig, aber falls man mal alle Pins benötigt, ist es doch ganz hilfreich.
 
Zuletzt bearbeitet:
wg I²C ... wir können auf der Controller-Platine ja beides unterbringen, der kleine Connector schluckt ja kaum Platz ;)


Ich glaub ich bekomms hin, der große SAM7 mit USB, 5.24"-Power, 2x Bus, 4x Lüfter und evtl noch nen paar Temp-Eingänge ... das ganze ist so klein geworden, das 3 Stück davon hinter eine Laufwerksblende passen ... etwa so wie die Pumpen-Platine von AC

---------- Beitrag hinzugefügt um 01:16 ---------- Vorheriger Beitrag war Gestern um 22:29 ----------

PS: Abneigung ist übertrieben und das falsche Wort ... ich hab mich vor einigen Jahren durchaus mit den AVRs beschäftigt und fand sie auch garnich so übel, im Gegenteil, ich fand sie um einiges besser als diese ganzen PICs wo keiner durchblickt welcher Chip was kann und was nicht ... als ich dann allerdings die ARMs von Atmel gesehen hab und festgestellt habe das sie sogar recht gut erhältlich sind, bin ich dorthin gewechselt. Sie bieten zu einem minimal höherem Preis deutlich mehr Leistung und die etwas aufwändigere Beschaltung ist nicht so schlimm wie man erst glaubt
 
Die erste Layoutversion ist fertig (erstaunlich was man auf knapp 4cm x 4.5cm so unterbringen kann) ... und damit du siehst was ich meine, habe ich mal 3 Module nebeneinander gesetzt ... das ganze passt wunderbar hinter eine 5.25" Blende

Das Layout hat natürlich noch Potential für Verbesserungen ;)

Aus irgend einem Grund werden die Befestigungslöcher etwas seltsam gerendert...
 

Anhänge

  • modul_Fan.jpg
    modul_Fan.jpg
    88,6 KB · Aufrufe: 96
Zuletzt bearbeitet:
ich verstehe von dem meisten hier zwar nur Bahnhof aber ich verfolge es jeden tag mit, find ich extrem geil wenn mann sowas selbst machen kann, ich bin dafür nicht qualifiziert also kann ich außer wünsche was rein soll nicht viel beitragen. Aber ich kann es nachher Testen mit meine Wakü :fresse:
 
ich verstehe von dem meisten hier zwar nur Bahnhof aber ich verfolge es jeden tag mit, find ich extrem geil wenn mann sowas selbst machen kann, ich bin dafür nicht qualifiziert...
Sieht alles komplizierter aus als es in Wirklichkeit ist. Wenn man die Grundbegriffe erst verstanden hat ist der Rest recht einfach.

...also kann ich außer wünsche was rein soll nicht viel beitragen. Aber ich kann es nachher Testen mit meine Wakü :fresse:
Immer her damit, was sind deine Anforderungen an die optimale Super-Delux-Steuerung? Mögliche Kosten sind (erst mal) egal, wenns zu teuer/kompliziert ist, wirds halt (erst mal) nicht gemacht.
 
Hab ich dich jetzt richtig verstanden?
Jedes Modul hat den ARM, USB, Powerstecker, 4 Kanäle und eine weiter Busanbindung drauf, mit der man dann auf weitere Module (auch mit ARM) kommt? Eines dieser Module geht dann über USB an die Software und macht die anderen über $BUSSYSTEM verfügbar.

Wo kommt dann das Display hin?

Oder sind das wiederum 'nur' die Einzelmodule, die von einem Master, der dann auch das Display dran hat über $BUSSYSTEM angesteuert werden können. Das USB wäre dann für standalone Verbindung.
 
10W-15W pro Lüfterkanal
25W Pumpenkanal mit einstellbarer Startspannung
2 Pumpenkanäle
Temperaturgesteuerter Anschluss für eine (oder mehrere) RGB-LEDs von blau(kalter Wasser) bis rot(heißes Wasser) mit frei wählbarer Temperaturkennlinie
Anschluss für min. 5 Temperatursensoren
Flow Sensor
Alarm Buzzer mit PC not aus
Grafische Benutzeroberfläche mit Drag&Drop
Möglichkeit Profile anzulegen

das wäre vorerst alles
 
Hab ich dich jetzt richtig verstanden?
Jedes Modul hat den ARM, USB, Powerstecker, 4 Kanäle und eine weiter Busanbindung drauf, mit der man dann auf weitere Module (auch mit ARM) kommt? Eines dieser Module geht dann über USB an die Software und macht die anderen über $BUSSYSTEM verfügbar.

Wo kommt dann das Display hin?

Oder sind das wiederum 'nur' die Einzelmodule, die von einem Master, der dann auch das Display dran hat über $BUSSYSTEM angesteuert werden können. Das USB wäre dann für standalone Verbindung.

das letztere ...

ohne Master-Modul werden die einzelnen Module über USB angeschlossen und sie übernehmen die rudimentäre Steuerung oder eine PC-Software übernimmt die Steuerung

mit Master-Modul braucht nur das Master per USB angeschlossen werden, welches dann auch Anschluss für Displays usw. bietet und sich um Firmwareupdates (soweit vorhanden) kümmert ... das ganze funzelt dann autark und braucht keine Software auf dem PC
 
Die erste Layoutversion ist fertig (erstaunlich was man auf knapp 4cm x 4.5cm so unterbringen kann) ... und damit du siehst was ich meine, habe ich mal 3 Module nebeneinander gesetzt ... das ganze passt wunderbar hinter eine 5.25" Blende

Das Layout hat natürlich noch Potential für Verbesserungen ;)

Aus irgend einem Grund werden die Befestigungslöcher etwas seltsam gerendert...
Also vom Prinzip her finde ich die Anordnung auch nicht schlecht. Nur ich würde dich mal bitten das Gesamtkonzept noch einmal zu überdenken. Falls du wirklich nicht mehr auf einem Modul realisieren willst, dann ist hier ein ARM total überdimensioniert. Die 4 Lüfterkanäle schafft ein 8-Bit AVR locker. Klar kann man auch dafür nen ARM nehmen und die Zusatzbeschaltung mag auch noch aktzeptabel sein, aber kosten tut der ARM so da 4-5 fache und bringt IMHO keinerlei Mehrwert der das rechtfertigen würden. Wie auch Rage_ würde mich interessieren, wie du dir das mit dem Display gedacht hast. Denn nur das Display ist eine Komponente, die ein ARM rechtfertigen könnte. Aus dem Grund würde ich vorschlagen, dass man bei Interesse ja noch ein USB-Modul entwirft das möglichst kompakt gehalten wird. So könnte man auf den Modulen halt einfachere µC verwenden. Falls dann nämlich auch auf dem LED-Modul, Pumpen-Modul usw ein ARM sitzt, dann schnellen die Kosten auch mal ganz schnell in die Höhe. Ich kann mir ganz ehrlich gesagt nicht so recht vorstellen, dass jemand die Module einzeln benutzen mag. Bei dem Lüfter-Modul okay.. aber der Rest? Wenn das ganze schon als Controller für eine Wasserkühlung dienen soll, dann wird man auch immer mehrere Module im Verbund nutzen. Und dabei stellt dann der Solo-Betrieb doch einen Sonderfall dar. Und für diesen Sonderfall die Universiallösung zu entwerfen halte ich für fragwürdig.

10W-15W pro Lüfterkanal
25W Pumpenkanal mit einstellbarer Startspannung
2 Pumpenkanäle
Temperaturgesteuerter Anschluss für eine (oder mehrere) RGB-LEDs von blau(kalter Wasser) bis rot(heißes Wasser) mit frei wählbarer Temperaturkennlinie
Anschluss für min. 5 Temperatursensoren
Flow Sensor
Alarm Buzzer mit PC not aus
Grafische Benutzeroberfläche mit Drag&Drop
Möglichkeit Profile anzulegen

das wäre vorerst alles
Die Leistung bei den Lüfterkanälen halte ich zwar für grenzwertig aber mit dem bisherigen Konzept noch für realisierbar.

2 * 25W für eine Pumpe sind ohne Schaltregler nicht vernüftig realisierbar. Die Verlustleistung wird bei einem Linearregler einfach zu groß. Mehr als 2W bekommt man ohne großen Aufwand nicht so einfach gekühlt.

Der Rest sollte absolut kein Ding sein.

Edit:
Zu lange getippt um die Antwort noch zu lesen^^
 
so langsam wirds echt eng auf der kleinen Platine ... habe noch zwei Anschlüsse für Temperatursensoren hinzugefügt ... evtl kommen 1 oder 2 Status-LED's dazu und dann geht nix mehr ...

ich muss sagen, ich bin recht zufrieden mit dieser Modulgröße. Alles wichtige läßt sich unterbringen und wenns doch zu eng wird, kann man die 1,5x, 2x oder 3x (Fullsize) Größe nehmen ... ist also recht universell und dennoch gut zu Verstauen im Rechner
 

Anhänge

  • modul_Fan.jpg
    modul_Fan.jpg
    100,8 KB · Aufrufe: 97
Also vom Prinzip her finde ich die Anordnung auch nicht schlecht. Nur ich würde dich mal bitten das Gesamtkonzept noch einmal zu überdenken. Falls du wirklich nicht mehr auf einem Modul realisieren willst, dann ist hier ein ARM total überdimensioniert. Die 4 Lüfterkanäle schafft ein 8-Bit AVR locker. Klar kann man auch dafür nen ARM nehmen und die Zusatzbeschaltung mag auch noch aktzeptabel sein, aber kosten tut der ARM so da 4-5 fache und bringt IMHO keinerlei Mehrwert der das rechtfertigen würden.

Ich glaube ich muss nochmal klarstellen, daß dies hier KEINE Billigsteuerung werden soll, sondern es soll das technisch möglichste ausgereizt werden. Das Billigzeug gibs schon zu hauf. Ob der Controller nu 2€ oder 6€ kostet ist mir dann auch egal. Das macht sich erst wirklich bemerkbar, wenn man mehr als 10 Module einsetzen will und selbst dann fällt der Unterschied kaum auf, insbesondere wenn man sich die Gesamtsumme anschaut.

Ich reize erst mal aus was geht, abspecken kann ich später immer noch.

Und dabei stellt dann der Solo-Betrieb doch einen Sonderfall dar. Und für diesen Sonderfall die Universiallösung zu entwerfen halte ich für fragwürdig.

Und gerade darum ist es halt die Luxus-Steuerung.
 
so ... das Probieren hat ein Ende ... zumindest vorerst ;)

Ich glaube mehr bekomme ich auf dem kleinen Platinchen nicht mehr sinnvoll unter. Wenn ich noch mehr drauf quetsche, dann wird die Platzierung der Bauteile und das Löten zur Qual, vom Layout rede ich gar nicht erst.
Was habe ich alles untergebracht...

- ARM Mikrocontroller (AT91SAM7S64..512 je nach Flashgrösse)
- Spannungsregler (für die 3.3V)
- USB-Port (5-Pol Stiftleiste)
- 2x Anschluss für Temperatur-Sensoren
- 2x Anschluss für den Bus (Master- und Slave-Modus ist möglich)
- zwei parallel geschaltete Message-LEDs (Vorder-/Rückseite)
- Dreh-Kodierschalter (z.B. zur Adresseinstellung)
- 4x PWM/Linear Low-Drop Lüfterkanal mit Tachoauswertung
- Jumper zur Aktivierung des Bootloaders

Damit dürfte klar sein, daß die Modulgröße durchaus ausreichend ist. Und wenn es doch mal mehr sein soll, dann kann man ja ein vielfaches der Größe benutzen (1,5x/2x/3x).

Im Anhang ist die Platine (Vorder-/Rückseite) ... das Layout müsste (wenn überhaupt) nur noch im Detail überarbeitet werden.
 

Anhänge

  • modul_Fan_top_bottom.jpg
    modul_Fan_top_bottom.jpg
    172,1 KB · Aufrufe: 93
Zuletzt bearbeitet:
Kann bei der Elektrik zwar nicht alles nachvollziehen, möchte aber trotzdem etwas beitragen:
Im ersten Post steht was von 8 Kanälen für die Lüfter. Aber selbst ein Mora (der so viel kostet, wie die Regelung selbst ja scheinbar kosten soll) hat bereits 9 Lüfter. Oder ist es so geplant, dass man dann Y-Kabel nimmt? Wie soll die Umdrehung dann aber überwacht werden?
Nächstes Feature wäre: Abgesehen von einer Spannungsregulierung die Möglichkeit, eine feste Geschwindigkeit (+/- Genauigkeit) für Lüfter/ Pumpe vorgeben zu können
 
Zuletzt bearbeitet:
Kann bei der Elektrik zwar nicht alles nachvollziehen, möchte aber trotzdem etwas beitragen:
Im ersten Post steht was von 8 Kanälen für die Lüfter. Aber selbst ein Mora (...) hat bereits 9 Lüfter. Oder ist es so geplant, dass man dann Y-Kabel nimmt? Wie soll die Umdrehung dann aber überwacht werden?
Es gibt mehrere Möglichkeiten, mehrere Lüfter-Module oder die zweite wäre ein extra Vervielfacher-Modul das nur dafür da ist, die Tachosignale von mehreren Lüftern die an einem Kanal hängen zu ermitteln. Oder halt ganz ordinäre Y-Kabel bei denen dann allerdings nicht von allen Lüftern das Tachosignal ausgewertet wird.

Nächstes Feature wäre: Abgesehen von einer Spannungsregulierung eine Möglichkeit, eine feste Geschwindigkeit (+/- Genauigkeit) für Lüfter/ Pumpe angeben zu können
Kommt auf die Software-Liste ;)

...ein Mora (der so viel kostet, wie die Regelung selbst ja scheinbar kosten soll)...
Es gäbe durchaus die Möglichkeit einer "Low-Cost"-Version ... nur möchte ich nicht für mehrere Controller Programmieren ... es wäre schön wenn sich jemand darum kümmern würde ... @3ver: wie wärs wenn du je eine Version mit dem ATmega erstellst?

---
PS: ich werde das Startposting noch aktualisieren ;)
 
Startposting ist für das Lüfter-Modul aktualisiert

---

Bei den Lüfter-Kanälen habe ich für den Tacho-Eingang einen Serien-Widerstand eingeplant um den µC zu schützen für den Fall, daß der Lüfter verkehrt herum angeschlossen wird (max. 12V am Tacho Pin) oder der Lüfter einen internen PullUp gg. 12V hat (sicher ist sicher) ... nur wie groß sollte ich diesen Dimensionieren? Der µC verträgt max 5.5V allerdings steht im Datenblatt nix über den Innenwiederstand gg. Masse.

EDIT1: oder ich setz einfach ne Z-Diode gg 5V/3.3V ... mal drüber grübeln ;)

EDIT2: als nächstes versuch ich mal etwas für das Master-Modul zu entwerfen...
 
Zuletzt bearbeitet:
Es ist noch ein wenig zu früh, um sich Ideen für die Software zu überlegen oder?
Ideen sind immer gut ... manchmal braucht man zur Realisierung ja auch noch Hardware. Wobei die PC-Software halt als allerletztes dran kommt. Denkbar wäre allerdings, die Schnittelle über USB vorerst als virtuellen COM-Port zu implementieren damit man zumindest schon mit einem Terminal-Programm mit der Hardware kommunizieren kann.

---------- Beitrag hinzugefügt um 03:31 ---------- Vorheriger Beitrag war um 02:40 ----------

Überlegungen zum Ethernet-Interface...

ich denke aufgrund der Beschaffungsschwierigkeit entsprechender PHY-Chips für das integrierte Interface des AT91SAM7X werde ich wohl einen externen Chip (z.B. Microchip ENC28J60) benutzen der über SPI angesprochen wird. Dadurch kann man das Interface auch als Option separat realisieren. Ein weiterer Vorteil der separaten Option ist, daß man das Platinchen frei im Gehäuse platzieren kann, z.B. auf einer Slot-Blende und es können auch andere Chips benutzt werden.

Der ENC28J60 dürfte noch schnell genug sein für rund 100kb/s. Für die recht simplen Seiten des Web-Frontends sollte das noch genügen. Die 100MB Schnittstelle des integrierten vom SAM7X dürften dafür mehr als nur der absolute Overkill sein.

Als Datenspeicher (für z.B. Grafiken und größere Logs) kommen die DataFlash-Bausteine von Atmel in die engere Wahl (1 bis 32MBit), ebenfalls mit SPI.

Überlegungen für die Displays...

ich denke das wird das einfachste, einfach ein paar SPI-Buchsen und ein oder zwei für das gebräuchliche 8Bit-Interface ... die Firmwaretreiber könnten für unterschiedlichen Typen dann ebenfalls ins DataFlash wandern

Sonstige Ideen?

---------- Beitrag hinzugefügt um 03:53 ---------- Vorheriger Beitrag war um 02:40 ----------

Auf der anderen Seite währe der SAM7X schon interessant ... doppelt so viel SRAM, 2x SPI ... und iwie reizt mich die integrierte MAC-Lösung schon ... grübel
 
Zuletzt bearbeitet:
Überlegungen zum Ethernet-Interface...

ich denke aufgrund der Beschaffungsschwierigkeit entsprechender PHY-Chips für das integrierte Interface des AT91SAM7X werde ich wohl einen externen Chip (z.B. Microchip ENC28J60) benutzen der über SPI angesprochen wird. Dadurch kann man das Interface auch als Option separat realisieren. Ein weiterer Vorteil der separaten Option ist, daß man das Platinchen frei im Gehäuse platzieren kann, z.B. auf einer Slot-Blende und es können auch andere Chips benutzt werden.

Der ENC28J60 dürfte noch schnell genug sein für rund 100kb/s. Für die recht simplen Seiten des Web-Frontends sollte das noch genügen. Die 100MB Schnittstelle des integrierten vom SAM7X dürften dafür mehr als nur der absolute Overkill sein.
Schau dir mal den Wiznet W5300 an. Gibts bei Watterott. Ist halt ein wenig teurer als der ENC28J60, aber hat dafür auch schon TCP-Sockets implementiert.

Überlegungen für die Displays...

ich denke das wird das einfachste, einfach ein paar SPI-Buchsen und ein oder zwei für das gebräuchliche 8Bit-Interface ... die Firmwaretreiber könnten für unterschiedlichen Typen dann ebenfalls ins DataFlash wandern
hier würde ich einen Stecker bestehend aus 8-Bit, SPI, Spannung und ggf den übllichen Read-Write-, Chip-Select usw Leitung bereitstellen. Das sollte man dann alle Displays mit Controller iwie dranhängen können. Vllt kann man auch ein paar Leitungen für nen Touchscreen integrieren. Das ist dann aber schon recht kniffelig, da die Umsetzung da recht variiert.

MfG
 
Schau dir mal den Wiznet W5300 an. Gibts bei Watterott. Ist halt ein wenig teurer als der ENC28J60, aber hat dafür auch schon TCP-Sockets implementiert.
Auf den ersten Blick nicht übel das Ding ... hab das Datenblatt nur überflogen, wenn ich es aber richtig deute, brauchts mind. 15 Leitungen um mit dem Chip zu kommunizieren und da brauch ich dann wieder den SAM7X da mir sonst zu wenig Portpins über bleiben. Und dann ist der Preisvorteil wieder dahin. :( ... wg. dem TCP/IP Stack, da gibts schon (nahezu) fertige Libraries die ich nur noch geringfügig anpassen muss, ist also auch kein wirklicher Vorteil. :(

hier würde ich einen Stecker bestehend aus 8-Bit, SPI, Spannung und ggf den übllichen Read-Write-, Chip-Select usw Leitung bereitstellen. Das sollte man dann alle Displays mit Controller iwie dranhängen können. Vllt kann man auch ein paar Leitungen für nen Touchscreen integrieren. Das ist dann aber schon recht kniffelig, da die Umsetzung da recht variiert.
Muss ich mal drüber grübeln ;)
 
bevor ich mit dem Layout anfange, werde ich erst mal ausprobieren ob der ENC28J60 was taugt ... ich hab das kleine Modul von Olimex hier schon herumliegen (hatte ich zusammen mit dem SAM7-Modul gekauft damals) ... welcher µC es wird, entscheidet dann quasi die Geschwindigkeit des ENC

mit anderen Worten: erst mal ne etwas längere Pause hier bis ich Zeit zum coden gefunden habe...
 
PS: was fällt euch denn noch so ein was man in Verbindung mit dem Netzwerk alles machen kann? Hier mal was mir so spontan einfällt...

- Web-Frontend für die Steuerung (was insofern praktisch ist, da man auf dem Rechner keine weitere Software braucht)
- Benachrichtigung per Email/SMS über auftretende Störungen
- Abfrage von Email-Konten
- Autom. Firmwareupdate

---------- Beitrag hinzugefügt um 18:56 ---------- Vorheriger Beitrag war um 16:05 ----------

als weitere Variante gibts noch den ENC624J600 das 100MBit Gegenstück zum ENC28J60 ... der µC schafft auf dem SPI max. 50MBit ... vom Preis her sind die beiden etwa gleich ... aber erst mal sehen was meine Versuche so ergeben ...
 
Da mich die ARM-Geschichte ja prinzipiell schon interessiert, habe ich mich da mal ein wenig eingelesen. Die Atmel ARMs scheinen da ja nicht gerade die besten Umsetzungen zu sein. Du solltest vllt mal einen Blick auf die STM32-Reihe von ST werfen (Cortex-M3 Kern). Neben einer umfangreichen Peripherie-Bibo gibt es das Teil auch in allen möglichen Ausbaugrößen (Preise <5€ oder andere mit 72Mhz). Durch die Standard-Bibo ist wohl der Code sehr einfach zu portieren. Und ich habe noch nix gelesen bezüglich krassen Hardware-Erratas (wie beim Atmel-TWI :rolleyes:). Soweit ich weiß könntest du sogar deine Toolchain weitestgehend behalten.

Interessant sind auch die Stellaris von Luminary Micro/ Texas Instrument. Die gibts auch mit integrierter PHY fürs Ethernet.

MfG
 
Bisschen OT:
Welche ARM Toolchains gibts eigentlich zur freien Verwendung? Hersteller ist erstmal egal.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh