Benutzer:Sven
Sven versucht zurzeit Ethersex mit SD-Card und HTTP Server zum Laufen zu kriegen. :-) (auf dem Pollin NET-IO mit ATMEGA644)
--Sven 09:29, 18. Jun. 2009 (UTC)
Inhaltsverzeichnis
Endlich habe ich Ergebnisse:
- http Webserver ging von Anfang an
- serielles Debugging funktioniert (Ursache siehe unten)
- HC595 an den Pins PD2, PD3 und PD4 (10-poliger EXT.) funktioniert hardwaretechnisch und via 'ecmd set port 4 ff' via http, telnet, und sogar über die serielle Debug-Konsole! Großartig! :-)
- SD-Card kann via "sd dir" angesprochen werden, sie geht also, muss nur noch als http-Server root eingerichtet werden (weiß noch nicht wie)
Die Hardware m4-Dateien
- HC595 Pin - Definition
Update: habe inzwischen die Technik begriffen (bilde ich mir ein ;-) ) und in /pinning/hardware/netio.m4 folgende Eintragungnen gemacht:
ifdef(`conf_HC595', `dnl
/* port pin the HC595_CLOCK is attached to */
pin(HC595_CLOCK, PD2, OUTPUT)
')dnl
ifdef(`conf_HC595', `dnl
/* port pin the HC595_DATA is attached to */
pin(HC595_DATA, PD3, OUTPUT)
')dnl
ifdef(`conf_HC595', `dnl
/* port pin the HC595_STORE is attached to */
pin(HC595_STORE, PD4, OUTPUT)
')dnl
Was dazu führt, dass der Compiler nicht mehr über die HC595 Pins und Ports meckert. Jetzt schmeckt ihm was mit uip nicht. (Später mehr dazu.)
Update --Sven 23:29, 21. Jun. 2009 (UTC) Hatte mit folgender Vorgehensweise (Teil-)Erfolg:
- Die obigen Änderungen aus /pinning/hardware/netio.m4 entfernt
- nach make menuconfig mit Einschalten des full-io und hc595 Support (hatte ich vorher auch schon)
(In add-hardware-brocken gibt es Templates für diverse Hardware. Was in .config "an" ist wird in das neue Hardwarefile übernommen. Das ist insofern unglücklich, weil man nach 'make menuconfig' add-hardware-brocken ausführen muss, um die passenden Einträge in ein neues m4-File zu bekommen. Das geht aber nicht, wenn das m4-File für die neue Hardware existiert.)
- ./scripts/add-hardware-brocken hc595_netio ausgeführt und in dem nun eingefügten Template-Code die Pins angepasst
- make läuft ohne Fehler durch
- als Nächstes: Test des so erzeugten Firmwarefiles
Update --Sven 16:32, 23. Jun. 2009 (UTC)
Es funktioniert einwandfrei! :-) Ich hatte ein Verständnisproblem mit den .m4-files in /pinning/hardware/! Ich dachte in /pinning/hardware/netio.m4 steht alles für meine NET-IO-Hardware und add-hardware-brocken würde diese Datei ändern, da ich das Profil ja im make Menü ausgewählt hatte. Tatsächlich stellt add-hardware-brocken das Profil im Menü auf das neu angelegte um. Das netio.m4 benutze ich jetzt überhaupt nicht mehr. Offenbar ist auch nur der CS-Pin für den Ethernet-chip wichtig, wenn man Ethernet nutzen will.
Der Inhalt meiner hc595_netio.m4 sieht jetzt so aus:
* pins for the hc595 shift register */ pin(HC595_DATA, PD3) pin(HC595_CLOCK, PD2) pin(HC595_STORE, PD4) /* port the enc28j60 is attached to */ pin(SPI_CS_NET, SPI_CS_HARDWARE) ifdef(`conf_SD_READER', `dnl /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB1, OUTPUT) ')dnl
Damit funktioniert die Hardware auf die es mir zurzeit ankommt.
Was ich festgestellt habe:
- Der Schaltplan in hardware/io_expander/hc595.sch ist falsch. Die Pins 10 des HC595 müssen an VCC und die Pins 13 an GND. (ich ändere die gschem-Datei noch)
- Der Schaltplan sollte jetzt stimmen, danke für den Hinweis --stettberger 17:13, 18. Jun. 2009 (UTC)
update: Vielen Dank für die schnelle Reaktion. :-)
Ich habe trotzdem mal den Plan überarbeitet und finde ihn so übersichtlicher und nicht unlogisch.
Fals gewünscht ich würde meine Version auch commiten. (muss nur Git-fit werden)
SD-Card Reader
- Hardware steht, sollte funktionieren
- Compilerfehler, den doppelt definierten CS-Pin betreffend, sind seit dem Wochenende (oder so) Geschichte
- Ich habe den SD CD-Pin auf PB1 gelegt, da an PB2 ja INT vom ENC28J60 hängt und PB1 auf J11 rauskommt
ifdef(`conf_SD_READER', `dnl /* port the sd-reader CS is attached to */ pin(SPI_CS_SD_READER, PB1, OUTPUT) ')dnl
serielles Debugging
Damit das richtig funktioniert sind folgende Dinge wichtig:
- die Fuse Bits des m644 auf hfuse 0xdc und lfuse 0xe7 setzen -> sonst Kauderwelsch an RS232
Grund dafür ist, dass der Atmega 644 in Werkseinstellung mit internem RC-Oszillator läuft. Damit funktioniert zwar Einiges (in Zeitlupe), aber die serielle Schnittstelle ist zu lahm. (Dank an --jochen)
Stella empfiehlt einen Blick auf den AVR Fuse Calculator zu werfen. Man sollte aber trotzdem wissen was man damit macht ;-)
Falls noch nicht geschehen: Fuses mit Atmel Programmieradapter via USB "brennen" (geht natürlich auch ein anderer Adapter)
avrdude -c avrispmkII -P usb -p m644 -U lfuse:w:0xe7:m -U hfuse:w:0xdc:m
ansehen mit
avrdude -c avrispmkII -P usb -p m644 -v
- die Baudrate ist 115200 (38400 und 9600 unter Umständen möglich)
- welche im Einzelfall aktiviert wird, steht in Serial Line Debugging --Stella 16:18, 18. Jun. 2009 (UTC)
- mit Terminalprogrammen geht es nicht richtig (?)
- bei minicom und Konsorten muss man in den Einstellungen Handshaking ausschalten; grundsätzlich geht es schon (ich verwend' immer minicom) --Stella 16:18, 18. Jun. 2009 (UTC)
- am besten mit dem Programm screen unter Linux verbinden
screen /dev/ttyS0 115200 8N1 oder screen /dev/ttyUSB0 115200 8N1
Jetzt kann man sich mit dem Ethersex "unterhalten". Auf "ip" erscheint die IP-Adresse. Cool! :-) Um screen zu beenden drücke Strg-a k, dann mit y (j) bestätigen.
