On 09.01.2014 20:03, Atlantis wrote:

> Tak swoją drogą mam jeszcze jedno pytanie. Jak to jest z wartością
> rezystora na pinie RBIAS? On jest w jakiś sposób krytyczny? Spotykałem
> się z jednym schematem, gdzie były wprost podane, że musi to być
> rezystor o dość nietypowej wartości 2,31k w wersji 1%.
> Na innych schematach widywałem w tym miejscu rozmaite rezystory pomiędzy
> 2k i 2,7k.
>
> W swojej płytce wlutowałem rezystor 2,7k w wersji 5% (obudowa 0603). Czy
> to może mieć jakiś negatywny wpływ na stabilność pracy układu, szybkość
> transmisji albo ilość błędów?
>

Strona 6 dokumentacji: "Must be tied to VSSRX through a 2 k?, 1%
resistor." To samo powtórzone na stronie 9, z dopiskiem, że wymaga tego
"internal analog circuitry".
Generalnie ustalasz tym rezystorem prąd podmagnesowania uzwojeń
transformatora, a od tego prądu zależy ich indukcyjność. Np. w tabelce
16.5 na stronie 88, tam podają że indukcyjność powinna być minimum 350uH
przy biasie 8mA. Więc trzeba jeszcze zajrzeć do noty transformatorka. W
ramach badań możesz sprawdzić stopę błędów w zależności od dopasowania
impedancyjnego (przy rezystorku 2k i 2k7).

--
Pozdrawiam
Jakub Rakus

do góry

W dniu 2014-01-09 20:54, Jakub Rakus pisze:

> Generalnie ustalasz tym rezystorem prąd podmagnesowania uzwojeń
> transformatora, a od tego prądu zależy ich indukcyjność. Np. w tabelce
> 16.5 na stronie 88, tam podają że indukcyjność powinna być minimum 350uH
> przy biasie 8mA. Więc trzeba jeszcze zajrzeć do noty transformatorka. W
> ramach badań możesz sprawdzić stopę błędów w zależności od dopasowania
> impedancyjnego (przy rezystorku 2k i 2k7).

No to już (prawie) wszystko jasne. W nocie gniazdka z transformatorkiem
mam podane, że rezystory przy trafo powinny mieć 49,9 oma 1% (takie
udało mi się dostać w wersji 1206) a ten na pinie RBIAS ma mieć 2,32k 1%
(dało mi się taki dostać, ale już po wykonaniu płytki i w wersji
przewlekanej).

To ma duże znaczenie? Bo jeśli tak, to najwyżej wykonam drugą wersję
płytki, z myślą o posiadanych elementach.

I jeszcze jedno pytanie przyszło mi do głowy. VCC powinienem podciągnąć
do dławika zasilającego gniazdko RJ45 osobną linią, bezpośrednio ze
stabilizatora? W tej chwili jest podłączony do tej samej "żyły", która
zasila ENC. Jednak zastanawiam się czy to nie powoduje/nie będzie
powodowało jakichś problemów. Może tak zostać?

do góry

A jak tam test prędkości, porzrzuciłeś temat...?

--
Marek

do góry

W dniu 2014-01-09 21:25, Marek pisze:

> A jak tam test prędkości, porzrzuciłeś temat...?

Nie. Po prostu w ciągu ostatnich dni praktycznie nie było mnie w domu, a
gdy już byłem, to nie miałem nawet siły na odpalenie Atmel Studio. ;)

Tylko tak się zastanawiam... W opisie stosu była chyba mowa o tym, że
generowana strona musi się mieścić w jednym pakiecie. Wcześniej
wspominałeś, że trzeba przesłać większą ilość danych, żeby test był
wiarygodny. To ograniczenie nie będzie tutaj problemem?

do góry

On Thu, 09 Jan 2014 21:34:27 +0100, Atlantis <m...@w...pl>
wrote:
> Nie. Po prostu w ciągu ostatnich dni praktycznie nie było mnie w
domu, a
> gdy już byłem, to nie miałem nawet siły na odpalenie Atmel Studio.
;)




> Tylko tak się zastanawiam... W opisie stosu była chyba mowa o tym,
że
> generowana strona musi się mieścić w jednym pakiecie. Wcześniej
> wspominałeś, że trzeba przesłać większą ilość danych, żeby test był
> wiarygodny. To ograniczenie nie będzie tutaj problemem?

A to dziwne, nie czytałem dokładnie ograniczeń tej bib, może chodzi o
mały mtu w tym stosie i brak wsparcia dla fragmentacji? Ale to by
tylko limitowało wielkość bufora przy wysłaniu, natomiast nie
ograniczołoby "kontynuację" wysyłania mniejszymi "porcjami" danych.
Jak wygląda wysyłanie danych, jest w ogóle jakaś odpowiednik funkcji
send(socket, buf,buflen)?

--
Marek

do góry

W dniu 2014-01-10 01:02, Marek pisze:

> Jak wygląda wysyłanie danych, jest w ogóle jakaś odpowiednik funkcji
> send(socket, buf,buflen)?

Może to ja coś pokręciłem, dopiero zaczynam zabawę z tym tematem. Z tego
co widzę w przykładzie, to wysyłanie odpowiedzi polega na tworzeni
zawartości bufora, np. funkcją jak poniżej:

uint16_t print_webpage(uint8_t *buf)
{
uint16_t plen;
plen=http200ok();
plen=fill_tcp_data_p(buf,plen,PSTR("<pre>"));
plen=fill_tcp_data_p(buf,plen,PSTR("Hi!\nYour web server works
great."));
plen=fill_tcp_data_p(buf,plen,PSTR("</pre>\n"));
return(plen);
}

Potem następuje wywołanie funkcji www_server_reply(buf,dat_p).

Funkcjonalności klienta jeszcze nie przerabiałem.

do góry

On Fri, 10 Jan 2014 06:51:16 +0100, Atlantis <m...@w...pl>
wrote:
> zawartości bufora, np. funkcją jak poniżej:

Oj oj nie wygląda to mi na funkcjonalny stos tylko na "hack"
wysyłający preformatowany pakiet :(.

--
Marek

do góry

W dniu 2014-01-10 09:40, Marek pisze:

> Oj oj nie wygląda to mi na funkcjonalny stos tylko na "hack" wysyłający
> preformatowany pakiet :(.

Kwestia nazewnictwa. ;)
Ten stos ma mocno ograniczoną funkcjonalność i zdaję sobie z tego
sprawę. Za to można za jego pomocą realizować funkcjonalne urządzenia na
tak małych MCU jak ATMega88.
Jednak źle chyba nie jest, skoro z tego co widzę biblioteka daje
możliwość obsługi DHCP i DNS. Może rzecz o którą pytałeś gdzieś tam
jest, ja po prostu dopiero zacząłem wgłębiać się w ten temat. Podałem
fragment kodu odpowiedzialny za wysyłanie danych składających się na
stronę w przykładzie, który wgrałem.

Do moich zastosowań ta biblioteka jak na razie wystarczy, bo w chwili
obecnej zależy mi na przesyłaniu danych ze stacji pogodowej w
zapytaniach HTTP. Dzięki temu nie będę musiał budować magistrali RS485
albo CAN. Domowy LAN już istnieje. :)

Gdy stwierdzę, że ta biblioteka jest za ciasna, po prostu wypróbuję uIP.
Z tego co widzę jest kompatybilna z płytkami prototypowymi z
TuxGraphics, będzie więc i z moją.

W5100 na dobrą sprawę też chętnie bym kiedyś przetestował w jakimś
własnym układzie z Atmegą, jednak lutowanie tego LQFP trochę mnie
przeraża... No i nie wiem czy taka płytka jest jeszcze w zasięgu
termotransferu...

do góry