Några kanske minns Craft demot med en ATmega88 som drev en VGA skärm, med scroll bl.a.
I sin konstruktionsbeskrivning skriver konstruktören: "This is used to generate high resolution scroll text: The MOSI pin is connected to a shift register internally in the AVR (it is typically used for serial data transmission), and this shift register can be programmed to emit a sequence of 8 bits with a single instruction, thus offloading the CPU. Smooth scrolling is then implemented by inserting variable delays before and after each display line".
Jag antar att det finns någon mekanism för att skicka flera bytes i rad utan avbrott?
Det borde kunna användas för att skicka 10Base-T (10 Mbit/s) data genom att machesterkoda och dumpa på SPI bussen..? (transistor .. +5V .. ethernet trafo)
Mottagning är värre, men om SPI bussens klocka SCLK går i takt med inkommande data borde det gå att ta emot?
Även om man missar dom första bitarna så innehåller ethernet paketet en preamble som ändå kastas.
(allt för att slippa ENC28J60 som är den enda ELFA säljer vid en snabbtitt)
Ethernet bitbang med SPI?
Re: Ethernet bitbang med SPI?
Sant.. 73-689-88 RTL8019A för 172 kronor i PQFP-100 (eller 73-067-33 DP83816AVNG LQFP-144 för 74 kr)
I vilket fall som helst vore det bra om det fanns en bitbang väg för att få ethernet funktion. Är något nyfiken på om det skulle kunna fungera.
I vilket fall som helst vore det bra om det fanns en bitbang väg för att få ethernet funktion. Är något nyfiken på om det skulle kunna fungera.
Re: Ethernet bitbang med SPI?
Fungerar knappast i dagens nätverk, du måste implementera handskakning, timing (rätt precis sådan för sändaren) och förmodligen CSMA/CD också
Tror knappast att du lär komma upp i 10Mbit med en vanlig uC.
RTLen är trevlig att jobba med, har dock aldrig jobbat med ENCerna.
Betydligt enklare att använda kretsar avsedda för ändamålet.
Dessutom, eftersom en frame är ca 1500 bitar blir det svårt att hantera en hel frame i en liten uC i det läget måste du ha en dedicerad kontroller. Eftersom Checksumman kommer före data (ialla fall när det gäller TCP) så får man tillgripa lite speciella tekniker för uC med begränsad mängd minne.
Nä glöm det.
Tror knappast att du lär komma upp i 10Mbit med en vanlig uC.
RTLen är trevlig att jobba med, har dock aldrig jobbat med ENCerna.
Betydligt enklare att använda kretsar avsedda för ändamålet.
Dessutom, eftersom en frame är ca 1500 bitar blir det svårt att hantera en hel frame i en liten uC i det läget måste du ha en dedicerad kontroller. Eftersom Checksumman kommer före data (ialla fall när det gäller TCP) så får man tillgripa lite speciella tekniker för uC med begränsad mängd minne.
Nä glöm det.
Re: Ethernet bitbang med SPI?
Är intresserad av hurvida det går att använda SPI/bitbang för ethernet. Så man inte är beroende av interfacechip 
, vill minnas att RTL8019 chippen dessutom behöver 8-bit + kontroll signaler för att fungera. GPIO är alltid lättare att få tag på jämfört med ett nytt chip .. 
I ATmega 48/88/168 databladet för SPI på sid 168 står det att flaga+IRQ signalerar "färdig". Om man lite fräckt räknar på klockcycklerna borde det gå att läsa och skriva till det interna SRAM minnet samtidigt som SPI:n bitbangar. Och sedan fylla på med NOP så att skiftregistret fylls eller läses av i exakt rätt ögonblick utan att vänta på bekräftelse av den föregående 8-bit skiftningen. För få en jämn takt utan pulsförlängning i 8-bits skarvarna.
Minsta paket är 7+65 bytes. Som således får plats i det interna 512-1024 bytes SRAM:et.
Så något i stil med för en klocka 4x bitrate:
Läs SPI
Skriv SRAM #0
Nop
IN R16, SPDR ; SPI till register, 1 clk
ST X+, R16 ; register till SRAM(X) samt X=X+1, 2 clk
NOP ; 1 clk
osv..
.
.
Då 20 MHz är max så får man överklocka minst 2x ..
Hittade dock en intressant funktion: "USART in SPI mode":
Vid 20 MHz klocka och UBBRn=0 får man en bithastighet på 10 Mbit/s (sid 198).
Och det verkar som till skillnad från UART mode så kan man läsa in en bitström utan att vissa bitar tolkas som start/paritet/stop-bitar. Vilket skulle ge 16 klockcykler per byte att utföra instruktioner parallellt med sändning/mottagning. Därmed borde något liknande fungera:
IN R16, UDRn ; UART buffer till register, 1 clk
ST X+, R16 ; register till SRAM(X) samt X=X+1, 2 clk
NOP ; 1 clk
NOP ; 1 clk
(tills 16 klockcykler är utfyllda)
osv..
@TomasL,
* Handskakning, du tänker förmodligen på Autonegotiation men dess tillämplighet är specifierad till "However, its implementation was optional". Och att generera 100 ns pulserna går lätt med två st out-port instruktioner. Vill man ha FLP ligger den på 4 kbit/s.
* Timingen är främst beroende av skarven mellan in/utmatningen av efterföljande 8-bitars bytes.
* CSMA/CD är inte ett jättestort problem med switchade nätverk och full-duplex. Samt att nätverket har en viss tolerans, perfektion i denna implementation är inte absolut nödvändlig. Och det går att lyssna av linjen någorlunda.
* Riktar in mig på UDP, det protokollet kan hanteras enkelt. Och minimi kravet är endast 65 bytes samt CRC32. Vilket lätt går in i 512 bytes.
* RTL8019 kräver >8 st GPIO vad jag minns, ENC28J60 ha en tjock errata, och båda kräver inköp.
Om jag t.ex vill kunna ställa en klocka, styra en alfanumerisk display mm räcker det med ett paket "gör X" samt "uppfattat". Delmoment som kan bli jobbiga men knappast supersvåra är bitskiftning för byte alignment, CRC32 beräkning, hantering av ARP. UDP IPv4 är t.om utan checksumma så där klarar man sig med en färdig mall och ethernets egen CRC32 (FCS).
Sådant som däremot kan ödelägga upplägget är tidsglitch mellan in/utmatning av enskilda bytes till bitströmmen. Och fasförskjutning över tid, dvs att takten på sändare och mottagar skiljer sig för mycket. Då "hacket" saknar PLL som det är.
Minimikraven torde se ut ungefär såhär:
* Bitrate på 10 Mbps/s utan glitch mellan varje byte.
* 10Base-T Länkpulser 100-200 ns utsänt varje 16 ms +/- 8 ms.
* ARP annonsering vid förfrågan och start
* IPv4 UDP, alternativt ICMP. Vilket kräver minimum 576 bytes minne.
* Jobbar man på endast på Ethernet nivå klarar man sig på en 64 bytes buffer och kan skippa ARP/IP/UDP. Nackdelen är att man måste använda "raw sockets" i administratörsläge.
Idén är inte att bygga en webbserver eller kritisk switchfunktion med routing
, vill minnas att RTL8019 chippen dessutom behöver 8-bit + kontroll signaler för att fungera. GPIO är alltid lättare att få tag på jämfört med ett nytt chip .. I ATmega 48/88/168 databladet för SPI på sid 168 står det att flaga+IRQ signalerar "färdig". Om man lite fräckt räknar på klockcycklerna borde det gå att läsa och skriva till det interna SRAM minnet samtidigt som SPI:n bitbangar. Och sedan fylla på med NOP så att skiftregistret fylls eller läses av i exakt rätt ögonblick utan att vänta på bekräftelse av den föregående 8-bit skiftningen. För få en jämn takt utan pulsförlängning i 8-bits skarvarna.
Minsta paket är 7+65 bytes. Som således får plats i det interna 512-1024 bytes SRAM:et.
Så något i stil med för en klocka 4x bitrate:
Läs SPI
Skriv SRAM #0
Nop
IN R16, SPDR ; SPI till register, 1 clk
ST X+, R16 ; register till SRAM(X) samt X=X+1, 2 clk
NOP ; 1 clk
osv..
.
.
Då 20 MHz är max så får man överklocka minst 2x ..
Hittade dock en intressant funktion: "USART in SPI mode":
Vid 20 MHz klocka och UBBRn=0 får man en bithastighet på 10 Mbit/s (sid 198).
Och det verkar som till skillnad från UART mode så kan man läsa in en bitström utan att vissa bitar tolkas som start/paritet/stop-bitar. Vilket skulle ge 16 klockcykler per byte att utföra instruktioner parallellt med sändning/mottagning. Därmed borde något liknande fungera:
IN R16, UDRn ; UART buffer till register, 1 clk
ST X+, R16 ; register till SRAM(X) samt X=X+1, 2 clk
NOP ; 1 clk
NOP ; 1 clk
(tills 16 klockcykler är utfyllda)
osv..
@TomasL,
* Handskakning, du tänker förmodligen på Autonegotiation men dess tillämplighet är specifierad till "However, its implementation was optional". Och att generera 100 ns pulserna går lätt med två st out-port instruktioner. Vill man ha FLP ligger den på 4 kbit/s.
* Timingen är främst beroende av skarven mellan in/utmatningen av efterföljande 8-bitars bytes.
* CSMA/CD är inte ett jättestort problem med switchade nätverk och full-duplex. Samt att nätverket har en viss tolerans, perfektion i denna implementation är inte absolut nödvändlig. Och det går att lyssna av linjen någorlunda.
* Riktar in mig på UDP, det protokollet kan hanteras enkelt. Och minimi kravet är endast 65 bytes samt CRC32. Vilket lätt går in i 512 bytes.
* RTL8019 kräver >8 st GPIO vad jag minns, ENC28J60 ha en tjock errata, och båda kräver inköp.
Om jag t.ex vill kunna ställa en klocka, styra en alfanumerisk display mm räcker det med ett paket "gör X" samt "uppfattat". Delmoment som kan bli jobbiga men knappast supersvåra är bitskiftning för byte alignment, CRC32 beräkning, hantering av ARP. UDP IPv4 är t.om utan checksumma så där klarar man sig med en färdig mall och ethernets egen CRC32 (FCS).
Sådant som däremot kan ödelägga upplägget är tidsglitch mellan in/utmatning av enskilda bytes till bitströmmen. Och fasförskjutning över tid, dvs att takten på sändare och mottagar skiljer sig för mycket. Då "hacket" saknar PLL som det är.
Minimikraven torde se ut ungefär såhär:
* Bitrate på 10 Mbps/s utan glitch mellan varje byte.
* 10Base-T Länkpulser 100-200 ns utsänt varje 16 ms +/- 8 ms.
* ARP annonsering vid förfrågan och start
* IPv4 UDP, alternativt ICMP. Vilket kräver minimum 576 bytes minne.
* Jobbar man på endast på Ethernet nivå klarar man sig på en 64 bytes buffer och kan skippa ARP/IP/UDP. Nackdelen är att man måste använda "raw sockets" i administratörsläge.
Idén är inte att bygga en webbserver eller kritisk switchfunktion med routing
Re: Ethernet bitbang med SPI?
Dagens nätverksutrustning kräver väl autoneg.
Jo RTLen kräver 8-bitar 3 adresslinor och tre (fyra) signaler med reset vill jag minnas, men enkel att jobba med och har inga errater.
Jo RTLen kräver 8-bitar 3 adresslinor och tre (fyra) signaler med reset vill jag minnas, men enkel att jobba med och har inga errater.
Re: Ethernet bitbang med SPI?
Kul idé. Jag tror absolut det är möjligt. Blir nästan lite sugen på att prova själv, fast på en lite fetare cpu =)
Något man måste tänka på är att ethernet klockan är extremt känslig för jitter.
Något man måste tänka på är att ethernet klockan är extremt känslig för jitter.
Re: Ethernet bitbang med SPI?
Checka http://www.fpga4fun.com. Finns lite info om att bitbanga ethernet/udp mha av en fpga. Kan kanske ge lite idéer.
Re: Ethernet bitbang med SPI?
Jag har redan bitbangat Ethernet (PHY) med FPGA. Utsatte en stackars Netgear 10/100 switch för allehanda elaka paket. Slutsatsen är att dom är rätt duktiga på att hålla rent
Tror t.om dom kontroll räknar CRC32 summan om jag minns det rätt.
Nåväl, utmaningen är att göra samma utan FPGA+PHY. För att t.ex kunna bygga en nätverkad programmerare till ett lågt pris. Är tillförlitlighet riktigt viktigt så köper man ett MAC+PHY chip förstås. Klockjitter är ett stort frågetecken dock, men en PC+NIC med "RUNT_FRAME" option satt underlättar betydligt för debug.
Någon som har lust att testa "UART in SPI mode" och mata på bytes till hastigheten 10 Mbits/s och se på oscilloskop med trigger hurvida byte skarvarna är okej? (utan bitstretch)
Nåväl, nu borde iaf teorin för hur man går till väga vara utredd..
Tror t.om dom kontroll räknar CRC32 summan om jag minns det rätt.
Nåväl, utmaningen är att göra samma utan FPGA+PHY. För att t.ex kunna bygga en nätverkad programmerare till ett lågt pris. Är tillförlitlighet riktigt viktigt så köper man ett MAC+PHY chip förstås. Klockjitter är ett stort frågetecken dock, men en PC+NIC med "RUNT_FRAME" option satt underlättar betydligt för debug.
Någon som har lust att testa "UART in SPI mode" och mata på bytes till hastigheten 10 Mbits/s och se på oscilloskop med trigger hurvida byte skarvarna är okej? (utan bitstretch)
Nåväl, nu borde iaf teorin för hur man går till väga vara utredd..
Re: Ethernet bitbang med SPI?
Du gav mig just en ide om ethernetanslutna sensorer, enbart transmit borde ju underlätta en hel del Om jag tar straffet för raw sockets så slipper jag arp också.
Om jag tar straffet för raw sockets så slipper jag arp också.
Re: Ethernet bitbang med SPI?
IgorPlug-UDP är enkelriktad bit-bangad UDP baserad på AVR, kanske kan vara intressant att titta på.
Re: Ethernet bitbang med SPI?
Om IgorPlug-UDP:
Har läst om Ethernet som bakplans överföring. Och där rekommenderades kondensatorer som ersättning för signaltransformatorn. Så R1, och R2 bör ses över. Alternativt så slänger man dit en signaltransformator från ett "frivilligt" donator NIC
Verkar som 20 MHz kristall är nödvändligt.
Verkar som att ingen signifikant byte glitch äger rum då projekter tydligen fungerar. Samt att om så är fallet borde det gå att ta emot också. Kanske mycket trasiga, paket. Fast skam den (MCU) som ger sig
Har läst om Ethernet som bakplans överföring. Och där rekommenderades kondensatorer som ersättning för signaltransformatorn. Så R1, och R2 bör ses över. Alternativt så slänger man dit en signaltransformator från ett "frivilligt" donator NIC
Verkar som 20 MHz kristall är nödvändligt.
Verkar som att ingen signifikant byte glitch äger rum då projekter tydligen fungerar. Samt att om så är fallet borde det gå att ta emot också. Kanske mycket trasiga, paket. Fast skam den (MCU) som ger sig
Re: Ethernet bitbang med SPI?
Ska nog kolla in igorplug, magnetics har jag sedan tidigare ickegenomförda projekt
Re: Ethernet bitbang med SPI?
Har funderat lite på hur man tar emot bitströmmar där sändarklockan ändrar sig under sändning. Och det faktum att bithastigheten är 10 Mbit/s medan maxfrekvens för ATmega är 20 MHz (välja annan CPU?). Om man använder SPI så klarar man sannolikt indatahastigheten. Problemet är att få något att klocka in det korrekt. För det skulle man kanske kunna använda en PLL som t.ex CD4046. Så att denna kan nyttja flankerna i Manchester signalen.
Ett alternativ är någon form av enkel kapacitans / induktans som ger signal vid 0,5 bittid respektive 1,5 bittid. Ideér om detta?
Ett alternativ är någon form av enkel kapacitans / induktans som ger signal vid 0,5 bittid respektive 1,5 bittid. Ideér om detta?
