Benutzer:Sven

Sven versucht zurzeit Ethersex mit SD-Card und HTTP Server zum Laufen zu kriegen. :-) Das macht er mit dem Pollin AVR-NET-IO (Best.Nr. 810 058 bzw. 810 073) umgerüstet auf 3,3V und ATMEGA644 mit 14,7456MHz Quarz. Desweiteren stehen einige Versuche mit Atmega8 / 88 und Atmega32 und USB an.

--Sven 09:29, 18. Jun. 2009 (UTC)

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.

74HC595 Schaltung

Beispiel-Schaltplan

• 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. Falls gewünscht ich würde meine Version auch commiten. (muss nur Git-fit werden) --update: mit Github soll das jetzt einfacher sein

---

SD-Card Reader

SD-Card Reader Vorderseite

SD-Card Reader Rückseite

• erstes Funktionsmuster auf Lochrasterplatine
• die schwarze Leitung ist CS
• Ich habe den SD CS-Pin auf PB1 gelegt, da an PB2 ja INT vom ENC28J60 hängt und PB1 auf J11 rauskommt
• Der Jumper auf der Rückseite ist da, weil ich nicht genau wusste ob ich den CS-Anschluss brauchen werde. Aber er wird tatsächlich benötigt, wenn noch weitere Hardware (z.B. der Ethernet-Chip) am SPI-Bus hängt.
• Angeschlossen an ISP des Pollin NET-IO. An Pin 3 der ISP Buchse habe ich die 3,3 Volt vom Board gelegt, die die SD (MMC) Karte speisen
• Die Widerstände setzen den 5V-TTL Pegel auf 3,3 Volt herunter, weil die Speicherkarte sonst Schaden nehmen könnte. Bei einem Betrieb des Mikrokontrollers mit 3,3 Volt kann auf die Spannungsteiler verzichtet werden.
• Schaltplan kommt noch

Wie oben erwähnt sorgt folgender Code in netio.m4 oder, wie in meinem Fall, in hc595_netio.m4 für den funktionierenden SD-Card Reader, welcher auch in menuconfig eingeschaltet sein muss.

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.