OK Mégsem
Fórum témák

» Több friss téma
Fórum » ENC28J60 ETHERNET vezérlő használata
Lapozás: OK   17 / 17
(#) Sick-Bastard válasza Panhard hozzászólására (») Nov 10, 2014 /
 
Üdv!

E-mail küldése engem is érdekelne, de még nem próbáltam. Csak most lettem meg a http nagy részével(számomra szükséges).
Az SMTP Protocolról, működéséről, használatáról találtál anyagot/leírást?
(#) Mészy hozzászólása Feb 21, 2015 /
 
Üdv mindenkinek!

Nekem nem működik 255 feletti portszámokon az eszköz weboldalas elérése. Ping-re válaszol de nem tudom elérni webservert ami rajta van. Beállítom a portot de nem működik. Találkozott már valaki ilyen problémával?

Előre is köszönöm!
(#) lastewer hozzászólása Márc 25, 2015 /
 
Neked legalább válaszol a pingre , nekem semmire sem
(#) wincso hozzászólása Aug 16, 2017 /
 
Sziasztok!
Segítséget szeretnék kérni!
Szeretnék egy olyan áramkört építeni ,amivel interneten keresztül 1 relét lehet vezérelni . Mikroc-ben írt programot letöltöttem , prozeus-ba betöltöm , de nem működik , hívásakor weblap nem elérhető, és a küldő buffer túlcsordul , állandóan változó időközönként.
Ezzel próbálkozom
http://www.studentcompanion.co.za/web-based-control-and-monitoring-...ikroc/

Előre is köszi
(#) hotau hozzászólása Aug 21, 2017 /
 
Szép estét!
Abban szeretnék segítséget kérni, hogy hogy tudok UDP segítségével int vagy double típusú változó értékét kiküldeni, mert eddig csak karakter tömbnek az elemeit sikerült.
Eddig ezt a kódot próbáltam:

  1. #include <EtherCard.h>
  2. static byte mymac[] = { 0x74,0x69,0x69,0x2D,0x30,0x31 };
  3. static byte myip[] = { 192,168,0,180 };
  4. static byte gwip[] = { 192,168,0,254 };
  5.  
  6. byte Ethernet::buffer[500];
  7. static uint32_t timer;
  8.  
  9. const int dstPort PROGMEM = 80;
  10. const int srcPort PROGMEM = 80;
  11.  
  12. void setup () {
  13.   if (ether.begin(sizeof Ethernet::buffer, mymac) == 0)
  14.     Serial.println( "Failed to access Ethernet controller");
  15.    ether.staticSetup(myip, gwip);
  16.   ether.printIp("SRV: ", ether.hisip);
  17. }
  18. char textToSend[] = "test 123";
  19. void loop () {  
  20.     if (millis() > timer) {
  21.       timer = millis() + 5000;  
  22.      ether.sendUdp(textToSend, sizeof(textToSend), srcPort, ether.hisip, dstPort );  
  23.   }
  24. }



Gondoltam arra, hogy a karakter tömböt módosítom, int tömbre, de nem működött.
Gondoltam még arra is, hogy az int, típust konvertálom karakterré, amit belerakok a karakter tömbbe, de az se vált be.

Ha valaki tud, valami jó ötletet erre az írja, le legyen szíves.
A segítséget előre is köszönöm.
(#) koverg70 válasza hotau hozzászólására (») Aug 22, 2017 /
 
Szia!

Nem ismerem pontosan azt a könyvárat, amit használsz, de feltételezem, hogy a sendUdp egy byte tömböt küld el. A kérdésed, tehát nem is ENC28J60 specifikus, hanem inkább C nyelv és különböző típuok (karakter tömb, egész szám, lebegőpontos szám) ábrázolása az adott nyelven és az adott platformon. Igen sajnos ez processzor, illetve mikro vezérlő specifikus is.

Hogyan konvertáljunk egy int-et byte tömbre:
1. Első lehetőség, hogy vesszük az int változó címét a memóriában. Már önmagában ez is platform specifikus, mert nem mindegy, hogy a program memóriában, a heap-en (malloc-kal allokált), vagy a stack-en (lokális változó) van. Ha ettől most eltekintünk, akkor ezt így tudod megcsinálni:
int numToSend = 1234;
ether.sendUdp(&numToSend, ...)
Ha minden jól megy az & jelenti azt a címet, amelyen a numToSend változót tárolja a programod. A cím egyben egy byte tömböt is jelent.
Itt mindjárt álljunk is meg. Egyrészt attól függően, hogy 8/16 vagy 32 bites a processzot / mikro vezérlő más lesz az átküldendő int mérete: 2 vagy 4 byte. Ezért inkább ne is int-et, hanem WORD-ot vagy DWORD-öt küldj át. A WORD 16 bit, azaz 2 byte a DWORD 32 bit, azaz 4 byte.
Ha ezen túl vagyunk, akkor következik a tárolás módja. Van olyan CPU, amely a legkisebb helyiértékeket tárolja a végén (little-endian) és van amelyik a nagyobbakat (big-endian).
Arra jutottunk, hogy ha így csinálod, akkor platform függő leszel. Ha mondjuk két ATMEGA 328 között küldözgetsz, akkor akár jó is lehet, de ha a 64 bites PC-n Windows vagy Linux alatt nézed, akkor már ne.

2. Egy előbbinél jobb lehetőség, ha te definiálod a konverziót és mind a küldő, mint a vevő oldalon ugyanúgy alakítod ki. Küldésnél pl.:

unsigned char bytesToSend[4];
DWORD numToSend = 1234;

bytesToSend[0] = (numToSend >> 24) & 0xFF;
bytesToSend[1] = (numToSend >> 16) & 0xFF;
bytesToSend[2] = (numToSend >> 8) & 0xFF;
bytesToSend[3] = numToSend & 0xFF;

ether.sendUdp(bytesToSend, 4, ...)

Ha nem baj, akkor a double-re most nem is térnék ki, mert az még bonyolultabb.

Üdv: Gábor

u.i.: a stringgé konvertálás is megoldás lehet, ha nem számít, hogy nagyobb lesz a payload. Így legalább olvashatóbb lesz a hálózati forgalom. Akkor a konverzió valahogy így kell kinézzen

int intToSend = 1234;
char strToSend[12];
sprintf(strToSend, "%d", intToSend );
ether.sendUdp(strToSend, strlen(strToSend), ...)
A hozzászólás módosítva: Aug 22, 2017
(#) pipi válasza koverg70 hozzászólására (») Aug 23, 2017 /
 
Hali!
Megpróbálnám a double-t és a char tömböt egy @nion-ba tenni.
(A '@' helyére 'u' betűt érts, úgy tünik tiltott szó a forumon, ha szerepel a válasz hozzászólásban, akkor üresen jelenik meg a hozzászólás, linket sem tudtam beilleszteni)
A hozzászólás módosítva: Aug 23, 2017
(#) wincso válasza hotau hozzászólására (») Ápr 3, 2018 /
 
Szia!
https://libstock.mikroe.com on találsz webservert ami működik, reléket kapcsolgat
(#) wincso hozzászólása Ápr 3, 2018 /
 
Sziasztok!
Tudna valaki segíteni , van egy webszerverem ami pár relét kapcsolgat meg hőmérsékleteket mér!
a http GET kérésekre válaszol. de az url mezőben benn marad a legutolsó Get kéeés és frissítéskor mindig a legutolsó parancsot ismétli. Azt javasolták , próbáljak POST -kéréssel küldeni az adatokat, de ha behelyettesítem GET szűrés helyére a POST szűrést, akkor szerver hiba üzenet jön a böngészőből.
Mit ronthatok el?
(#) Sick-Bastard hozzászólása Dec 31, 2018 /
 
Üdv! (BÚÉK)

Leginkább babonából írom le a problémám, mivel már sokszor a hozzászólás leírása után jött az EUREKA pillanat... hátha most is.

Probléma:
Jó pár éve írtam egy saját könyvtárat az ENC28J60-hoz. Be akartam rakni egy projekthez, némi "fejlesztés", az új projekthez való illesztés után, de problémám akadt a csomagok fogadásával.

Úgy tapasztalom, hogy a csomagok hiányosan érkeznek meg, ami miatt borul az egész.
Az adatlap 43. old. 7-3-as ábra alapján a csomag első 6 byte-ja a next_packet_pointer(NPP) és a receive_status_vector(RSV), majd ezután jön maga az ethernet csomag, amit a crc zár.

Az RSV- első 2 byteja lenne az ethernet csomag mérete, amit már 0-0xFFFF-ig mindennek olvastam szóval tuti nem jó. Arra tippeltem, hogy ha 0xFFFF-ként olvasom be, az még akár az ethernet csomag destination address-e (broadcast) is lehetne, ami arra enged következtetni, hogy valamiért el/csúszok a buffer memory kiolvasása során... de hol/hogyan(hogyan lehetséges)?

Mellékeltem a könyvtárat(enc28j60_partial.h) amit írtam, csak annyira lecsupaszítva, hogy még érthető maradjon. Valamit rosszul állítok be az inicializálás során? Rossz a csomag fogadó funkció?

Jelenség a debug_report-ban található alapján:
83: packet cnt 0x01 <- jött egy csomag
93: Ethernet RXD Write Pointer: 0x46 <- NPP+RSV+ 36 byte csomag +CRC (elvieg)
95: NPP 0x1A0 <- a következő csomag a 0x01A0-tól kezdődik?

Ha a Write Pointer és a NPP nincs összhangban, akkor biztos nem jó...

Jelenség 2:
Adatlap 27. old. 4.2.1 READ CONTROL REGISTER COMMAND
4-3 és 4-4 ábrák
Az adatlap alapján ha az ETH egyik regiszterét szeretném kiolvasni, akkor elég hozzá 2 SPI csomag. Ha egy MAC vagy MII regisztert olvasok, akkor 3 SPI csomagot kell küldeni.
Ha ez így van akkor az EREVID regisztert miért csak 3 SPI csomaggal tudom kiolvasni? Ez nem az ETH regiszter csoportba tartozik?

enc28j60_par...h
enc28j60_deb...txt		   
(#) Sick-Bastard válasza Sick-Bastard hozzászólására (») Jan 2, 2019 /
 
Bővült a furcsa jelenségek sora:

Ha inicializálom az ENC-t és ERDPT = RXSTART(0x0000)-ra állítom be, de a az ECON1.RXEN bitet nem kapcsolom be, akkor is az ERDPT értéke valamiért folyton módosul (növekszik). Pedig nem hajtok végre RBM parancsot.

Ha ECON1.RXEN bit be van kapcsolva akkor meg az első beérkező csomag esetében:
ERXWRPT egyenlőnek kéne lennie RXSTART(0x0000)-al mégis az első byteokat(NPP, RSV) RXEND(0x0FFF) és 0x0FFE közé kezdi írni...

Hardware hibát azzal zártam ki, hogy 2db ENC modulom is van, amiket kipróbáltam a működő kóddal rendelkező AVR-el és abban minden jól megy (ARP, ICMP(ping), UDP).

bank setting...txt		    
(#) Sick-Bastard válasza Sick-Bastard hozzászólására (») Jan 11, 2019 /
 
A jelenség megfejtése:

A hibakereséshez használt for() ciklussal végzett ENC28J60 regiszter tömbjei (bank 0 - 3) kiolvasása okozta a jelenséget. Ha az egyik tömb 0x1A címen található "Reserved" regiszterét olvasod ki (és ECON2.AUTOINC bit be van kapcsolva), akkor ERDPT értéke 1-el növekedni fog. Ha ezt mind a 4 tömbben elvégzed, akkor az ERDPT 4-el fog növekedni.

Következtetés:
A tömbökben az 0x1A címen található "Reserved" regiszter lehetséges, hogy maga az EDATA regiszter, amit az adatlapon csak egyszer említenek:
16. old. 3.1.2 ECON2 Register
Idézet:
„bit 7 AUTOINC: Automatic Buffer Pointer Increment Enable bit
1 = Automatically increment ERDPT or EWRPT on reading from or writing to EDATA
0 = Do not automatically change ERDPT and EWRPT after the buffer is accessed”


Utalás arra, hogy ne végezz WR/RD műveletet ezen ezen a regiszteren:
12. old. 3.1 Control Register
Idézet:
„The register at address 1Ah in
each bank is reserved; read and write operations
should not be performed on this register. All other
reserved registers may be read, but their contents must
not be changed.”

... csak a miért ne maradt ki.
(#) wincso hozzászólása Ápr 4, 2019 /
 
Sziasztok!
A kérdésem az lenne , hogy enc28j60 pic18f4620-al , webserver tcp/ip vel , és ha 4 kb feletti html oldalt írok a pic be akkor nem tölti be az oldalt. lehet ennek oka az , hogy az enc buffer mérete 4kb, és ha igen , lehet valahogy feljebb tornászni a html oldal méretét, hogy be is töltődjön?
Köszönöm...
(#) superuser válasza wincso hozzászólására (») Ápr 4, 2019 / 1
 
A MCHP TCP/IP stack kezeli ha az oldal mérete nagyobb a buffer méreténél. Mondjuk a környezetről nem írtál semmit.
(#) wincso válasza superuser hozzászólására (») Ápr 21, 2019 /
 
A MikroC fordítót használok, és a mikroelektronika libstock oldaláról töltöttem le egy példa projektet és módosítottam, de a példa program html része kicsi volt , néhány bájt, 2 relét kezelt.
http://www.studentcompanion.co.za/web-based-control-and-monitoring-...ikroc/
(#) Sick-Bastard hozzászólása Aug 1, 2021 /
 
Üdv!

Egy kis segítségre lenne szükségem. Az ECN28J60-hoz irt könyvtáramat kezdtem el kiegészíteni, mégpedig IPv6-os protokollokkal. Ám első akadály a Receive Filter (Section 8.0) jó beállítása, AVR tehermentesítése. IPv4 esetében ez nem gond, elég volt csak az Unicast, Multicast és Broadcast csomagok továbbítása.

IPv6-hoz viszont, úgy tapasztaltam ez már nem elég. Átmeneti megoldásként a Pattern Match Filtert használom, ám ennek egy nagy hátránya van. Átengedi a Spanning Tree Procol-okat is, ill. mindent ami 64 byte-nál kisebb.

Szóval a Hash Table Filtert szerettem volna használni, de nem látom át, hogy hogyan is kéne nekem a CRC-ket kiszámolnom. Google csak annyiban segített, mármint összezavart, hogy a CRC-ből is kismillió verzió van.
A Hash Table csak 64 bites, és a leírt példa szerint, ha CRC = 0x05 akkor ellenőrzi, hogy a táblában az 5. bit be van e állítva, ha igen akkor igaz a feltétel és a csomag átmegy.

Szóval a lényeg, a chip milyen CRC szerint számol? Van valakinek kódja erre?

SB

enc28j60 - 8...jpg		    
(#) superuser válasza Sick-Bastard hozzászólására (») Aug 1, 2021 /
 
Csatolj be valami adatlapot, ami alapján el lehet indulni.
Amúgy gondolom egy RFC pontosan megadja, hogy milyen CRC algoritmus. Ezt kellene tudni, hogy melyik RFC.
(#) bbb válasza Sick-Bastard hozzászólására (») Aug 1, 2021 / 1
 
Az adatlap 5.1.7-es pontja szól a CRC-ről:
Idézet:
„5.1.7 CRC
The CRC field is a 4-byte field which contains an industry standard 32-bit CRC calculated with the data from the destination, source, type, data and padding fields.
When receiving packets, the ENC28J60 will check the CRC of each incoming packet. If ERXFCON.CRCEN is set, packets with invalid CRCs will automatically be discarded. If CRCEN is clear and the packet meets all other receive filtering criteria, the packet will be written into the receive buffer and the host controller will be able to determine if the CRC was valid by reading the receive status vector (see Section 7.2 “Receiving Packets”).
When transmitting packets, the ENC28J60 will automatically generate a valid CRC and transmit it if the MACON3.PADCFG<2:0> bits are configured to cause this. Otherwise, the host controller must generate the CRC and place it in the transmit buffer. Given the complexity of calculating a CRC, it is highly recommended that the PADCFG bits be configured such that the ENC28J60 will automatically generate the CRC field.”

Vagyis az IEEE 802.3 szabvány CRC32-jét használja, amiről mondjuk a Xilinx lapját olvasd el: Bővebben: Link
(#) Sick-Bastard válasza bbb hozzászólására (») Aug 2, 2021 / 2
 
superuser, bbb

Szóval megint bejött a "tervem". Megírom, hogy valamivel problémám van és mire "kiposztolom", meg is lesz a megoldás.

superuser:
Az ENC28J60 adatlapját a topic jellege miatt nem osztottam meg. Úgy gondoltam aki itt tud válaszolni, annak megvan az adatlap. Az adatlapot átnyálazva, a keresést használva, a következő kulcs szavakkal: CRC, polynomial, algorithm... nem találtam referenciát a a CRC típusára vagy algoritmusára.

bbb:
Valóban az adatlap 5.1.7-es pontja a CRC-ről szól, de ez, értelmezésem szerint, csak a küldött/fogadott csomagok után lévő 4 byte-os Frame Check Sequence - CRC -re vonatkozik (adatlap ábra 5-1).

Az 5.1.7-es pont említi is, hogy a CRC-t a "destination, source, type, data and padding fields"-ekből rakja össze, de itt is csak annyit ír, hogy "industry standard 32-bit CRC"-al számol.
A 8.4-es pont viszont csak a destination address 6 byteját használja.
Jó rendben, legyen a CRC algoritmus mindkét esetben ugyanaz, de akkor hogy lesz egy 32 bites CRC-ból 8 bites CRC?
Idézet:
„For example, if the CRC is calculated to be 0x5, bit 5 in the Hash Table will be checked.”


Nem hagyott nyugodni a dolog, így tovább googliztam.
Találtam is egy exe-re utalást itt Microchip Hash Table Filter Entry Calculator v1.01, ám a további keresésem maga a program után kudarc volt. Sehol sem találtam. Viszont így kaptam pár fontos infot a CRC-kel kapcsolatban. Ezek a Polynomial (0x04C11DB7), az initial value (0xFFFFFFFF) és egy CRC eredmény(0x6005A787) egy megadott MAC címhez(00:04:A3:11:22:33), a CRC számításhoz és az ezután kapott Hash érték (EHT0 = 0x01).
Valamivel előrébb jutottam, de ebből még így kód nem lesz.
Keresés tovább:
crccalc.com és egy oldalon talált C kód (az oldalt már nem találom) előrébb vitt.

FONTOS: A kódokat, a gyorsabb tesztelés miatt (re/compile>test>repeat), egy meglévő GUI-s programom, C# környezetben futtattam.
  1. public uint Compute_CRC32_Simple(byte[] bytes)
  2.         {
  3.             const uint polynomial = 0x04C11DB7; /* divisor is 32bit */
  4.             uint crc = 0xFFFFFFFF; /* CRC value is 32bit */
  5.  
  6.             foreach (byte b in bytes)
  7.             {
  8.                 crc ^= (uint)(b << 24); /* move byte into MSB of 32bit CRC */
  9.  
  10.                 for (int i = 0; i < 8; i++)
  11.                 {
  12.                     if ((crc & 0x80000000) != 0) /* test for MSB = bit 31 */
  13.                     {
  14.                         crc = (uint)((crc << 1) ^ polynomial);
  15.                     }
  16.                     else
  17.                     {
  18.                         crc <<= 1;
  19.                     }
  20.                 }
  21.             }
  22.            
  23.             return crc;
  24.         }


Ez a kód már olyan eredményt adott, ami a crccalc.com oldalon is szerepelt. A 0x0004a3112233 mac-re címre eredményül 0x738471E4-et adott, ami az oldalon CRC-32/MPEG-2 algoritmus-ként szerepel.
Sajnos ez az eredmény nem azonos a Microchip Hash Table Filter Entry Calculator oldalon található 0x6005A787-el... keresek tovább.

Jöjjön hát a szent grál:
Forrás
Ezzel kellett volna kezdenem, mármint a keresés irányát.

  1. UInt32 enc28j60CalcCrc(byte[] data, UInt16 length)
  2.          {
  3.             UInt16 i;
  4.             UInt16 j;
  5.             UInt32 crc;
  6.             byte[] p;
  7.  
  8.                 //Point to the data over which to calculate the CRC
  9.                 p = (byte[]) data;
  10.                 //CRC preset value
  11.                 crc = 0xFFFFFFFF;
  12.  
  13.             //Loop through data
  14.             for(i = 0; i<length; i++)
  15.             {
  16.                //The message is processed bit by bit
  17.                for(j = 0; j< 8; j++)
  18.                {
  19.                   //Update CRC value
  20.                   if((((crc >> 31) ^ (p[i] >> j)) & 0x01) != 0)
  21.                   {
  22.                      crc = (crc << 1) ^ 0x04C11DB7;
  23.                   }
  24.                   else
  25.                   {
  26.                      crc = crc << 1;
  27.                   }
  28.                }
  29.             }
  30.  
  31.             //Return CRC value
  32.             return crc;
  33.          }


Ez már jó.
Most már csak meg kell kapni a Hash Table értékeket:

  1. void enc28j60UpdateMacAddrFilter()
  2.         {
  3.             UInt16 i;
  4.             UInt16 k;
  5.             UInt32 crc;
  6.             byte[] hashTable = new byte[8] { 0,0,0,0,0,0,0,0};
  7.             byte[] mac_addresses = new byte[6] { 0x00, 0x04, 0xa3, 0x11, 0x22, 0x33 };
  8.             string temp_str = "";
  9.  
  10.             for (i = 0; i<1; i++)
  11.             {
  12.                 //Compute CRC over the current MAC address
  13.                 crc = enc28j60CalcCrc(mac_addresses, 6);
  14.                
  15.                 temp_str = "crc: " + crc.ToString("X08") + "\r\n";
  16.                 write_to_uart_screen(temp_str);
  17.  
  18.                 //Calculate the corresponding index in the table
  19.                 k = (UInt16)((crc >> 23) & 0x3F);
  20.  
  21.                 temp_str = "k: " + k.ToString("X04") + "\r\n";
  22.                 write_to_uart_screen(temp_str);
  23.  
  24.                 //Update hash table contents
  25.                 hashTable[k / 8] |= (byte)(1 << (k % 8));
  26.  
  27.                 temp_str = "hashTable[k / 8]: " + hashTable[k / 8].ToString("X02") + "\r\n";
  28.                 write_to_uart_screen(temp_str);
  29.             }
  30.         }

A write_to_uart_screen(string) csak egy flancos foo(), amivel Invoke segítségével több szálon futó kódok is tudnak az UART_Screen (Rich Text Box)-ba írni, anélkül hogy a kódom összeomlana.

Mellékeltem is egy screenshot-ot az eredményről.

Konklúzió:
Google olykor ellenség, olykor barát.
Az ENC28J60-as adatlapban ettől függetlenül nem találtam a CRC-re a megoldást.

HashTableFil...png
mac crc and ...png		   
(#) bbb válasza Sick-Bastard hozzászólására (») Aug 2, 2021 /
 
Nekem nincs birtokomban ilyen IC, csak szemezgettem vele mostanában. SNMP-t tudó kütyüt alkotnék vele, ami csak egy szenzor értékét tudja visszaadni. Persze ehhez rá kéne szánnom magam, hogy játsszak vele
(#) pipi válasza bbb hozzászólására (») Aug 2, 2021 /
 
Hali!
Én nem fejvesztenék már ezzel az ENC28-al.Egyszer próbálkoztam, de nagyon lassúnak tűnt ez a 10Mbit, arról nem is beszélve hogy több switch/router már nem is támogatja. Akkor enc624+pic32 lett a megoldás.
Esetleg ha találsz kész konkrét cuccot, amit csak össze kell dobni, kész szoftverrel.
Ma inkább esp8266 vagy esp32-vel indulnék neki új fejlesztésnek, Arduinó alatt rengeteg mintát találni, könnyebb fejleszteni. Ha mindenképp drótos kell akkor az esp32-höz lehet kész lan8720 modulkát illeszteni...
(#) bbb válasza pipi hozzászólására (») Aug 2, 2021 /
 
Köszi!

Mindenképp "drótost" szeretnék, ha majd nekilátok, már csak azért is, hogy POE lehessen. A 10Mbit nem lenne gond, mert jóformán csak SNMP üzeneteket váltanék vele.
Ha egyszer nekilátok, akkor úgy is körül nézek merre érdemes elindulni.
(#) pipi válasza bbb hozzászólására (») Aug 2, 2021 /
 
Valamikor még volt az Olimexnek hazai szállítója, nem is messze tőlem. Akkor vettem ott pic32 panelt, és abba bedugható enc624-es modulkát. Ma már ezeket nem valószínű hogy el tudnám érni. Ugyanezt a projektet megcsináltam ugyanazzal a pic32-vel és az ali-ról vásárolt lan8720 modullal próbából, ha esetleg az ügyfélnek kell még a régi projekt-hez.
(#) Sick-Bastard hozzászólása Aug 4, 2021 / 1
 
Üdv!

Szerintem sikerült. Megvannak a szükséges Hash Table adatok.
Lecseréltem a Pattern Match Filtert a Hash Tabel Filterre és a kívánt csomagok átjönnek, de a nemkívánatosak (STP) nem jönnek át.

Ezen felbuzdulva összedobtam egy Hash Table Filter Entry Calculator-t. Amolyan Upgrade verzió, ha szabad így fogalmaznom...

Hátha egyszer valakinek még jól jön.

SB

Microchip Ha...rar
Hash Table C...jpg		   
(#) Sick-Bastard válasza pipi hozzászólására (») Aug 4, 2021 /
 
Üdv!

Azzal egyetértek, hogy a 10Mbites Ethernet kompatibilitás kezd kihalni az újabb Switchek/Routerekből, de attól még rengeteg ilyen eszköz marad a használt piacon. Nekem még az összes támogatja, sőt van olyan is ami az 1000-est nem támogatja.

A lassú résszel már nem teljesen értek egyet. Ez már relatív, ami erősen függ a társ uC-től. Esetemnél maradva, az AVR-nél, SPI-n keresztül 16Mhz-en max 8Mbit (sem) érhető el. Szóval a 10Mbps több mint elég egy 8bites uC-nek.

Ha programomban kikapcsolom a debug funkciókat (adatok UART dump, megszakítást használva 500kBaud-on), akkor 1-3ms-es pingeket kapok, ami debuggal 100-200ms.

Én is igazából az elmélet POE lehetőség miatt maradtam ennél. Ezt úgy értem, hogy még csak DIP IC-ket tudok forrasztani és erre az IC-re kezdtem el POE képes modult tervezni. Persze időközben rájöttem, hogy nem is olyan könnyű, meg egy POE képes RJ45 jack sem olcsó. Lehet az lesz a vége, hogy egy passzív poe splitter-el oldom meg a tápellátást. Bár lehet nem minden splitter alkalmas 48V továbbítására (48V-os POE Switchem van).

SB
Ezekre szükség lehet! - HESTORE.HU

ENC28J60-I/SO
PIC18F4620-I/P
LAN8720AI-CP
RJ45 CAT5e 1xWall-F
PIC32MX764F128H-I/PT
Következő: »»   17 / 17
Bejelentkezés

Belépés
Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem