Hallo alle zusammen, Ich habe vor, ein bestehendes AVR Net IO Board, dass mit einem ENC28J60 bestückt ist, auf WiFi umzubauen. Ich habe bereits eine funktionierende Software mit TCP-Stack in meinem Mega644, der prima mit meinem ENC28J60 funktioniert. Ich suche deswegen nach einem MAC&PHY chip, damit ich meinen ENC28J60 durch diesen ersetzen kann. Ich will meine Software lediglich anpassen und meinen bestehenden Stack weiter verwenden. Es gibt ja mittlerweile zahlreiche WiFi-Schnittstellen, z.B. von Lantronix oder auch Microchip, die direkt via UART angesprochen werden und bereits einen TCP/IP Stack haben. So eine Lösung suche ich jedoch nicht. Ich will auch keine extra Hardware als Wifi-Ethernet-Bridge verwenden. Kennt jemand einen passenden Chip, durch den ich meinen ENC28J60 ersetzen kann? Gruss meinereiner
Hola allerseits, da möchte ich mich gerne anschliessen, denn ich bin selbst gerade am Googeln was die Leitung hergibt. Da meine HW-Architektur noch nicht steht, wäre eine Lösung, die für 802.11 (Wi-Fi) die unteren beiden Layer MAC und PHY als Chip realisiert, ähnlich wie der ENC28J60 das für 802.3 (Ethernet) macht. Wenn der auf dem Controller laufende TCP/IP Stack dann noch für beide Varianten zu gebrauchen wäre, wäre das natürlich das Sahnehäubchen. Dann müsste nur noch der Treiber umgeschaltet/ausgetauscht werden, und alles ist gut. Ich bin mal gespannt auf Eure Vorschläge bzw. Links. Ach ja: Der Controller wird kein Linux hosten können, sondern wird eher vom Schlag ATmega oder AVR32 bzw. äquivalent. Dankeschön schon mal im Voraus, und schönen Sommer noch. Ulrich
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en548014 Das Modul wird vom Microchip TCP/IP Stack unterstützt. Programmierdokumentation für Nicht-PICs gibt Microchip nicht heraus. fchk
Es gibt von Microchip die Module MRF24WB0MA und MRF24WB0MB (eines hat eine chipantenne, das andere zusätzlich noch einen connector für eine externe Antenne) Beide lassen sich von einem Pic mit dem Microchipstack ansprechen. Es gibt allerdings für Arduino das sogenannte "WiShield" welches auf diese Module setzt und dementsprechend gibt es unter folgender Adresse auch Sourcecode um die Module von einem AVR her per SPI anzusprechend. https://github.com/asynclabs/WiShield_user_contrib Ich spiele schon länger mit dem Gedanken mir endlich auch einmal eines dieser Module zu bestellen, leider gibt es wie immer einen Haken: Es schafft angeblich nur maximal 2Mb/s Durchsatz. Falls ihr noch weitere Module findet die sich als Hobbyanwender/Student bestellen lassen,ich wäre auch sehr interessiert an Modulen welche: a) NICHT per Uart sondern SPI bedient werden können b) >2Mbit/s transportieren können Nik
Nik Bamert schrieb: > dieser Module zu bestellen, leider gibt es wie immer einen Haken: Es > schafft angeblich nur maximal 2Mb/s Durchsatz. Mit uip oder dem Microchip-Stack gemessen? fchk
Die Messung stammt nicht von mir selber, sondern ist so auf dem Wikipedia des WiShield Herstellers angegeben. Es ist leider nicht ersichtlich ob die Hersteller sich damit auf den Raw Durchsatz oder auf den Durchsatz nach dem TCP/IP Stack beziehen. Ich nehme einfach mal RAW an, da ich auf dem AVR noch keinen Stack gehabt habe, der 250kByte/sek mit TCP geschafft hat (UDP jedoch schon) Nik
Hallo, ich habe mich mittlerweile auch noch ein bisschen damit beschaeftigt. Ich habe mich wie hier im Forum beschrieben auch fuer das Modul MRF24WB0MA entschieden. Ich denke dass es ganz gut in mein Projekt passt. Ich habe auch noch einmal mich ein bisschen bzgl. Board umgeschaut. Ulrich Radig hat ganz schoenes Modul, dass ich einfach erweitern kann: http://www.ulrichradig.de/home/index.php/avr/avr-webmodule Auch gibt es fuer die Plattformen schon allerhand Code, den man wiederverwenden kann bzw. auf den man den erwaehnten Treiber anpassen kann. Ich will nicht unbedingt auf einen AVR32 umschwaenken. Wer haette noch Interesse an einer solchen Kombination? Gruß meinereiner
> Wer haette noch Interesse an einer solchen Kombination? Hier, ich! Die Microchips hatte ich auch schon gefunden - das scheint mir ein gangbarer Weg zu sein. Auch wenn man nicht den Sourcecode des Stacks verwenden kann, studieren wird man hoffentlich dürfen. Das Command Set soll im Sourcecode dokumentiert sein, damit sollte es möglich sein, den Chip unter einen anderen Stack ("uIP"? oder den von Andreas Dannenberg oder...) zu schrauben. Dann habe ich noch den WL1271 von TI gefunden. Sehr interessant, macht Bluetooth UND WiFi, auch preislich: 24 CHF, etwa 20 EUR bei einem Distributor. Sie binden ihn allerdings an den die Sitara und Omap Plattform an (AM1802?) und propagieren embedded Linux als OS. Da drängt sich mir die bange Frage auf, ob der Atmel das noch gestemmt kriegt? Dann habe ich noch ein interessantes Webserver-Modul bei Olimex gefunden. Es heisst "EasyWeb3" und basiert auf dem MSP430, liegt bei 25 EUR. Die MSP430 ist für mich persönlich interessant, weil es Varianten mit Radio-Interface gibt, RF SoCs, CC430F5137 u. ä. Das ist für micht die Brücke zum drahtlosen Sensor/Aktor-Netzwerk auf der Basis 802.15.4/ZigBee oder 6loWPAN. An den will ich dann das WiFi Modul schrauben, und fertig ist die Bridge. So die Theorie. Wollen wie die beiden Varianten mal diskutieren? Schöne Grüsse, Ulrich
Hallo, Ulrich Sprick schrieb: > Wollen wie die beiden Varianten mal diskutieren? Klar, gerne. Mein Hintergrund bei der Geschichte ist, dass ich relativ viel Code zum Schalten von Ein- und Ausgaengen wiederverwenden moechte der bereits existiert. Rund um die 8biter von Atmel (Mega32, 64, 128) in Kombination mit den ENC gibt es schon einiges. Schau dir zum Beispiel mal die Alternative Firmware vom Radig-Board an oder auch http://www.ethersex.de. Ich habe bisher noch keine so umfangreiche Sammlung in anderen Bereichen gefunden. Gibt es sowas im PIC-Bereich oder auch im AVR32-Bereich? Ich lasse mich gerne eines Besseren belehren! Deswegen habe ich vor schon im Mega644-Bereich zu bleiben und auch das Radig-Board weiter zu verwenden. Schau doch mal bei http://www.ethersex.de ob es da nicht schon was gibt was du fuer deinen Teil verwenden kannst?! Fuer Anregungen, Hinweise oder neue Infos bin ich immer dankbar! ;-) Gruß meinereiner
Nobody Niemand schrieb: > Mein Hintergrund bei der Geschichte ist, dass ich relativ viel Code zum > Schalten von Ein- und Ausgaengen wiederverwenden moechte der bereits > existiert. Rund um die 8biter von Atmel (Mega32, 64, 128) in Kombination > mit den ENC gibt es schon einiges. Schau dir zum Beispiel mal die > Alternative Firmware vom Radig-Board an oder auch > http://www.ethersex.de. Ich habe bisher noch keine so umfangreiche > Sammlung in anderen Bereichen gefunden. > > Gibt es sowas im PIC-Bereich oder auch im AVR32-Bereich? Ich lasse mich > gerne eines Besseren belehren! Der Microchip-Stack enthält alles, was Du netzwerktechnisch brauchst, inkl DHCP, DNS, Web-Server TCP und UDP Sockets etc etc. Das ist alles schon fertig und kann so benutzt werden. Der Stack ist deutlich leistungsfähiger als das Zeugs von Adam Dunkel (uip, lwip). Auf einem PIC32 (Software) oder einem System mit dem größeren ENC424J600/624J600 (Hardware) hast Du auch SSL. > Deswegen habe ich vor schon im Mega644-Bereich zu bleiben und auch das > Radig-Board weiter zu verwenden. Ich halte das nicht für eine optimale Lösung. Wenn es klein und billig sein soll, ist der PIC18F67J60 die erste Wahl, da ist nämlich alles in einem Chip drin, und Du brauchst nur nach die Ethernetbuchse anzuschließen. Der Ethernet-Teil ist der gleiche wie beim ENC28J60, nur eben nicht per SPI angebunden, sondern direkt im Adressraum des Prozessors. Einfacher, kleiner und billiger gehts nicht mehr, und für einfache Fernschaltvorgänge reicht die Leistung problemlos aus. Ich habe hier Geräte auf Basis dieses Teils im 24*7 Betrieb am Laufen. Wenns schnell sein soll, dann wäre ein PIC32MX695F* das Mittel der Wahl. Über seinen internen Ethernet-MAC schafft der etwa 9 MByte/s Datendurchsatz per UDP, 2.5 MByte/s per TCP. Microchip gibt für das MRF24WB0M WiFi-Modul an einer 20 MHz SPI-Verbindung zu einem PIC32MX einen TCP-Durchsatz von etwa 100k/s an. Der Stack ist über die Prozessorfamilien (PIC18/PIC24/dsPIC/PIC32) derselbe. fchk
Servus Diese WiFi-Module warem mir schon bekannt, aber ich konnte mich noch nicht recht dazu durchringen. Aber der Carambola ist ja der Hit...! Danke für den Link!!! System on Chip SoC, ARM7 und Wi-Fi: http://www.gainspan.com/products/GS1011_SoC.php Gefällt mir bisher am besten. Riecht nach niedrigem Chip-Count. Marvell Avastar 88W8782U: SoC, Wi-Fi 802.11 b/g/n, USB http://www.marvell.com/wireless/assets/marvell_avastar_88W8782U.pdf Atheros und Broadcom haben auch was im Programm. Je länger man googelt, desto unübersichtlicher wird es. Abgesehen davon, dass die Grossen unsereinen Privatschrauber wohl ungern in die Datenblätter schauen lassen. Schöne Grüsse Ulrich
Frank K. schrieb: > Ich halte das nicht für eine optimale Lösung. Wenn es klein und billig > sein soll, ist der PIC18F67J60 die erste Wahl, da ist nämlich alles in > einem Chip drin, und Du brauchst nur nach die Ethernetbuchse > anzuschließen. Kennst du fuer diePIC32-Familie ausser dem offiziellen Starterkit noch andere Boards, die vielleicht in die Richtung des Radig-Boards gehen? Da ich kein besonders guter Hardware-Entwickler bin ist das fuer mich erstmal die groeßte Huerde. Ich suche was was relativ einfach zu verwenden ist. Zum Beispiel ein Board mit ein paar Relais zum klackern und ein paar Eingaenge fuer Sensoren. Wenn jemand eine Platine machen wuerde die zum Beispiel pinkompatibel zu der vom Radig ist und man das Traegerboardweiter verwenden kann waere das durchaus auch ein gangbarer Weg. Da ich in dem Bereich kaum Erfahrungen habe traue mir das jedoch (noch) nicht zu.
@ FrankK: Danke für die PIC Links. Diese Kleinen sind mir eigentlich auch sympathischer als die grossen ARM/MIPS/...-basierten SoCs, denn ich bezweifle, dass man (ich) diese komplexen Dinger ohne OS in den Griff bekommt. Mit einem Linux drauf könnte es machbar sein - sofern Treiber vorhanden sind oder angepasst werden können. Aber da bin ich (noch) nicht fit genug... Sicher wird es Bibliotheken für IAR oder Keil geben, aber da schreckt mich doch der Preis für den Einstieg... @ meinereiner: Vertrauen, Erfahrung und vorhandener Code ist absolut nicht zu verachten! Für eine Kombination des von MRF24WB0MA mit Ethernet-PICS spricht allerdings die gemeinsame Kompatibilität mit dem Software-Stack vom uChip - war auch gar nicht zu verachten ist. Schön für die Atmels ist, dass es einem Menge Code gibt. Allerdings sind Digital-IO, Character-LCDs, RFM-12 Interfacing usw. nicht so schwierig wie ein gut funktionierender TCP/IP-Stack. Oder? Korrigiert mich bitte, wenn ich falsch liege. Fazit: Ich bin noch unentschlossen. Es wird Zeit für einen tieferen Blick in die Datenblätter. Über die Erkenntnisse halte ich euch auf dem Laufenden. Schöne Grüsse Ulrich
Hoi meinereiner, > Da > ich kein besonders guter Hardware-Entwickler bin ist das fuer mich > erstmal die groeßte Huerde. Ich suche was was relativ einfach zu > verwenden ist. Da ist die Hürde aber wesentlich kleiner :-) da die Komplexizität deutlich geringer ist als bei Software. Wir machen eine Schaltung mit dem benötigten IO, dann wird daraus das PCB layoutet. Für halbe Europakarten kann man Target von IB Friedrich (gibt's das eigentlich noch?) verwenden - sehr studentenfreundlich für 0 Euro. Die Fertigungsdaten gehen dann zu einem PCB-Hersteller (Beta-Layout fällt mir so aus dem Stand ein), und für kleines Geld bekommt man ein paar Prototypen zum belöten. Alternativ kann man auch sein Controllerboard so layouten, dass sich andere Standard-IO-Boards (Shields, Capes,...) aufstecken lassen. Die Arduino-Gemeinde hat zum Beispiel Einiges auf die Beine gestellt. Das ist vielleicht noch sinnvoller, weil man dann auch mal mit exotischer Hardware und Sensorik "spielen" kann. Also, bei dieser Nebenbaustelle stehe ich gern mit Rat und Tat zur Seite. Schöne Grüsse, Ulrich
Angehängte Dateien:
-
DSC04935s.JPG
130 KB -
DSC04937s.JPG
130 KB -
DSC04942s.JPG
170 KB
Nobody Niemand schrieb: > Frank K. schrieb: >> Ich halte das nicht für eine optimale Lösung. Wenn es klein und billig >> sein soll, ist der PIC18F67J60 die erste Wahl, da ist nämlich alles in >> einem Chip drin, und Du brauchst nur nach die Ethernetbuchse >> anzuschließen. > > Kennst du fuer diePIC32-Familie ausser dem offiziellen Starterkit noch > andere Boards, die vielleicht in die Richtung des Radig-Boards gehen? Da > ich kein besonders guter Hardware-Entwickler bin ist das fuer mich > erstmal die groeßte Huerde. Ich suche was was relativ einfach zu > verwenden ist. www.olimex.com/dev/pic32-maxi-web.html Olimex hat noch weitere Boards. Für PIC32 habe ich jetzt nichts passendes in der Schublade. Für den PIC18F67J60 habe ich mal ein Bastelboard gemacht, das in einen normalen DIL64 passt. (siehe Bilder) fchk
Ich würde halt nur nicht ganz von vorne anfangen wollen. Die PIC32 haben mich schon in letzter Zeit öfters mal gelockt, jedoch habe ich mich nie aufgerafft mich darin einzuarbeiten. Wenn wir ein pinkompatibles Board erstellen würden mit einem PIC32 und einer Ethernet und Wifi-Schnittstelle (wahlweise bestückbar) fände ich den Ansatz auch nicht verkehrt. Noch ein Kommentar zu den Stacks: Bisher hat sich bei dem was ich gemacht habe der uIP-Stack eigentlich als stabil und ausreichend für meine Zwecke erwiesen, weswegen ich nicht unbedingt so das Problem darin sehe...
Angehängte Dateien:
-
ethernet-qil.jpg
270 KB
Nobody Niemand schrieb: > Noch ein Kommentar zu den Stacks: Bisher hat sich bei dem was ich > gemacht habe der uIP-Stack eigentlich als stabil und ausreichend für > meine Zwecke erwiesen, weswegen ich nicht unbedingt so das Problem darin > sehe... Oh. Ich hatte mal zwei Boards hier nebeneinander laufen: eines mit einem Cortex M3 (TI/Luminary Micro LM3S6911 mit 10/100 Ethernet, 72 MHz Takt, siehe Bild) und uip bzw lwip (beides ausprobiert) und mein Board aus dem vorherigen Posting mit einem PIC18F67J60 und 10 Mbit Ethernet und dem Microchip-Stack. Beide am selben Switch (HP Procurve 1800), selber PC als Client mit Firefox. Der kleine PIC war schneller. Echt! Der Webserver lies sich viel flüssiger bedienen. Der Unterschied war deutlich spürbar. So wanderte das LM3S6911-Modul in die Ablage. fchk
Hallo zusammen, vielleicht findet ihr ja auf http://avr-nio.de/ was ihr sucht. Ich bin ein reiner Hardware-Entwickler. Viele Grüße der_geltinger
Reinhard Hartwig schrieb: > http://avr-nio.de/ Sehr interessantes Projekt! Ich werde es mir mal die Tage genauer anschauen. Nichts desto trotz bin ich auch weiterhin an einer gemeinsamen PIC32-Loesung interessiert!
Pic32 wäre auch für mich interessant. Entwicklungsumgebung ist vorhanden.
Flensburger an Geltinger: Die Begleit-CD läßt sich nicht downloaden... Gruß Helmut
Nachtrag Ich würde euch die WiFi-Beispiele von Mikroe nahelegen. Die gehen zwar auch mit PIC32, aber für ein paar Port's reicht auch ein PIC18 oder auch AVR. Soviel Code ist auch nicht nötig, zumal der MRF24WB0MA mit diesem MCW1001 Chip aufgebaut ist. Gruß Helmut
Geltinger an Flensburger Der Link wurde gecancelt. Du scheinst sehr gut im Thema zu stecken. Meine Hardware basiert auf dem AVR, aber ein Modul mit Pic und ähnlichen Eigenschaften wie AVR-NIO wäre eine Alternative.
Angehängte Dateien:
-
Webserver_BeispielBild.png
330 KB
Ich bin ziemlich abhängig von dem Mikroe-Compiler in DER Beziehung.
Ich habe fast alle Sachen, die ich in meinen Projekten brauchen konnte,
aus Mikroe-Beispielen benutzt bzw erweitert.
ZB.
hier ein Auszug wie das Get Kommando mit der Stelle 6 und 7 ausgewertet
wird.
Das t steht für Toggle und die Nummer könnte eine Port-Nr eines µP sein,
oder die RelaisNr, die getoogelt werden soll.
Der Rest, der für die MAC-Adresse, für die IP4-, Port- und andere
Adresseneinstellung notwendige Kram steckt in bereitgestellten Lib's und
Beispielen.
Sie müssen nur noch zusammen gestrickt werden.
CODE-AUSZUG:
else if(getRequest[5] = "t") then ' if request path name
starts with t, toggle PORTA (LED) bit number that comes after
if(isdigit(getRequest[6])) then ' if 0 <= bit number <=
9, bits 8 & 9 does not exist but does not matter
bitMask = getRequest[6] - "0" ' convert ASCII to
integer
bitMask = 1 << bitMask ' create bit mask
LATA = PORTA xor bitMask ' toggle PORTA with xor
operator
end if
end if
end if
Der Bildausschnitt zeigt eine Webseite mit einem Grundriss.
Wenn man die Ringe mit der Maus berührt, gibt es ein Link und ein
Kontexmenue.
Der Link wird unten links angezeigt, er hat dann ein t für toogle und
die Nr.
Wenn man klickt schickt man die ADR dum Webserver und der Portpin
toogelt.
In meinem Fall ist das Bild auch auf einem Touch- TFT- Bedienfeld mit
2.8", ein touchen macht das Gleiche wie auf dem Webserver.
Gruß Helmut
Nobody Niemand schrieb: > Nichts desto trotz bin ich auch weiterhin an einer gemeinsamen > PIC32-Loesung interessiert! Also PIC32 mit MRF24WB0MA/B. Ich würden einen der PIC32MX6xx oder 7xx mit Ethernet Interface vorschlagen, dann kann man das WLAN Modul als Option einsetzen oder weglassen. Der TCP/IP-Stack passt ja für beide. Platz für die Webseiten sollte ein serielles EEPROM bereitstellen, das nimmt nicht so viel Platz weg wie ein SD-Kartenslot. Das Aufspielen der Seiten macht man ja eh "online", das das Gerät ja im Netz hängt. Dann brauche ich noch die SPI-Schnittstelle für ein Sub-GHz Funkmodul, damit ich an meine Steckdosen und Schalter herankomme. Interfacing zur Radig's Grundplatine mit Relais wäre zu erwägen. Hat jemand noch andere Wünsche? Schöne Grüsse, Ulrich
Ulrich Sprick schrieb: > Platz für die Webseiten sollte ein serielles EEPROM bereitstellen, das > nimmt nicht so viel Platz weg wie ein SD-Kartenslot. Das Aufspielen der > Seiten macht man ja eh "online", das das Gerät ja im Netz hängt. Du hast ein halbes Megabyte Flash im Controller zur Verfügung. Wie viel brauchst Du denn für Deine Webseiten? Wie groß soll denn Dein Code werden? fchk
Frank K. schrieb: > Du hast ein halbes Megabyte Flash im Controller zur Verfügung. Daswuerde mich ausreichen! Mit gezippten Seiten und wenig bis keine Bilderauf der Page kann man einiges in 512 KB packen! Meine Meinung: Lieber einen Prozessor der viel Speicher mitbringt wie noch was externes. Mir faellt noch eine fuer mich nicht unteressante Sache in Verbindung mit Ethernet ein: POE Ich wuerde es rein optional sehen aber wenigstens im Layout schon vorsehen. Es gaebe dafuer 2 optionen: 1. Alles auf eine Plattine packen und bestuecken was man will/braucht. 2. Man koennte ja, wenn man gerlingers Gedanken weiter spinnt das Netzwerkmodul austauschbar machen und 3 Netzwerkmodule vorsehen: a) Wifi b) Ethernet c) Ethernet & POE In jedem fall wuerde iches begruessen einen Stecker dann (zum Beispiel zum Radig-Traegerboard pinkompatibel) mit allen freien Ports aufzusetzen, so dass jeder seine eigenen Erweiterungen bauen kann. Auf jeden Fall sollten wir darauf achten, dass es auch kostentechnisch im Rahmen bleibt. Deswegen finde ich Option 1 besser, da man nicht noch zusaetliche Platinen braucht sondern erstmal eine hat mit der man loslegen kann und bestuecken kann was man braucht! Was denkt ihr darueber?
Hallo zusammen, vielleicht wäre ja ein Aufbau wie ich ihn beim AVR-NIO II realisiert habe als Grundlage interessant. Ist nur ein Vorschlag. Bei dieser Baugruppe sind LAN-Modul oder WLAN-Modul wahlweise steckbar. Ansteuerung über SPI. http://avr-nio.de/ Ich würde mich anbieten, Layout und Platinen zu erstellen. Da ich über entsprechende Händler/ -Herstellerkontakte verfüge, wäre auch eine entsprechende Bauteilbeschaffung kein Problem.
Falls Ihr das noch nicht kennt: www.openpicus.com Vielleicht ist das ja was. Bastele ich zurzeit mit rum. Wenn ich das beim Überfliegen des Threads richtig verstanden habe, macht es so ziemlich das was Ihr wollt. Gibts als LAN und WLAN Version.
Frank K. schrieb: > Du hast ein halbes Megabyte Flash im Controller zur Verfügung. Wie viel > brauchst Du denn für Deine Webseiten? Wie groß soll denn Dein Code > werden? Die Grösse hatte ich da nicht so im Sinn, sondern eher ein Update der Seiten vom LAN aus. Ich könnte mir vorstellen, dass das Flashen "over the air" während des "Normalbetriebs" nicht so einfach geht. Daher separates EEProm. Aber vielleicht sollte ich jetzt erst mal die Datenblätter eingehend studieren - bisher habe ich nur Featurelisten verglichen und quergelesen um eine Vorauswahl treffen zu können. Grüessli Ulli
Nobody Niemand schrieb: > Mir faellt noch eine fuer mich nicht unteressante Sache in Verbindung > mit Ethernet ein: POE > Ich wuerde es rein optional sehen aber wenigstens im Layout schon > vorsehen. Gute Idee! Das sollte problemlos machbar sein. In Jan Axelson's Buch "Ethernet Complete" habe ich gesehen, dass sie für die Stromversorgung 2 Übertrager mit Mittelanzapfung verwenden. Dadurch überträgt das eine Leiterpäärchen + und das andere -. Funktioniert im Prinzip wie die Phantomspeisung bei Kondensatormikrofonen. Ich nehme an, dass es dafür schon passende RJ-45-Buchsen mit Übertrager gibt. Der Bestückungsmehraufwand für PoE scheint sich somit sehr in Grenzen zu halten. > Es gaebe dafuer 2 optionen: > 1. Alles auf eine Plattine packen und bestuecken was man will/braucht. Dann wird es eine eierlegende Wollmilchsau, die aber gerade das nicht kann, was man speziell für sein spezielles Problem gerade braucht. Dann landet man preislich bei Boards wie Beagle, Hawk oder dem Raspberry. Das richtige Mass zwischen Featuritis und Minimalismus zu finden scheint mir das Problem zu sein... Ach, ich sehe gerade, darum geht's gar nicht: > 2. Man koennte ja, wenn man gerlingers Gedanken weiter spinnt das > Netzwerkmodul austauschbar machen und 3 Netzwerkmodule vorsehen: > a) Wifi > b) Ethernet > c) Ethernet & POE Also ich würde b) streichen, da c) kein grosser Mehraufwand ist. Eine Alternative "traditionelle" Stromzufuhr würde ich natürlich auch vorsehen. Nicht jeder hat ja in seinem heimischen Netz eine PoE-Stromquelle... WiFi würde ich als als Bestückungs-Option vorsehen, so dass man Ethernet und WiFi hat und eine Bridgefunktion realisieren kann. Das ist ab und zu ganz nützlich. Die nächste LAN Party kommt bestimmt. Kurz: Ich bin für Variante 1. > In jedem fall wuerde iches begruessen einen Stecker dann (zum Beispiel > zum Radig-Traegerboard pinkompatibel) mit allen freien Ports > aufzusetzen, so dass jeder seine eigenen Erweiterungen bauen kann. So meinte ich das. > Auf jeden Fall sollten wir darauf achten, dass es auch kostentechnisch > im Rahmen bleibt. Dagegen würde ich mich nicht sperren. > Deswegen finde ich Option 1 besser, da man nicht noch > zusaetliche Platinen braucht sondern erstmal eine hat mit der man > loslegen kann und bestuecken kann was man braucht! Genau. Wer das WiFi Modul braucht, kann's bestücken. Wer Ethernet nicht braucht, kann ja die wenigen Bauteile weglassen - muss aber nicht. Wer beides nicht braucht, tja... Zum PIC: Unter http://www.microchip.com/productselector/MCUProductSelector.html gibt's einen schönes Auswahlwerkzeug, mit dem man sich seinen PIC prima auswählen kann. Ich tendiere zunächst zu den PIC32-ern. Wer dann sein Design auf die kleinren PIC18 portieren und ein optimiertes Board-Layout machen will, kann das dann ja immer noch machen. Dann möchte ich noch gern anregen, einen möglichst universellen Footprint im Layout zu verwenden, mit dem man verschiedene PIC-Varianten bestücken kann. Damit ein möglichst grosser Teil der lötenden Bevölkerung glücklich werden kann. In diesem Sinne: Schöne Grüsse, Ulrich
Meine Basteleien sind mit den MikroElektronika Multimediaboards entstanden. guggst Du: http://www.tigal.de/category/150 Das Problem bei so einem Gemeinschaftsprojekt: jeder hat seine eigenen Vorstellungen. Es muß unbedingt ein Supertruppa Chef das sagen haben, der bestimmt wer was macht. Dazu braucht man eine Mehrheitsentscheidung für die Funktionen der Hardware, der Software. Nach meinen Erfahrungen zerfällt soetwas nach wenigen Anläufen, dann hat der Hardwareentwickler XYZ im Moment keine Zeit mehr. Ein anderer Hardwareentwickler könnte übernehmen, benutzt aber ein anderes Layoutprogram. Beim Software entwickeln gibt es gleiche Schwierigkeiten, Der Eine nimmt C, programmiert aber lieber gerne mit Microchip Prozessoren, der Nächste nimmt lieber Pascal-Compiler, die nicht jeder hat. Man sollte es zuerst einmal mit der Hardware beginnen lassen und da hat sich der Hartwig angeboten. Das ist schonmal ein guter Anfang. Der Vorschlag: wahlweise zu bestücken ist super. Soll es nur eine Mutterboard werden, soll es auch Handbedienfähig sein, soll es in eine Unterverteilung passen usw. muß festgelegt werden. Für mich, ich bin kein Maßstab, sollten die Relais extern sein, wegen der VDE- und Versicherungs- Zulassung. Finderrelais mit Socker haben das. Eine Handbedienung vor Ort würde ich mir wünschen, der WAF muß stimmen. Andere haben andere Vorschläge. Gruß Helmut
Hallo, ich versuche das ganze einmal zusammen zu fassen und auch einpaar Vorschlaegedamit zu unterbreiten, die vielleicht ein guter Kompromiss sind: Wir beginnen mit der Hardware: HARDWARE Verantwortliche Personen (bisher, Mitwirkende willkommen): Ullrich und Hardwig Wir wollen ein Motherboard auf Basis eines PIC32MX7XX entwickeln. Prinzipiell soll es so aufgebaut sein, dass man verschiedene "Modulbereiche" bestuecken kann auf die man wert legt. Das Motherboard soll jedoch nur grundfunktionen bereitstellen. Dabei soll auf folgende Punkte wert gelegt werden: Must have: Das Board soll ueber eine WiFi-Schnittstelle (MRF24WB0MA/B) wie auch eine Ethernetschnittstelle verfuegen. Serielle bzw. USB-Schnisttelle zur Konfiguration bzw. Debugausgaben. Optional: POE soll auf dem Motherboard vom Layout her vorgesehen sein jedoch optional bestueckbar sein. Das Layout sollte sich an dem des Webmodus vom Radig orientieren, um das Traegerboard weiter verwenden zu koennen. (Link: http://www.ulrichradig.de/home/index.php/avr/avr-webmodule) So hat man gleich eine Moeglichkeit die Ports direkt auszukoppeln und eventuell auch in einem gleichartigen Gehause weiter zu betreiben. Gleichzeitig kann man selbst eigene Extensionboards bauen, wenn man weitere Schnisttellen braucht. Der Verbindungsstecker kann zu beiden Seiten erweitert werden um auch alle anderen freien Ports/Schnittstellen nach aussen zu fuehren. Es sollten die vom Prozessor angebotenen Schnittstellen jederzeit auch mit anderen Extensionboards weiter verwendet werden koennen. Prinzipiell soll bei der Hardware auch auf den Kostenfaktor geachtet werden, dass man nicht in Dimensionen endet, wo sich bereits fertige Loesungen mit großen Prozessoren oder gar einem kompletten Linux-Kernel rechnet. Offene Punkte: - Zusaetzliches Flash/Speicherkartenslot notwendig? - Ethernet OR Wifi oder Ethernet XOR Wifi - Wer macht einen Vorschlag zur Schaltung? - Wie wird diese kommuniziert? - Soll (wenn ja wie) die Schaltung mit Layout veroeffentlicht werden? SOFTWARE: Verantwortliche Personen (bisher, Mitwirkende willkommen): Ullrich und meinereiner Mit der Software wird erst noch gewartet, bis eine Erste Version der Hardware zur Verfuegung steht. Bei der Software sollte darauf geachtet werden so viel wie moeglich auf Standard-Bibliotheken von Microchip zurueckzugreifen. Des Weiteren sollen alle neuen Funktionen modular gegliedert sein so dass jeder die entsprechende Funktionen verwenden oder ausschalten kann. Ziel sollte es erst einmal sein eine gemeinsame Grundlage mit Grundfunktionen zur Konfiguration, Einbindung von Modulen und zur HTTP Weboberflaeche zu schaffen. Einzelne Module koennten dann individuell weiterentwickelt werden und auf einer gemeinsamen Plattform zur Verfuegung gestellt bzw.ausgetauscht werden. Ich wuerde vorschlagen wenn es soweit ist auf GoogleCode ein Projektrepository einzurichten um dies fuer alle Dokumente, Beschreibungen und auchCode-Austausch zu verwenden. Ich kann mich gerneum die Details dabei kuemmern. Offene Punkte: - einheitliche Sprache und Entwicklungsumgebung definieren - gemeinsame Plattform festlegen - Lizenzrechtliche Themen Was haltet ihr davon? Es ist erstmal nur ein Vorschlag. ich will damit versuchen dem entgegenzuwirken, was Helmut beschrieben hat! Fuer die Anforderungen kann ich auch gerne ein gemeinsames Dokument bei GoogleDocs anlegen, dass wir gemeinsam bearbeiten koennen. Wenn ihr dafuer seit postet doch schnell eureMeinung und schickt mir per PN eine Adresse fuer das ich das ganze freischalten soll. ------------------------------------------ Meine Meinung zu verschiedenen Themen: - Zusaetzliches Flash/Speicherkartenslot notwendig? -> Speicherkarte optional, ist einfacher um Informationen auszutauschen, auch wenn man es fuer ein Logging verwenden will; bin jedoch offen fuer alle 3 Varianten :-) - Ethernet OR Wifi oder Ethernet XOR Wifi -> Um die Komplexitaet zu minimieren: XOR, wenn man eineBridge braucht kann man auch einen guenstigen Router nehmen, der bringt mehr Leistung fuer weniger Geld! - einheitliche Sprache: C Gruß meinereiner
Nächste Version: - etwas aufgeräumt - Spannungsversorgung - USB OTG - CAN (wer es braucht) Zu den sonstigen Anschlüssen: Ein SPI ist fürs WLAN reserviert, zwei sind noch frei. Wer einen USART braucht, muss einen SPI abgeben - die Pins liegen etwas doof, und bei den großen Gehäusen hat Microchip leider nicht die überaus praktischen Remappable Pins implementiert, wo man jede Funktion auf fast jeden Pins legen kann (siehe dsPIC33) Vielleicht kommt das ja noch.
Servus allerseits, ich sehe mit Erstaunen und Vorfreude, dass sich hier gerade eine Art Lawine entwickelt :-) Helmut schrieb: > Das Problem bei so einem Gemeinschaftsprojekt: jeder hat seine eigenen > Vorstellungen. > Es muß unbedingt ein Supertruppa Chef das sagen haben, der bestimmt wer > was macht. Auf Hoher See gibt's dafür den Käptn. Der sagt, wo's lang geht, und wenn einer aufmuckt, wird er kielgeholt. Das hat jahrhundertelang prima funktioniert ;-) > Dazu braucht man eine Mehrheitsentscheidung für die Funktionen der > Hardware, der Software. Das gab's auf Hoher See nicht. Wer von der Mannschaft den Offzieren einen Vorschlag machte, wurde schlicht aufgeknüpft - Problem erledigt. Auf diese Weise hat Admiral Nelson denn auch fast die gesamte Flotte vor Englands Klippen im Nebel verloren... Aber wir sind ja auch nicht auf hoher See :-) > Nach meinen Erfahrungen zerfällt soetwas nach wenigen Anläufen, dann hat > der Hardwareentwickler XYZ im Moment keine Zeit mehr. > Ein anderer Hardwareentwickler könnte übernehmen, benutzt aber ein > anderes Layoutprogram. Das sind auch meine Befürchtungen. Und ich fürchte, bei ECAD Projekten sind modulare Entwurfstechniken in der unteren Preiskategorie nicht sooo verbreitet. Es muss also immer einen Hardware-Käptn geben, der angemessene Zeit aufwenden kann, um Änderungen in das Projekt einzupflegen. > Beim Software entwickeln gibt es gleiche Schwierigkeiten, Der Eine nimmt > C, programmiert aber lieber gerne mit Microchip Prozessoren, der Nächste > nimmt lieber Pascal-Compiler, die nicht jeder hat. Also wenn's um Software geht, ist die Lage m. E. etwas entspannter: Man sollte Object-Libraries in beliebiger Sprache schreiben können, bei der die Schnittstellen der C calling convention des Systems folgen, oder wenigsten sie C-Libraries des Systems aufrufen können. Das ist unter Linux und Windows jedenfalls so. Ich kenne die aktuelle Microchip-IDE jetzt nicht (meine PIC-Erfahrung ist etwa 15 Jahre her), aber das könnte schon als normierender Faktor angesehen werden. Letztendlich: Der Käptn hat das letzte Wort, und gut is. > Man sollte es zuerst einmal mit der Hardware beginnen lassen Macht Sinn. Ist ja von der Software gut entkoppelt. > soll es auch Handbedienfähig sei ? Ich nehme an, es geht um Taster auf der Platine. > soll es in eine Unterverteilung passen usw. muß festgelegt werden. > Für mich, ich bin kein Maßstab, sollten die Relais extern sein, wegen > der VDE- und Versicherungs- Zulassung. Finderrelais mit Socker haben > das. Das sind wichtige und gute Kriterien. Das werde ich mal in einer Tabelle sammeln. > Eine Handbedienung vor Ort würde ich mir wünschen, der WAF muß stimmen. Was ist ein WAF? Ich nehme an, es hat nicht mit Warendorf zu zun? > Andere haben andere Vorschläge. So ist das. Aber wir sammeln erst mal, und nach angemessener Diskussionsperiode sagt dann der Käptn... ich glaub das hatten wir schon mal? Fortsetzung folgt. Ulrich
@Frank Das Layout gefällt mir gut. Der MClr hat bei mir sonst einen Kondensator, ist aber wurscht Da viel in SMD ist, kommt es auch nicht mehr darauf an, dass der LAN-Baustein so klitze ist. Man könnte auch diesen steckbaren fertigen Baustein nehmen, ist auch nicht soo teuer: http://www.mikroe.com/eng/products/view/582/ethernet-phy-board/ Aber soll kein besserwissen sein, Super Layout, sogar mit verpohlschutz und USBfault, super! Übrigens WAF bedeutet WomanAcceptanceFactor, nächste Steigerung FamilyAcceptanceFactor. Helmut
Nobody Niemand schrieb: > Das Board soll ueber eine WiFi-Schnittstelle (MRF24WB0MA/B) wie auch > eine Ethernetschnittstelle verfuegen. Das wär schon gut ;-) > Serielle bzw. USB-Schnisttelle zur Konfiguration bzw. Debugausgaben. Debugging hätte ich gerne komplett über das LAN, denn wenn ich jedesmal eine Strippe vom Keller bis unter's Dach ziehen muss, um zu debuggen, wär das doof. Initialkonfiguratin über serielle Schnitte oder USB ist ok, denn bevor das Ding in's lokale Netz kommt, muss es ein paar Sachen wissen. Z. B. die IP des Netzes (etwa 192.168.200.0), die dazugehörige Netzmaske, den Namen, und wie finde ich den DNS und das Gateway. Alternativ zu DNS könnte man auch die IP-Adresse direkt konfigurieren. Man muss dann nur seinen DNS so konfigurieren, dass er bestimmte Adressbereiche nicht selbst. dynamisch vergibt. In der Firma arbeite ich gerade mit gdbserver und gdb übers Netz unter Linux. Finde ich sehr angenehm. > bzw. Debugausgaben Debugausgaben sollte er über einen IP-Port machen. Wenn man ein Terminal darauf connected, kann man dann die Debug-Ausgaben sehen. Geht super. > Das Layout sollte sich an dem des Webmodus vom Radig orientieren, um das > Traegerboard weiter verwenden zu koennen. Ich hätte aber auch keine Angst vor einem Redesign unter Berücksichtigung der weiter oben genannten Faktoren (DIN, EN, TÜV, VDE, Versicherungsverband). Aber dieses Hutschienengehäuse ist schon Klasse. > Gleichzeitig > kann man selbst eigene Extensionboards bauen, wenn man weitere > Schnisttellen braucht. > Der Verbindungsstecker kann zu beiden Seiten > erweitert werden Vorsicht - irgendwann wird der erforderliche Kraftaufwand zum Stecken zu hoch! > um auch alle anderen freien Ports/Schnittstellen nach > aussen zu fuehren. Es sollten die vom Prozessor angebotenen > Schnittstellen jederzeit auch mit anderen Extensionboards weiter > verwendet werden koennen. Macht Sinn. Tut selbst im Herzen weh, wenn wunderbare Controllerfunktionen an einem nicht herausgeführten Portpin enden... Für Erweiterungsmodule möchte ich aber dringend auf eine andere Schnitte hinweisen: I2C. Der schärfte multimasterfähige kollisionsfreie bidirektionale Interfacebus der mir je untergekommen ist. 4 Leitungen, GND, VCC, Serial Data SDA und Serial Clock SCL, fertig. Für diesen Bus gibt es für kleines Geld haufenweise Chips: Parallel-IO, UARTS, RTCs,... Schlage vor, auf dieser Basis eine Palette von IO-Modulen ("Shields" oder "Capes" oder von mir aus auch "Onions" ;-), parallel zu entwickeln, die dann lediglich mechanisch kompatibel sein müssen. Das würde die Attraktivität in der Gemeinde ungemein steigern. Zum beispiel eine Platine für die Handbedienung von Harald(?) - Tasten und LEDs. Oder Sensorik-Boards. Oder eine Relaisplatinen. Temperatur. Luftfeuchte. Luftdruck. Bodenfeuchte für unsere Brüder mit dem Grünen Daumen. PH, Nitrit, Leitfähigkeit für unsere Aquarianer. Ich muss mich jetzt bremsen. > Offene Punkte: > - Zusaetzliches Flash/Speicherkartenslot notwendig? Für mich ist das Blödsinn, denn der Speicher ist ja komfortabel über's Netz erreichbar. Andererseits wirkt ein SD-Slot auf manche Zeitgenossen überaus attraktiv. Und sei es auch nur, um herumliegende ausgediente Speicherkarte wieder einer sinnvollen Verwendung zuzuführen. Also ich sach jetz mal nicht nein. > - Ethernet OR Wifi oder Ethernet XOR Wifi OR bitte. XOR würde bedeuten: Steckverbinder, zusätzliche Karte. Bei Platzproblemen müssten wir dann vielleicht doch noch mal diskutieren. > - Soll (wenn ja wie) die Schaltung mit Layout veroeffentlicht werden? Macht Sinn für Nachbauer, erhöht die Attraktivität des Projektes für Mitstreiter und die Bastelgemeinde. Kommerzielle Ausbeuter könnte man ja durch geeignete Lizenzbedingungen (GPL, LGPL) etwas bremsen. > Des Weiteren > sollen alle neuen Funktionen modular gegliedert sein so dass jeder die > entsprechende Funktionen verwenden oder ausschalten kann. Also ein Build-Konfigurations-System a la "make menuconfig" wie bei Linux-Projekte üblich oder beim Ethersex Projekt oder beim Freetz? Gute Idee. Könnte aber Probleme bei Verwendung der Microchip IDE geben. Ich muss mir das mal anschauen. > Ziel sollte es erst einmal sein eine gemeinsame Grundlage mit > Grundfunktionen zur Konfiguration, Einbindung von Modulen und zur HTTP > Weboberflaeche zu schaffen. Einzelne Module koennten dann individuell > weiterentwickelt werden und auf einer gemeinsamen Plattform zur > Verfuegung gestellt bzw.ausgetauscht werden. Also erst den Kern, und dann die Zwiebelschalen. > Ich wuerde vorschlagen wenn es soweit ist auf GoogleCode ein > Projektrepository einzurichten um dies fuer alle Dokumente, > Beschreibungen und auchCode-Austausch zu verwenden. Ich kann mich Ich kenne nur Sourceforge und GitHub. Bei Google auf jeden Fall die Lizenzbedingungen genau studieren, nicht das wir da hinterher Konferenzen mit Herren in dunklen Anzügen und Sonnenbrille abhalten müssen ;-) Ganz wichtig: Alle Dokumente müssen versioniert sein, auch Schaltplan, Layout und CAM Files. Und ein bestimmter Stand (Release) muss jederzeit wieder ausgecheckt werden können, um Bugfixing oder Untersuchungen an Vorversionen machen zu können. > Offene Punkte: > - einheitliche Sprache und Entwicklungsumgebung definieren 1. Englisch wegen globaler Attraktivität 2. Deutsch wegen weil bisher nur deutschsprachige Teilnehmer dabei sind? Ich mach auch gern den Übersetzer. In der Firma scheiben wir eh alles auf englisch, daher ist das kein Problem. Zweisprachig wär vielleicht gut. > - gemeinsame Plattform festlegen IDE/Software: a) Microchip IDE b) GNU Toolchain (sofern verfügbar für PICs) Bei der Microchip-IDE ist vermutlich der Einstieg und das Programmieren leicht. Anbindung an ein Versionsverwaltungs- und Konfigurationssystem? Keine Ahnung... GNU Toolchain ist eher etwas für den professionellen harten Kern. Also für Leute wie wir ;-) Aber mit Anleitung ist auch das zu meistern. In der Firma arbeite ich damit. Es fluppt. > - Lizenzrechtliche Themen Offen halten im Sinne von Freiheit und kommerzielle Verwertung an dieses Prinzip binden, so dass das Projekt sich möglichst weit selbst weiterentwickelt. > Was haltet ihr davon? Es ist erstmal nur ein Vorschlag. ich will damit > versuchen dem entgegenzuwirken, was Helmut beschrieben hat! Mein Daumen ist oben. > Fuer die Anforderungen kann ich auch gerne ein gemeinsames Dokument bei > GoogleDocs anlegen, dass wir gemeinsam bearbeiten koennen. Wenn ihr Besser eine Tabelle. Am besten wäre ein Requirements Management System. Ich persönlich stelle immer wieder fest, dass das eine gute Idee gewesen wäre, hätte man es von Anfang an benutzt. Da gibt es freie Tools. Ist aber nur eine Anregung. Dann brauchen wir noch: - Ein Forum für Diskussionen (hier?) - Ein Dokumentationssystem (ein Wiki?) mit Anleitungen für Installation, Build, Programmierung der Chips, Beschreibung der Hardwarekomponenten, Bezugsquellen,...) - Ein Konfigurationssystem (make menuconfig o. ä.) das auch die Doku mit installiert. (ich lese nicht gerne Quelltexte um herauszufinden was ein Package überhaupt macht) - Ein Ticketsystem (Bug Tracking und Management) > - Zusaetzliches Flash/Speicherkartenslot notwendig? -> Speicherkarte siehe oben > - Ethernet OR Wifi oder Ethernet XOR Wifi -> Um die Komplexitaet zu > minimieren: XOR, Ich denke, die Komplexizität ist geringer bei OR. > - einheitliche Sprache: C Daumen hoch. Muss aber nicht zwingend sein. Ich kann auch ganz gut nach C portieren, das ist oft einfacher als sich mit fremden Compilern rumschlagen. Ausserdem lernt man beim Portieren die fremde SW ganz gut kennen. Dann noch: Welches Layoutsystem? Eagle ist ja schon auf dem Vormarsch :-) die freie Version kann ja 100x180 mm doppelseitig. Die kommerzielle Variante ist dann mit 800 Öcken schon heftiger... kikad hab ich öfter schon gelesen, kenne es aber nicht. Target hatte ich mal vor Jahren probiert. Ist wohl der direkte Gegenspieler zum Eagle. Ich enthalte mich. So muss einkaufen bevor der Laden wieder dicht macht. Bis denn, Ulrich
Ulrich Sprick schrieb: > Debugging hätte ich gerne komplett über das LAN, denn wenn ich jedesmal > eine Strippe vom Keller bis unter's Dach ziehen muss, um zu debuggen, > wär das doof. Debugging übers LAN - da wüßte ich nicht, wie ich das hinbekomme. Microchip unterstützt das nicht. > Initialkonfiguratin über serielle Schnitte oder USB ist ok, denn bevor > das Ding in's lokale Netz kommt, muss es ein paar Sachen wissen. Z. B. > die IP des Netzes (etwa 192.168.200.0), die dazugehörige Netzmaske, den > Namen, und wie finde ich den DNS und das Gateway. Alternativ zu DNS > könnte man auch die IP-Adresse direkt konfigurieren. Man muss dann nur > seinen DNS so konfigurieren, dass er bestimmte Adressbereiche nicht > selbst. dynamisch vergibt. DHCP oder Zeroconf ist Standard und ist auch im Microchip-Stack drin. > In der Firma arbeite ich gerade mit gdbserver und gdb übers Netz unter > Linux. Finde ich sehr angenehm. Gibts hier nicht. > Also ich sach jetz mal nicht nein. > >> - Ethernet OR Wifi oder Ethernet XOR Wifi > > OR bitte. XOR würde bedeuten: Steckverbinder, zusätzliche Karte. Bei > Platzproblemen müssten wir dann vielleicht doch noch mal diskutieren. Der PHY vom Ethernet muss zwingend mit aufs Board, weil das RMII ist und da 50 MHz drüberlaufen. Das will man nicht über Steckverbinder leiten, wenn es nicht notwendig ist. Der PHY muss daher auch in die unmittelbare Nähe des PIC32. > Also ein Build-Konfigurations-System a la "make menuconfig" wie bei > Linux-Projekte üblich oder beim Ethersex Projekt oder beim Freetz? Gute > Idee. Gibts hier so nicht. >> Ziel sollte es erst einmal sein eine gemeinsame Grundlage mit >> Grundfunktionen zur Konfiguration, Einbindung von Modulen und zur HTTP >> Weboberflaeche zu schaffen. Einzelne Module koennten dann individuell >> weiterentwickelt werden und auf einer gemeinsamen Plattform zur >> Verfuegung gestellt bzw.ausgetauscht werden. Vieles stellt Microchip schon bereit. > b) GNU Toolchain (sofern verfügbar für PICs) Gibts nicht, Du wirst das Microchip-Zeugs verwenden (was im Kern ein angepasster GCC ist). Rein theoretisch könntest Du eine normale MIPS-Toolchain verwenden, aber das ist auf PIC32 ineffizient. Der C32 erzeugt angepassten MIPS16-Code (im Prinzip so was wie Thumb bei ARM), was eine Standard MIPS Toolchain nicht macht, und deswegen sollte man den C32 bzw später den XC32 auch nehmen. Die Plattform der Wahl ist zur Zeit das alte MPLAB 8 und der C32 Compiler 1.12 und ein ICD3. Beim C32 2.x und dem XC32 gibts momentan noch kleinere Problemchen. Die alten Sachen sind gut abgehangen und funktionieren. In einem halben Jahr sieht die Sache vielleicht anders aus. >> - Ethernet OR Wifi oder Ethernet XOR Wifi -> Um die Komplexitaet zu >> minimieren: XOR, > > Ich denke, die Komplexizität ist geringer bei OR. siehe oben, die Physik legt ein OR nahe. >> - einheitliche Sprache: C > Siehe oben. Will man die Microchip Applikationsbibliotheken verwenden (was zu empfehlen sind, da hier die ganzen Errate berücksichtigt sind), ist die Microchip Umgebung Pflicht. -> C32 1.12 (die letzte 1'er) fchk
Helmut schrieb: > @Frank > Das Layout gefällt mir gut. Das ist nur der Schaltplan. > Der MClr hat bei mir sonst einen Kondensator, ist aber wurscht Ganz wurscht ist der nicht. Wenn der zu groß ist, kann der ICD3/PICKIT3 den Chip nicht mehr in den Debugmodus setzen. fchk
Nun ja, Elko's verwende ich auch nicht. Zitat: Der PHY vom Ethernet muss zwingend mit aufs Board, weil das RMII ist und da 50 MHz drüberlaufen. Das will man nicht über Steckverbinder leiten, wenn es nicht notwendig ist. Der PHY muss daher auch in die unmittelbare Nähe des PIC32. Die PHY vom Ethernet ist in der Nähe von der Buchse, auch auf dem Board. Und letzendlich hat's eine LAN-Steckbuchse ---- was ist mit den Kontakten und wie schnell über SPI gearbeiter wird, bestimmt der Programmierer. Zumal es hieß: Es soll eine Wahlmöglichkeit geben. Der Treadstarter begann mit diesem Wunsch.
Helmut schrieb: > Und letzendlich hat's eine LAN-Steckbuchse ---- was ist mit den > Kontakten und wie schnell über SPI gearbeiter wird, bestimmt der > Programmierer. > > Zumal es hieß: Es soll eine Wahlmöglichkeit geben. Der Treadstarter > begann mit diesem Wunsch. Mit diesem Design unter Verwendung eines PIC32MX795F512 geht das nicht. Der Ethernet-Controller (MAC, der Digitalteil der Ethernetschnittstelle) ist bereits im PIC fest eingebaut. Da ist also nix mit SPI, und das ist auch gut so, weil viel viel schneller. Allein dieser Punkt spricht gegen eine Modularität. Als externe Beschaltung wurd noch ein PHY benötigt, der den Analogteil enthält. MAC und PHY kommunizieren über ein standardisiertes Interface namens MII oder RMII (Reduced Media Independent Interface, also weniger Leitungen, aber doppelter Takt). Und der Takt auf einem RMII beträgt nun mal 50 MHz, fix und permanent, und unabhängig davon, ob gesendet wird oder nicht. Und das wiederum erfordert gewisse Maßnahmen bei der Bauteileplazierung und beim Layout, damit es nachher auch sauber funktioniert und ggf später auch mal ein CE-Zeichen tragen darf. Wunsch hin oder her, letztendlich hat die Physik das Sagen. fchk
PS: zu dem PHY-Board von microe Ja, das kann man so machen, aber der Pfostenstecker ist aus HF-Sicht sehr ungünstig. Dieses Board ist nur zum Basteln gedacht. Ob Du damit jemals einen EMV-Test bestehen wirst, bezweifle ich. Ich würde zumindest vom 2.54mm Raster aufs 1.27mm Raster gehen und eine zweite Pinreihe nur mit Ground-Pins hinzufügen. fchk
Naja, die Frage könnte ich mir selbst beantworten: Ist das Pollinboard EMV fest? Ich denke ja nur an die Wahlmöglichkeit, LAN/WLAN Meine Bedenken wegen der Relais, versicherungstechnisch, ist mir persöhnlich, höher angesiedelt. Notfalls helfen Optokoppler und Blechgehäuse. Nicht falsch verstehen, der Fachmann wie Du, der achtet drauf. Ist die Frage wofür es gedacht ist.
Hoi allerseits, > Der PHY vom Ethernet muss zwingend mit aufs Board, > weil das RMII ist und da 50 MHz drüberlaufen. Das > will man nicht über Steckverbinder leiten, wenn es > nicht notwendig ist. Der PHY muss daher auch in die > unmittelbare Nähe des PIC32. Also bei HF hört der Spass ja schnell auf. Da will man keine Leiterbahnen mit scharfem Knick, und auch gar keine langen Leitungen, und wenn möglich auch Ground Planes rundherum. HF soll ja auch möglichst nicht in den Analogbereich einstreuen, sonst sind die schönen 10 ADC Bit schnell Makulatur... > Ich denke ja nur an die Wahlmöglichkeit, LAN/WLAN Da Ethernet und WLAN Interfaces sowie unterschiedliche Pins verwenden, stellt sich die Frage nach Wahlmöglichkeit auch gar nicht so richtig. Meinereiner war dann ja auch von der Möglichkeit der optionalen Bestückung {WLAN|Ethernet|beides} recht angetan. Also mein Ok hat Frank. > Meine Bedenken wegen der Relais, versicherungstechnisch, > ist mir persöhnlich, höher angesiedelt. Das Problem "Relais" möchte ich eigentlich auslagern auf ein Carrier- oder IO-Board, wie die Grundplatine von Ulrich Radig etwa. Meinereiner wohl auch, wenn ich ihn richtig verstanden habe. Braucht Platz, treibt dadurch die Kosten in die Höhe, und schränkt die vielseitige Verwendbarkeit ein. Durch ein externes Board hat man dann auch mehr Freiheit bei der Wahl der Relais (dicke Lastrelais mit Silberkontakten oder schnuckelige Reedrelais für höhere Schaltfrequenzen etwa). Schöne Grüsse, Ulrich
Hoi nochmal Wo wir gerade bei HF waren: Ich möchte gern RC-Netzwerke an den/einigen ADC Eingängen anregen. Die Anti-Aliasing Filter, braucht man immer wieder. R-Arrays in SODIP sind mir ja noch (ca. 1997) bekannt. Gibt's da auch C-Arrays? Das wäre schön zu bestücken. Analog-Ground: Haben wir dafür eigentlich ein separates Netz? Wenn über das Ground im Analogteil Ströme aus dem Digitalteil (HF) fliessen würden, haben wir so butz ekelige Störsignale auf dem ADC... Bei getrennten Netzen kann man diese dann an geeigneter Stelle, etwa am Ausgang der Stromversorgung zusammenführen. Schöne Grüsse allerseits, Ulrich
Servus, @ Frank: Würdest du netterweise die Schematics in ein PDF giessen? Ich habe mein altes Protel wiedergefunden und installiert - scheint zu funktionieren unter WXP. Dann kann ich auch sehen, was schaltungstechnisch gerade so abgeht. Dankeschön, und schöne Grüsse Ulli
Ulrich Sprick schrieb: > Servus, > > @ Frank: Würdest du netterweise die Schematics in ein PDF giessen? Ich > habe mein altes Protel wiedergefunden und installiert - scheint zu > funktionieren unter WXP. Da isses. Ich hätte noch etwas anzubieten: als PHY den SMSC9303 anstelle des 8720. Der 9303 ist ein 3-Port-Switch, bei dem der dritte Port als PHY betrieben werden kann. Damit kann man dann beispielsweise eine Ethernet-Verbindung durchschleifen. Oder filtern: Der Switch ist managebar über MDC/MDIO und über I2C (das I2C-EEPROM enthält die Defaultsettings, kann aber nach der Initialisierung voll vom Controller mitbenutzt werden), und man kann Header zuschalten, an denen man erkennt, von welchem Port ein Paket angekommen ist bzw auf welchem Port ein Paket rausgehen soll. Damit hat man dann zwei virtuelle Ports. Das wird z.B. bei den meisten SOHO-Routern auch so gemacht. In diesem Plan ist der Switch-PHY per MII angebunden. Ich müsste mal schauen, ob der auch RMII kann. Das einfach mal so als Vorschlag, was mit wenig mehr Aufwand auch noch alles geht. Mir schwebt übrigens ein SO-DIMM Modul für dem PIC32 und dem PHY und dem ganzen essentiellen Beipack, aber ohne Buchsen und ohne weitere Peripherie wie SPI-Devices vor. Es könnte nämlich Sinn machen, das Modul in vier Lagen zu fertigen, und weil vier Lagen teuer sind, will man das Modul daher so klein wie möglich halten. Dann werden natürlich die ganzen 100n-Kondensatoren in 0402 gewählt und der PIC im 12x12mm TQFP100 PT Package mit 0.4mm Pitch, und deswegen will ich das EEPROM auch im SOT23-5 haben. SO-DIMM deswegen, weil der Sockel gleich für die mechanische Befestigung sorgt und die Pins alle auf einer Seite liegen, was Groundloops verhindert, und weil die SO-DIMM-Sockel problemlos erhältlich sind. Alternativ Mini-PCI/Mini-PCIe o.ä. fchk
Frank K. schrieb: > Da isses. Besten Dank! > Ich hätte noch etwas anzubieten: als PHY den SMSC9303 anstelle des 8720. > Der 9303 ist ein 3-Port-Switch, bei dem der dritte Port als PHY... Junge junge jetzt geht's aber ab hier :-) > betrieben werden kann. Damit kann man dann beispielsweise eine > Ethernet-Verbindung durchschleifen. Oder filtern: Der Switch ist Dann könnte das Kerlchen ja langfristig meine Fritzbox ersetzen ;-) > managebar über MDC/MDIO und über I2C (das I2C-EEPROM enthält die > Defaultsettings, kann aber nach der Initialisierung voll vom Controller Verstehe ich das richtig so, dass der Switch und das EEProm am gleichen I2C-Bus hängen, und sich der Switch die Init-Config direkt aus dem EEProm saugt, ohne dass die MCU da eingreifen muss? Boah! > mitbenutzt werden), und man kann Header zuschalten, an denen man > erkennt, von welchem Port ein Paket angekommen ist bzw auf welchem Port > ein Paket rausgehen soll. Damit hat man dann zwei virtuelle Ports. Das > wird z.B. bei den meisten SOHO-Routern auch so gemacht. Nicht schlecht, wenn man ein kabelgestützes Netzwerk aufbauen will. Allerdings bin ich nicht so sicher, ob das zur noch nicht definierten Zielgruppe passt. Schön wäre es ja, wenn sich das Projekt in der Art des Raspberry PI lawinenartig zum Selbstläufer entwickeln würden. Dann könnte man sich mal wieder einen Satz Ersatzlötspizten gönnen ;-) Platzbedarf steigt natürlich etwas. Was meinen die anderen? Wo wir gerade beim Thema sind: Ich habe eine RJ45 mit PoE von Midcom gefunden, MIC66011-5171. Daran kann man sehr gut sehen, wie das PoE funktioniert. Ueber eine Suchmaschine findet man das Datenblatt. Schlage vor, die Ausgänge hinter dem Gleichrichter mit der Stromversorgung zu verbinden. Dann kann man das Kerlchen wahlweise über ein Steckernetzteil oder über's LAN-Kabel füttern. Leider habe ich noch keine USB/RJ45 mit PoE Kombi gefunden. > Mir schwebt übrigens ein SO-DIMM Modul für dem PIC32 und dem PHY und dem > ganzen essentiellen Beipack, aber ohne Buchsen und ohne weitere > Peripherie wie SPI-Devices vor. Es könnte nämlich Sinn machen, das Modul Das hatte ich auch mal vor. Dann könnte man das Modul als Standardelement für's Prototyping nehmen. Da gibt's auch schon was Fertiges. Gumstix zum Beispiel, auch kleine SODIMM Boards, aber alles nicht so ganz billig. So ab 60 Euro etwa. Und dazu kommt ja dann noch die ganze IO-Mechanik. Ich würde mal sagen, wenn das Projekt so richtig erfolgreich sein will, sollten wir die 20 USD/EUR Grenze im Auge behalten. Bei dem Preis greift man schon mal zu. Das tut auch nicht weh, auch wenn das Ganze dann später auf dem Schreibtisch verstaubt. > in vier Lagen zu fertigen, und weil vier Lagen teuer sind, will man das 4 Lagen sind mir äusserst sympathisch - auch oder gerade aus EMI-Sicht! > Modul daher so klein wie möglich halten. Dann werden natürlich die > ganzen 100n-Kondensatoren in 0402 gewählt und der PIC im 12x12mm TQFP100 > PT Package mit 0.4mm Pitch, und deswegen will ich das EEPROM auch im > SOT23-5 haben. Jepp. Löten will ich übrigens im modizierten 20 Euro Pizzaofen. Soll saugut gehen. Also für die Prototypen sollte das gehen. Wenn man dann 10000 Stück bauen will, würde ich dann mal nach China reisen. Siehe Raspberry... > SO-DIMM deswegen, weil der Sockel gleich für die mechanische Befestigung > sorgt und die Pins alle auf einer Seite liegen, was Groundloops > verhindert, und weil die SO-DIMM-Sockel problemlos erhältlich sind. > Alternativ Mini-PCI/Mini-PCIe o.ä. Ich hab den Verdacht, du kannst Gedanken lesen. Müsste man mal durchkalkulieren. Eventuell braucht's 2 Varianten: - die Integrierte mit Buchsen drauf, Pin Headers und 4 Befestigungsbohrungen mit Target lowest cost - die Modulare für's Prototyping, eventuell mit einem Satz verschiedener Kickstart Base Boards für die nichtlötenden Softwareker in der Gemeinde. Die Software wäre dann ja kompatibel. Soweit erst mal. Schönen Feierabend allerseits. Ulrich
Ulrich Sprick schrieb: > Wo wir gerade beim Thema sind: Ich habe eine RJ45 mit PoE von Midcom > gefunden, MIC66011-5171. Daran kann man sehr gut sehen, wie das PoE > funktioniert. Ueber eine Suchmaschine findet man das Datenblatt. > > Schlage vor, die Ausgänge hinter dem Gleichrichter mit der > Stromversorgung zu verbinden. Dann kann man das Kerlchen wahlweise über > ein Steckernetzteil oder über's LAN-Kabel füttern. Welchen POE PD Controller möchtest Du haben? TPS23750? Si3402? irgendwas anderes? Das ganze soll ja nachher auch 802.3af konform sein, um es hinter einen beliebigen POE Injector hängen zu können. Brauchen wir die isolierte Variante mit Flyback Topologie? Ich fürchte: ja. > Leider habe ich noch keine USB/RJ45 mit PoE Kombi gefunden. Bei USB würde ich Mini-USB ab verwenden zwecks OTG. fchk
Frank K. schrieb: > Welchen POE PD Controller möchtest Du haben? > TPS23750? Si3402? irgendwas anderes? Gottchen, dass muss ich erst mal googeln. > Das ganze soll ja nachher auch 802.3af konform sein, um es hinter einen > beliebigen POE Injector hängen zu können. Brauchen wir die isolierte > Variante mit Flyback Topologie? Ich fürchte: ja. äääh... s. o. >> Leider habe ich noch keine USB/RJ45 mit PoE Kombi gefunden. > Bei USB würde ich Mini-USB ab verwenden zwecks OTG. Jaaaaa.... Ja. OTG muss ich auch noch mal googeln, aber ich glaub ich es geht um Host oder Device. Aber Mini-USB ist ne gute Idee, soll ja klein werden. Andererseits: Die Mini-USB meiner externen Festpladde musste ich schon mal tauschen, weil alle (!!!) Anschlussdrähte im Knick gebrochen waren. Die Idioten hatten einen Biegeradius von 0 (null) Millimetern fabriziert. Da muss selbst der goldigste Draht brechen... Mal Digikey konsultieren. Bis gleich. Ulrich
Angehängte Dateien:
-
fig-01.png
8,2 KB
So jetzt bin ich im Bilde. Frank K. schrieb: > Welchen POE PD Controller möchtest Du haben? > TPS23750? Si3402? irgendwas anderes? So wie ich das aus dem Schaltbild der Midcom-Buchse (siehe Anhang) entnehme, sind die stromliefernden Anschlüsse V+ und V- vom Netz galvanisch nicht getrennt. Da ist ein Schaltregler ja geradezu Pflicht! Ich hatte schon darüber nachgedacht, aber einen Switcher mit hohem Wirkungsgrad (soll ja schön grün werden) bei dem niedrigen Leistungsbedarf ist ja auch nicht ganz ohne. Da sind die analogen Low Drop Längsregler ja noch richtig gut. Aber jetzt... Hmmm. Der Vorschlag von TI im Datenblatt schein mir ein kleinwenig oversized zu sein... und dann würde ich auch gleich noch die 3.3 V und eventuell andere Hilfsspannungen noch mit erzeugen. Die Spannungen kann man ja prima über das Wicklungsverhältnis auf der Sekundärseite festlegen. 12 V etwa für externe Festplatten, falls jemand einen Fileserver bauen will. Oder für die Gehäuse-Innenbeleuchtung. Muss man ja bringen heutzutage, wenn man im Showgeschäft bleiben will... Ich gehe mal weiter was Schlankes suchen. Da war ja noch der Si. Und LT hat vielleicht auch was im Programm. Da könnte ich auch gleich mal das aktuelle Switchercad absaugen. Bis nachher. Ulrich
Der SI3402 ist mir etwas sympathischer, weil er den Power MosFET mit integriert hat. Und was macht der TI mit der Hilfsspannung an AUX? Versorgung für den MosFET Gate Driver? Hmm. Aber TI hat zeigt auf jeden Fall mehr Liebe zum Detail. ~
Zum Thema PoE ein Aufsatz. Zwar von 2004, dafür kurz und knackig: Teil 1 www.all-electronics.de/media/file/3641 Teil 2 www.all-electronics.de/media/file/3667 Gute N8 zusammen. Ulrich
Hallo alle zusammen, da ich ja relativ wenig Ahnung von Hardware habe war ich in letzter Zeit nur stiller Mitleser. Ich will mich jedoch auch noch einmal zu Wort melden. Ich denke wir sollten aufpassen, dass wir nicht abheben. Korrigiert mich wenn ich falsch liege aber urspruenglich war die Idee eine Grundplatine fuer WiFi zu basteln. Das muss ja nicht das Ergebnis sein nur sollten wir aufpassen, dass wir es nicht uebertreiben. Meine Meinung ist, dass wir so Dinge wie Switches oder Wifi-Ethernetbruecken den Projektrahmen sprengen. Den Vorschlag von Ulrich im 20 Euro-Bereich zu bleiben finde ich prima. Ich denke weiterhin, dass wir ein einfaches aber einfach erweiterbares Mainboard mit Wifi oder Ethernet (beide Varianten sollten moeglich sein, jedoch nicht gleichzeitig) sowie POE erstellen sollten, so dass auch Einsteiger es damit einfach haben. Zu viele spezifische Komponenten schrecken neue Mitstreiter, die vielleicht weniger Ahnung im Bereich Hardware und/oder Software haben nur ab. Ich habe mich im Detail nicht mit allen Bauteilen auseinander gesetzt, denkt nur bitte dran,dass wir solche verwenden, die mit den Microchip-Libs funtionieren, nicht dass wir durch andere, fremde Bausteine wieder bei den Treibern von vorne anfangen. Versteht mich nicht falsch, ich finde ihr habt gute Ideen, nur es muss einfach und handhabbar bleiben. Andernfalls haben wir einen neuen Raspberry Pi ... --------------------- Noch was vonmir zu POE: Ich habe mir schon mal den TPS23750 genauer angeschaut.MeinerMeinung nach ist dieser nicht schlecht. Wir sollten auf jeden fall wie bereichts geschrieben IEEE802.3af oder auch IEEE802.3at kompatibel sein. Auch finde ich die Idee nicht schlecht zumindest 5V (oder auch 12V) von POE auf der Platine zur Verfuegung zu stellen. Eine HDD damit zu betreieben weiss ich nicht ob das auf Grund vom Stromverbrauch gelingen wird (gerade der Anlaufstrom). Aber zumindest eine andere Platine mit Relais oder aehnliches sollte sie speisen koennen. Ich waere immernoch dafuer ein Dokument z.B. via Google Docs (Drive) zu erstellen, wo wir ein paar definitiv festgelegten Punkte einmal festhalten, damit wir neben dem Schaltplan die eigentlichen Ideen und Anforderungen die wir uns selbst stellen nicht aus den Augen verlieren. Editieren, erweitern, abaendern kann es ja jeder. Neue und offene Punkte koennen ja weiterhin hier diskutiert werden! Gruß meinereiner
Mein Konstrukt: http://www.hifi-forum.de/viewthread-71-9872.html PIC32MX695 VS1053 4,3 TFT mit Touch LAN8720 MRF24WB0MA SD Karte + NAND Flash USB Host / Device 74HC595 IO Expander Leider kein PoE / CAN >>Den Vorschlag von Ulrich im 20 Euro-Bereich zu bleiben finde ich prima. Der Vorschlag ist toll, aber wenn der MRF24WB0MA schon fast 30€ kostet sehe ich nicht wie die Rechnung aufgehen soll :) Mein Board war auch DEUTLICH teurer... Zu LAN / WiFi: Wartet auf den TCPIP Stack V6, der wird beides ganz geschmeidig unterstützen. Haut rein!
Nobody Niemand schrieb: > da ich ja relativ wenig Ahnung von Hardware habe das ändert sich gerade :-) > war ich in letzter Zeit > nur stiller Mitleser. Ich hatte schon Befürchtungen... > Ich denke wir sollten aufpassen, dass wir nicht abheben. Das mag stellenweise so aussehen, ja. Aber eigentlich sind das nur Ideen, die aus dem Kontext entspringen. Man geht ihnen etwas nach, diskutiert, wägt ab, und verwirft sie meist. Oder sie fliessen ins Konzept ein. Das ergibt sich dann aber aus der Diskussion, und normalerweise ist der Threadstarter ja dann auch der Oberboss und hat das letzte Wort. Für mich ist das gar kein Problem, also keine Bange. > Korrigiert mich wenn ich falsch liege aber urspruenglich war die Idee > eine Grundplatine fuer WiFi zu basteln. Hab ich nicht aus den Augen verloren. Daher auch der Vorschlag für ein 20 Euro Target. Obwohl das eher knapp wird, denn das WiFi-Modul kostet schon 15 Euro in 1000er-Stückzahlen. Sagen wir mal 20 Euro + WiFi. > Meine Meinung ist, dass wir so Dinge wie Switches oder > Wifi-Ethernetbruecken den Projektrahmen sprengen. Sehe ich ähnlich. Obwohl die "Brücke" lediglich ein Stück Software ist und mit Hardware gar nichts zu tun hat. Also keine Bange, > Den Vorschlag von Ulrich im 20 Euro-Bereich zu bleiben finde ich prima. Und ich erst ;-) > Ich denke weiterhin, dass wir ein einfaches aber einfach erweiterbares > Mainboard mit Wifi oder Ethernet (beide Varianten sollten moeglich sein, Genau. > jedoch nicht gleichzeitig) Das wird nicht gehen wie Frank (?) weiter oben schon dargelegt hat. Die Physik fordert einen räumlich dichten Aufbau. Ausserdem sind die Interfaces zu WLAN-Modul und Ethernet-PHY so dermassen unterschiedlich, dass ein Versuch der Vereinigung nichts bringt. Ausser technischen Problemen - und das will man überhaupt gar nicht. Daraus ergibt sich, das im Entwurf und im Boardlayout beide Optionen implementiert werden müssen. Allerdings hat man dann immer noch die Wahl über eine wahlweise Bestückung: Ethernet, WiFi, oder beides. > sowie POE erstellen sollten, so dass auch > Einsteiger es damit einfach haben. Sehe ich auch so. Ich denke sogar, dass PoE ebenfalls eine Bestückungsoption sein sollte im Hinblich auf die Kosten. Aber die PoE Option an sich finde ich äusserst attrativ - besonders wenn ich mir das bereits vorandene Sammelsurium an Steckernetzteilen hinter dem Sofa so anschaue. > Zu viele spezifische Komponenten > schrecken neue Mitstreiter, die vielleicht weniger Ahnung im Bereich > Hardware und/oder Software haben nur ab. Ich denke, das ist eine Frage von Darstellung und Psychologie. Bis jetzt haben wir ja gar nicht so viele Design-Komponenten: - MCU - Ethernet - Wi-Fi - PoE und Stromversorgung - Analog-IO Beschaltung. - Steckverbinder > Ich habe mich im Detail nicht mit allen Bauteilen auseinander gesetzt, > denkt nur bitte dran,dass wir solche verwenden, die mit den > Microchip-Libs funtionieren, Haben wir. Das einzige, was zur Zeit mit Software zusammenspielen muss, ist WiFi, und der PIC32. Alles andere ist reine Hardware und hat keine Interfaces zur Software. Frank, korrigier mich bitte, wenn ich mit dem Ethernet MAC/PHY falsch liege, aber ich glaube in dem Teil steckt nur Elektronik. Alles schön modular :-) > nicht dass wir durch andere, fremde > Bausteine wieder bei den Treibern von vorne anfangen. s. o. > es muss > einfach und handhabbar bleiben. Meine Zustimmung. Schliesslich haben wir alle nur einen begrenzten Zeitrahmen... > Noch was vonmir zu POE: > Ich habe mir schon mal den TPS23750 genauer angeschaut.MeinerMeinung > nach ist dieser nicht schlecht. Wir sollten auf jeden fall wie bereichts > geschrieben IEEE802.3af oder auch IEEE802.3at kompatibel sein. Wird sich automatisch ergeben, weil die vorgeschlagenen Chips für genau diesen Einsatzbereich entworfen wurden. > Auch finde ich die Idee nicht schlecht zumindest 5V (oder auch 12V) von > POE auf der Platine zur Verfuegung zu stellen. Eine HDD damit zu > betreieben weiss ich nicht ob das auf Grund vom Stromverbrauch gelingen > wird (gerade der Anlaufstrom). Würde es. Die "kleinen" PoE-Chips bringen so an die 11 Watt, das reicht dicke für 2.5" Platten. Das Leistungsspektrum reicht bis etwa 50 Watt. Allerdings hatte ich Platten und Innenbeleuchtung eher mit ;-) Ironie erwähnt; ich wüsste nicht, warum ich eine Platte anschliessen sollte... Aber wer weiss, ich bin nicht jedermann. > Aber zumindest eine andere Platine mit > Relais oder aehnliches sollte sie speisen koennen. Das war der Gedanke. Hauptziel beim PoE-Design sind aber eher weniger die technischen Daten, als die Kosten. Spannungsregler für 5 und 3.3 V brauchen wir auf jeden Fall, warun sollte das nicht der PoE-Chip machen? Das würde die beiden analogen Spannungsregler LM117 (?) ersetzen. Und die 12 V gibts für den Preis einer Zusatzwicklung kostengünstig dazu. > Ich waere immernoch dafuer ein Dokument z.B. via Google Docs (Drive) zu > erstellen, Ja mach das bitte. Wenn möglich ein Spreadsheet, oder noch besser eine Datenbank. Dieser Thread hier ist ja eher ein offener Gedankenflusskanal und hervorragend geeignet, heillose Verwirrung zu stiften. Aussedem muss ja irgendwo festgehalten werden, was denn nun Sache ist. > Editieren, erweitern, abaendern kann es ja jeder. Jaein... Es sollte einen Autor geben, dier die Änderungen nach Diskussion koordiniert. Sonst gibt das Chaos, garantiert. Kann man bei Google eigentlich alle Arten von Files ablegen, oder ist das nur ein Online Office? Sorry meine Unwissenheit, aber ich kann mich leider nicht um Alles kümmern... Schöne Grüsse Ulrich PS: Nicht abschrecken lassen - du wirst nicht untergebuttert. Ich bin ein höflicher Mensch (glaueb ich). Vielleicht etwas überschwenglich begeistert. Aber ich hoffe, das ist nicht schlimm. Wenn doch: Einfach ansprechen.
Ulrich Sprick schrieb: >> Ich denke weiterhin, dass wir ein einfaches aber einfach erweiterbares >> Mainboard mit Wifi oder Ethernet (beide Varianten sollten moeglich sein, > > Genau. > >> jedoch nicht gleichzeitig) > > Das wird nicht gehen wie Frank (?) weiter oben schon dargelegt hat. Die > Physik fordert einen räumlich dichten Aufbau. Ausserdem sind die > Interfaces zu WLAN-Modul und Ethernet-PHY so dermassen unterschiedlich, > dass ein Versuch der Vereinigung nichts bringt. Ausser technischen > Problemen - und das will man überhaupt gar nicht. Genau. Natürlich gibts Alternativen: UDP-Durchsatz: (Quelle: Microchip TCP/IP Stack 5.31 Doku) 1. Interner MAC plus externer PHY (z.B. SMSC LAN8720A) via RMII: ca 8800 MB/S 2. ENC624J600 über 16 Bit PMP: ca 2100 MB/s 3. ENC424J600/624J6000 über SPI: ca 800 MB/s 4. ENC28J60 über SPI: ca 400 MB/s Über SPI haben wir nur noch 1/10'tel der Leistung, und das bei höheren Kosten: (Quelle: Digikey, 1'er Nettopreise) SMSC LAN8720A-CP: 1.72€ ENC28J60/SS: 3.14€ ENC424J600-I/PT: 4.02€ ENC624J600-I/PT: 4.36€ So, jetzt müsste es eigentlich auch der Letzte hier kapiert haben, dass alles andere als der interner MAC plus externer PHY Unsinn ist. >> Ich habe mich im Detail nicht mit allen Bauteilen auseinander gesetzt, >> denkt nur bitte dran,dass wir solche verwenden, die mit den >> Microchip-Libs funtionieren, > > Haben wir. Das einzige, was zur Zeit mit Software zusammenspielen muss, > ist WiFi, und der PIC32. Alles andere ist reine Hardware und hat keine > Interfaces zur Software. Frank, korrigier mich bitte, wenn ich mit dem > Ethernet MAC/PHY falsch liege, aber ich glaube in dem Teil steckt nur > Elektronik. Der PHY ist schon software-relevant. Der Stack unterstützt die folgenden PHYs: (Digikey Einzelstückpreise zum Vergleich) - National DP83640 (10.89€ örks! dafür mit IEEE1588-Support) - National DP83848 (>= 2.89€) - SMSC LAN8700 (2.12€) - SMSC LAN8720 (1.72€) . (Punkt) Ich habe den letzten ausgewählt, weil er am einfachsten zu beschalten ist und keinen 50 MHz Oszillator für RMII braucht, sondern mit einem 25 MHz Quarz auskommt. (Kosten!) Und weil er am billigsten ist. Wenn wir was anderes nehmen wollen, müssen wir einen Treiber für den Stack schreiben. Das ist dokumentiert und nicht wirklich schwierig, aber ohne wirklichen Grund macht das natürlich niemand. > Hauptziel beim PoE-Design sind aber eher weniger die technischen Daten, > als die Kosten. Spannungsregler für 5 und 3.3 V brauchen wir auf jeden > Fall, warun sollte das nicht der PoE-Chip machen? Das würde die beiden > analogen Spannungsregler LM117 (?) ersetzen. Und die 12 V gibts für den > Preis einer Zusatzwicklung kostengünstig dazu. Und wenn jemand keinen POE-Injektor hat, weil er beispielsweise WLAN verwendet? Der POE PD-Controller fängt ja erst nach dem Handshake mit dem Injektor an zu arbeiten. Einfach so 48V (das ist die Nennspannung, mit der POE arbeitet) anzuklemmen wird wohl nicht gehen. Ich habe es nicht ausprobiert, ich habe zwar 48V-Netzteile, aber keine POE Devices hier. POE ist daher niemals ein Ersatz für die ohnehin vorhandenen Linearregler. Ein einfaches Netzteil muss immer noch reichen. fchk
Moin allerseits, Frank, für mich sieht das gut aus so wie vorgeschlagen. Frank K. schrieb: > Und wenn jemand keinen POE-Injektor hat, weil er beispielsweise WLAN > verwendet? Tja, dann wollte ich eigentlich die externe Spannung einspeisen stattdessen. 12 V etwa. Aber: > Der POE PD-Controller fängt ja erst nach dem Handshake mit > dem Injektor an zu arbeiten. Einfach so 48V (das ist die Nennspannung, > mit der POE arbeitet) anzuklemmen wird wohl nicht gehen. Ich habe es > nicht ausprobiert, ich habe zwar 48V-Netzteile, aber keine POE Devices > hier. Das könnte stimmen. Ich lese mich gerade durch die Datenblätter. So wie ich das verstanden habe, signalisiert der PD (unser Board) dem PSE (einem Power Injector) mittels 25 kOhm "Signatur" seine Anwesenheit, und irgendwie auch seine Klasse. Daraufhin fährt der PSE die Spannung hoch, in verschiedenen Etappen. Ab 30 V etwa nimmt dann der PD seinen Betrieb auf. Das deutet darauf hin, dass Einspeisung von etwa 48 Volt aus einem einfachen Netzteil reichen müsste. Dummerweise hab ich auch grad kein 48 V Netzteil rumliegen. Und bei 12 V springt er noch nicht an :-( Mist. Da muss ich noch mal in mich gehen. Für 2 zusätzliche Spannungsregler bin ich zu geizig... > POE ist daher niemals ein Ersatz für die ohnehin vorhandenen Noch weigere ich mich, das zu glauben ;-) Harrghnnnn > Linearregler. Ein einfaches Netzteil muss immer noch reichen. Das sollte es auf jeden Fall. Melde mich später noch mal. Danke für den Input. Ulrich
Wobei ja auch ein 48V Netzteil nicht wirklich alltäglich ist. Wer das Teil mit WLAN und zwei LiPo Akkus betreiben möchte (wegen drahtlos), der sollte das auch machen können. fchk
Stampede schrieb: > Leider kein PoE / CAN Hm CAN. Nur mal in den Raum geworfen: Was denkt ihr darüber? Zumindest auf 2 Pins gelegt um es optional zu verwenden? Ulrich Sprick schrieb: > Jaein... Es sollte einen Autor geben, dier die Änderungen nach > Diskussion koordiniert. Sonst gibt das Chaos, garantiert. OK, herzlichen Glückwunsch, du hast das Los gezogen :-D Nein im Ernst, ich denke, dass Frank schon sehr viel am Zeichnen ist und da du ja auch sehr tief in der Matrie bist könntest du es wahrscheinlich noch am Ehesten machen. Ich helfe wo ich kann. Schickt mir mal eure Mailadressen per PN. Ulrich bekommt Schreibrechte, Frank und wer sonst noch will Leserechte. OK? Ulrich Sprick schrieb: > Kann man bei Google eigentlich alle Arten von Files ablegen, oder ist > das nur ein Online Office? Sorry meine Unwissenheit, aber ich kann mich > leider nicht um Alles kümmern... Kein Thema: Also mit Google Drive (was das neue Google Docs ist) geht das, klar. Da könnten wir auch den Schaltplan mit verteilen. Man kann dann auch einen Link dazu für alle lesend erstellen und den hier im Forum posten! Für die Windows-Fans unter unter uns kann das Google Drive auch direkt im Explorer eingebunden werden. Frank K. schrieb: > So, jetzt müsste es eigentlich auch der Letzte hier kapiert haben, dass > alles andere als der interner MAC plus externer PHY Unsinn ist. Ja sogar ich :-D Genau darauf wollte ich hinaus. Ich sehe ihr denkt genauso, nur das ihr das auch technisch besser einschätzen könnt! Frank K. schrieb: > POE ist daher niemals ein Ersatz für die ohnehin vorhandenen > Linearregler. Ein einfaches Netzteil muss immer noch reichen. Sehe ich genauso! Frank K. schrieb: > Wobei ja auch ein 48V Netzteil nicht wirklich alltäglich ist. Jap. Warum machen wir nicht beides? Man kann ja das ganze via Jumper oder Drahtbrücke auswählbar machen? Durch eine "optionale Bestückung" eben. Ulrich Sprick schrieb: > PS: Nicht abschrecken lassen - du wirst nicht untergebuttert. Ich bin > ein höflicher Mensch (glaueb ich). Vielleicht etwas überschwenglich > begeistert. Aber ich hoffe, das ist nicht schlimm. > > Wenn doch: Einfach ansprechen. Ach quatsch. Dann melde ich mich schon wenn ich denke das was falsch läuft. Bitte auf Gegenseitigkeit beruhen lassen. Wenn nicht im Forum dann gerne auch via PN. Ulrich Sprick schrieb: >> war ich in letzter Zeit >> nur stiller Mitleser. > > Ich hatte schon Befürchtungen... Dahin werde ich mich wieder zurückziehen und euch fachsimpeln lassen. Ihr könnt das eh besser. Ich melde mich wieder wenn mir was einfällt oder ich einen Kommentar abgeben möchte. ;-)
Nobody Niemand schrieb: > Stampede schrieb: >> Leider kein PoE / CAN > Hm CAN. Nur mal in den Raum geworfen: Was denkt ihr darüber? Zumindest > auf 2 Pins gelegt um es optional zu verwenden? Wenn Du einen Blick auf meinen Schaltplan geworfen hast, wirst Du den MAX13054 CAN-Transceiver sicher gefunden haben. :-) fchk
Moin allerseits, Frank K. schrieb: >> Hm CAN. Nur mal in den Raum geworfen: Was denkt ihr darüber? Zumindest >> auf 2 Pins gelegt um es optional zu verwenden? > Wenn Du einen Blick auf meinen Schaltplan geworfen hast, wirst Du den > MAX13054 CAN-Transceiver sicher gefunden haben. Also ich hab ihn gesehen :-) Aber mal eine grundsätzliche Frage: CAN ist ja nun DIE Automatisierungsschnittstelle aus der Automobilbranche, aber ganz ehrlich: Ich hab's noch nie wirklich gebraucht. Innerhalb eines Gerätes würde ich eher auf I2C oder UART für die Inter-Modul-Kommunikation zurückgreifen. Und zwischen Geräten bräuchte man dann ein Kabel. Kabel sind mir irgendwie unsympathisch. (Meinem Vermieter scheinbar auch, denn er guckte so merkwürdig, als ich von Wandbohrungen sprach, um fehlende LAN-Kabel zu verlegen...) Vorschlag zur Abstimmung daher: Wollen wir den CAN Driver auf ein/das Trägerboard verlegen? Ein Trägerboard (in der Art von Ulrich Radig's Relaisplatine für sein Web-Modul) ist ja schon stärker problemorientiert als unsere Controllerplatine, daher würde ein Driver dorthin besser passen. Vorteil: Weniger Space. Nachteil: Weniger Funktionalität out-of-the-box. Schöne Grüsse Ulrich
Nobody Niemand schrieb: > Hm CAN. Nur mal in den Raum geworfen: Was denkt ihr darüber? Zumindest > auf 2 Pins gelegt um es optional zu verwenden? Auf Pins sollten wir alles legen was die Steckverbinder hergeben. Ulrich
Nochmal Stromversorgung: Irgendwie packt mich ja das PoE-Problem an meiner Ehre. Nur für PoE einen kompletten Schaltregler, und das zusätzlich? Welch eine Verschwendung... Ich fasse mal die Requirements kurz zusammen: - Stromquelle entweder 3 V (min) Akku - oder 5...12 V Standard-Netzteil - oder PoE Hab ich was vergessen? 3 Volt Eingangsspannung könnte etwas knapp werden für Spannungsregler :) Die 5 Volt brauchen wir für - USB - CAN - ? Meine Idee: Einen kleinen konventionellen Schaltreger für 3.3 und 5 V, der die beiden analogen Stabis ersetzt. Eingangsspannungsbereich 5 bis 57 V. Wenn das klappt, in einem 2. Schritt das Interfacing für PoE hinzufügen. Nachdem was ich bisher gelesen habe, traue ich mir das wohl zu. Wenn man das Gerät mit 2 MiMHs betreiben will, lässt man eher den kompletten Spannungsregler weg und betreibt das Teil direkt aus den Akkus - was auch energiemässig auch am effizientesten ist. Andererseits: Wollt ihr wirklich einen TQFP-100 Bomber in ein akkugspeistes Gerät zwängen? Na ja, zum testen vielleicht. OK. Soll so sein. Wie ist eure Meinung so? Schöne Grüsse, Ulrich
Ulrich Sprick schrieb: > Also ich hab ihn gesehen :-) Aber mal eine grundsätzliche Frage: CAN ist > ja nun DIE Automatisierungsschnittstelle aus der Automobilbranche, aber > ganz ehrlich: Ich hab's noch nie wirklich gebraucht. Innerhalb eines > Gerätes würde ich eher auf I2C oder UART für die > Inter-Modul-Kommunikation zurückgreifen. Kommt darauf an, wie groß das Gerät ist. I2C ist nicht dafür gedacht, die Platine zu verlassen. RS485 bedient eine ähnliche Zielgruppe, aber bei CAN macht der Controller selber mehr. > Vorschlag zur Abstimmung daher: Wollen wir den CAN Driver auf ein/das > Trägerboard verlegen? Es ist doch nur ein SO08. Ich würde ihn drauflassen, weil es sozusagen eine Konstante ist und keine Variable. fchk
Ulrich Sprick schrieb: > Irgendwie packt mich ja das PoE-Problem an meiner Ehre. Nur für PoE > einen kompletten Schaltregler, und das zusätzlich? Welch eine > Verschwendung... Das ist normal. > Ich fasse mal die Requirements kurz zusammen: > > - Stromquelle entweder 3 V (min) Akku muss nicht sein. LiPo Akkus haben 3.6-3.8V Nennspannung, bei zweien wäre man bei 7.4-7.8V. Das ist doch ok. Oder 12V Blei-Gel-Akku. Jedenfalls keine 48V. > - oder 5...12 V Standard-Netzteil > - oder PoE > Die 5 Volt brauchen wir für > > - USB > - CAN > - ? > Meine Idee: Einen kleinen konventionellen Schaltreger für 3.3 und 5 V, > der die beiden analogen Stabis ersetzt. Eingangsspannungsbereich 5 bis > 57 V. Wenn ich was analoges mache, will ich keine Schaltregler drauf haben, die mir irgendwo reinstrahlen. Schaltregler sind auch Aufwand. POE ist für mich eher optional. Es gibt Module dafür, die man einsetzen kann, wenn man das tatsächlich braucht. Die Arduino-Leute nehmen das hier z.B. http://arduino.cc/en/uploads/Main/PoE-datasheet.pdf Gibts überall, wo es Arduino zu kaufen gibt. Die Stromversorgung gehört für mich eher auf das Trägerboard, weil das applikationsspezifisch ist. Die Linearregler wären eine billige und einfache Defaultlösung. fchk
Hier ist es auf einmal so ruhig geworden. Sommerferien? Verzweiflung? fchk
Frank K. schrieb: > Hier ist es auf einmal so ruhig geworden. Sommerferien? Verzweiflung? Ich habe mich auch schon gewundert. Ich lese noch fleissig mit! ;-) Zum Thema POE: Ich kenne das Modul was du verlinkt hast auch noch unter einem anderen Namen. Prinzipiell finde ich die Idee nicht verkehrt, die Frage ist nur ob es in Verbindung mit einer 1-Chip-Lösung+Regler nicht pereiswerter ist. Auf jeden Fall sollte es optional sein. Man kann die Schaltung ja vielleicht so auslegen, dass der Spann8ungsregler je nach Bestückung gewählt werden kann?! Dann ist beiden Vorschlägen genüge getan, oder? POE aber bitte auf die Hauptplatine, da es auf Grund der RJ45-Abgriffe sonst unübersichtlicher wird. Ich denke das die Spannungsversorgung auf dem Hauptboard sein sollte. Frank K. schrieb: > Wenn Du einen Blick auf meinen Schaltplan geworfen hast, wirst Du den > MAX13054 CAN-Transceiver sicher gefunden haben. Warum frage ich überhaupt, ihr denkt eh an alles ;-) Nein im Enrst: Ich denke wir sollten das optional vorsehen. Von mir aus auch auf einem Extra-Board, halt nur das man es verwenden kann. Vielleicht habe ich nur wieder was übersehen aber trotzdem eine ganz andere Frage: Wie sollen wir die PIC32 programmieren? Via Bootloader über USB? Gruß meinereiner
Nobody Niemand schrieb: > Vielleicht habe ich nur wieder was übersehen aber trotzdem eine ganz > andere Frage: Wie sollen wir die PIC32 programmieren? Via Bootloader > über USB? Per ICD3 oder PicKit3. fchk
Frank K. schrieb: > Per ICD3 oder PicKit3. Wie auch immer, wir sollten die kostengünstigste Variante in den Fokus nehmen, da vielleicht so Umsteiger wie ich sich erst noch einen passenden Flasher zulegen müssen. Mein Atmel-JTAG wird das wohl nicht mitmachen. Ulrich ist vielleicht im Urlaub (zumindest meldet er sich nicht mehr). Was denkst du sind die nächsten Schritte? Wir haben ja über allerlei Module diskutiert. Hast du ein klares Bild wie du es auf Grund unserer Diskussionen umsetzten würdest? Du hast ja schon einiges gemacht, vielleicht ist ja auch schon alles eingeflossen. POE habe ich zum Beispiel noch nicht auf deinem hochgeladenen PDFs gesehen (oder ich bin blind). Wie auch immer: Es wäre gut, wenn wir noch die offenen Punkte sammeln würden. Wenn diese erledigt sind sollten wir noch einmal grob alles zusammen fassen (welche Module sind optional, was kommt auf Mainboard was auf eine optionale Platine) damit alle Leser hier noch eine Übersicht haben. Anschließend können wir mit dem Layouten beginnen.
Für mich wäre 12/24V POE wichtig, max 30V(ev. 35) mit günstigem Schaltreger oder LDO, nach dem POE injection Prinzip, günstig und einfach, natürlich optional da nicht so standardconform.
Nobody Niemand schrieb: > Frank K. schrieb: >> Per ICD3 oder PicKit3. > Wie auch immer, wir sollten die kostengünstigste Variante in den Fokus > nehmen, da vielleicht so Umsteiger wie ich sich erst noch einen > passenden Flasher zulegen müssen. Mein Atmel-JTAG wird das wohl nicht > mitmachen. Das PicKIT3 kostet etwa 50€ und kann alle aktuellen PICs, ob groß oder klein, ob 8, 16 oder 32 Bit programmieren und debuggen. Das ICD3 (ca 200€), mit dem ich arbeite, ist die Profiversion und etwas schneller. Dann gibts noch das RealICE (ca 500€), das dann auch RealTime Trace über die Pins TRCLK(91) und TRD0(97), TRD1(96), TRD2(95), TRD3(92) unterstützt. Die eigentliche ICSP-Schnittstelle ist immer die gleiche. Die Microchip-Tools benutzen JTAG nicht. > Wir haben ja über allerlei Module diskutiert. Hast du ein klares Bild > wie du es auf Grund unserer Diskussionen umsetzten würdest? Du hast ja > schon einiges gemacht, vielleicht ist ja auch schon alles eingeflossen. > POE habe ich zum Beispiel noch nicht auf deinem hochgeladenen PDFs > gesehen (oder ich bin blind). Nein, POE ist in den Plänen noch nicht drin. Diese Pläne hatte ich mal für ein anderes Projekt gemacht, das aber nie realisiert wurde. Ulrich lag viel an POE, und er wollte sich drum kümmern. Ich würde hier den Weg gehen wollen, die die Arduino-Leute gewählt haben - POE als extra Modul, zunächst als Fertigteil, später vielleicht als Eigenbau. > Wie auch immer: Es wäre gut, wenn wir noch die offenen Punkte sammeln > würden. Wenn diese erledigt sind sollten wir noch einmal grob alles > zusammen fassen (welche Module sind optional, was kommt auf Mainboard > was auf eine optionale Platine) damit alle Leser hier noch eine > Übersicht haben. Anschließend können wir mit dem Layouten beginnen. Genau. Wobei wir da auf Ulrich warten sollten. fchk
Chris schrieb: > optional da nicht so standardconform. Au weia. "Standardkonform" ist für mich eine binäre Eingenschaft, und im Falle von POE auf true gesetzt. fchk
Die Sache ist die, POE Modul muss 60V können. Während des power discovery sind aber nur 30V erlaubt, also funktionieren auch alte Geräte ohne Signatur. Wegen dieser 60V sind sie eigentlich so teuer. Wieso muss ich 17€ für ein add-on Modul ausgeben, wenn es doch nur 0.5-2€ an zusätzlichen Komponenten braucht, und ich keine 100mt oder auch große Watt brauche ? Meistens geht es um ein paar Meter mit 12V oder 24V. Dass das Add-on Modul zusätzlich reingesteckt werden kann, das kann/soll bitte gemacht werden, aber wenn man mit Spannungen von max30V als Obergrenze, aber sonst 12/24 V hat, dann kann man ev. auch einen günstigen Step-Down oder auch Linearwandler nehmen + ein bisschen Schutzschaltung + Kondensator. So meine Meinung. Angenommen das Modul braucht 170mA bei 3.3V , sind also ca 55mA bei 12V oder 25mA bei 24V mit einem günstigen Step-down. Bei besseren Netzwerktreibern als Microchip vielleicht 1/3-1/4. Also POE ohne 802.3af Protokoll auf unbenutzte Leitung, Standardkonform existiert, es ist jedoch ein überholter Standard. Wenn jetzt da dann 1-2V Spannungsdrop dazukommen (10mt) oder 4-6V (x-FTP) (10mt) worst case, dann steigen die mA Zahlen noch um vielleicht 25%, alles nicht kritisch.
Wifi Module mit serieller Schnittstelle: http://www.solutron.de/epages/61427429.sf/en_GB/?ObjectPath=/Shops/61427429/Categories/Industrieller_Datenfunk/WiFi
Chris schrieb: > Also POE ohne 802.3af Protokoll auf unbenutzte Leitung, Standardkonform > existiert, es ist jedoch ein überholter Standard. Sagst Du mir auch, wer das unter welcher Bezeichnung normiert hat? Wenn wir ein POE-Modul nutzen, dann spricht ja nichts dagegen, dass Du Dir Dein eigenes machst. Als Bestückungsoption ist alles andere als 802.3af ungünstig. Der Aufpreis wäre in diesem Fall aber auch nicht so groß. fchk
Frank K. schrieb: > Hier ist es auf einmal so ruhig geworden. Sommerferien? Verzweiflung? Wurde zum Wandern gezwungen. Sorry. Freundin war zu Besuch, ist jetzt aber wieder weg, so dass ich mich wieder den wirklich wichtigen Dingen im Leben widmen kann ;-) Grüezi Ulli
Nobody Niemand schrieb: > Ulrich ist vielleicht im Urlaub (zumindest meldet er sich nicht mehr). So könnte man das auch nennen. Urlaub braucht doch kein Mensch. Das hält doch bloss auf und stört den Ideenfluss. ;-)
Hoi zäme,
arbeite mich gerade in Schaltregler ein. Daher auch ein wenig die Ruhe.
> Wenn ich was Analoges mache, will ich keinen Schaltregler... (oder so ähnlich)
Kann ich gut nachvollziehen. Schaltregler machen Rauschen (Störungen)
auf den Versorgungsleitungen, und die elektromagnetischen Felder streuen
in andere Schaltungteile ein durch elekrische bwz. magnetische Kopplung.
Kann man aber in den Griff kriegen, denke ich. Z. B. separater Zweig für
die Versorgung der Analogteile, getrennte Masseführung, besondere
Siebung usw.
Aber noch isses ja nicht so weit. Schaltregler ist ja auch wohl nicht
billiger als Längsregler.
muss los
komme wieder
Forts. PoE heisst ja auch nicht unbedingt Schaltregler. Vor allem im Bereich geringer Eingangsspannungen und gleichzeitig geringem Leistungsbedarf sehen Schaltregler u. U. extrem schlecht aus, was den Wirkungsgrad angeht. Bei hohen Eingangsspannungen sieht es dann schon wieder anders aus. Im Moment brüte ich über einem Konzept, das einen PoE PD Controller (von LT zum Beispiel) mit einem separaten quasi-konventionellen Schaltregler kombiniert. Der wiederum hat dann 2 Eingänge, einmal 48 bis 70 V und einmal (5) 12 bis 24 V oder so. Und mehrere Ausgänge (3.3, 5 V und eventuell was man sonst noch so braucht). Das Ganze mit einem einzigen Übertrager und natürlich galvanisch von den Stromquellen getrennt. Ich glaube das kriegt man sogar ganz platz- und kostengünstig hin. Einziger Knackpunkt: Der Übertrager. Das wird wohl kein Standardteil von der Stange aus dem Katalog. Aber wenn's funktioniert, würde ich durchaus mal so ein, zweihundert Dinger vorfinanzieren. In der Hoffnung, es kommt irgendwann wieder rein... Ach, da ist noch ein kleiner Knackpunkt: Ich habe noch nie einen SMPS-Trafo dimensioniert... Will heissen, es könnte danebengehen. Aber für solche Fälle gibt's ja das gute alte Breadboard. Und Simulationssoftware :-) Und Experten, die man vielleicht fragen könnte. Der konventionelle Alternativ-Ansatz ist natürlich ein Standard-Stromversorgungsentwurf (analog oder SMPS) kombiniert mit einem Standard-PoE-Standard als "Vorstufenregler". Soweit erst mal die Gedanken zur Stromversorgung. Schönen Feierabend! Ulrich PS: Analoger Stabi für den Analogteil kann man natürlich immer noch. Da gibt's ja schöne geeignete Dreibeiner. Also nicht die Humanoiden jetzt.
Ich möchte eine kombiplatine machen: USB slave+Host PIC18F14K50 als slave mit i2c Anbindung zu carambola sowie 32khz osc. Irgendein MCU mit ETH+USB als günstigere Alternative zu carambola Irgendein MCU mit ADC optional, z.B. attiny24 mit i2c zum Rest angeschlossen Step-down von 5.6-34V 0.75A auf 5V/3.3V mit MC34063 5V->3.3V step-down für carambola Dataflash+(µ)SD Card i2c sram/fram/eeprom RS485 / Lin Temperatursensor Funkmodul(RFM70/RFM12...) 2x ETH (Magjack) Xbee footprint GPRS Modem Wenn es interessiert, dann mache ich ein neues Post auf. Preislich sollte es eine 10€/20€/30€ Lösung sein je nach Ausbaustufe.
Hallo an alle, Ich wollte mal fragen was der Schaltplan macht? Es ist recht ruhig hier geworden. Letzter Stand war das Ullrich noch an der Spannungsversorgung in Verbindung mit POE arbeiten wollte. Gibt es was Neues dazu? Gruß meinereiner
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.