mało pamięci rtl8019as i atmega8535

Witam.

Piszę taki prosty serwerek www, ze swoim stosem tcp. Zaimplementowałem arp, icmp, i mały serwerek www.

Wszystko pięknie działa tyko ten serwerk www jest mocno okrojony. Problem mam z brakiem pamięci programu w atmega8535. Napisałem kika prościutkich stronek, formularzy i w czystym html które przechowuję w pamięci programu i ta szybciutko się wyczerpała. Pokombinowałem trochę na zmiennych JavaScript, ale parę liniek i zaraz znowu koniec.

Czy macie jakiś sposób na lepsze "upakowanie" stronki w mikrokontrolerze? A może atmega8535 to za mało na taki serwerek ?

Dziękuję za pomoc Pozdrawiam Paweł

Reply to
invalid unparseable
Loading thread data ...

Mogę tylko chodzi raczej o minimalizaję kosztów a co za tym idzie układu. Jeżeli iść tą drogą to równie dobrze mogę użyć do tego jakiejś większej atmegi.

Pozdrawiam Paweł

Reply to
invalid unparseable

Paweł - where do you want to go today ?

A nie możesz stron trzymać w pamięci zewnętrznej?

Sławek

Reply to
Sławomir Szczyrba

no coz - jak brakuje pamieci to uzyj wiekszego procka.

A co na tych stronkach jest ? bo upakowac mozna stosunkowo latwo - zrob slownik, zapamietasz 1 bajt np 81h, a przeslesz do karty " wykres", czy "<title>"

J.

Reply to
J.F.

Podlaczenie zewnetrznego szeregowego EEPROMu nie zwiekszy ci istotnie kosztow, a doda ci sporo miejsca. Ew. trzymaj stronki w pamieci FLASH procka, o ile ci jeszcze zostalo troche. Ten procek chyba ma instrukcje LPM ?

Reply to
T.M.F.

No właśnie trzymam te stronki w pamięci programu. Z tym że sama obsługa arp, icmp, ip, tcp bez htmli zajmuje 77% flasha. czyli jakieś 6,3kB (i to jeszcze nie skończone). Na html zostaje około 1,8kB. Ale już np. taka krótka linijka <FRAME SCROLLING=auto NAME=main SRC=start.html>

zajmuje 47 bajtów, to niech takich linijek mogę mieć powiedzmy 40 to i tak co to jest. Chyba rzeczywiście nie ma co się wygłupiać i wziąść większego procka.

Dzięki Pozdrawiam Paweł

Reply to
invalid unparseable

Przy czym wiekszy proc niekoniecznie rozwiaze twoj problem. Taka ATMega128 ma tylko 128kB, a byle jaki szeregowy EEPROM, ktor zajmnie ci

2 linie IO procka moze miec 64kB do kilku MB. Wiec na twoim miejscu poszedlbym raczej w tym kierunku. Nie wspominajac juz o wykorzystaniu jakiejs karty typu RS-MMC, gdzie za niecale 150zl masz nawet 512 MB.
Reply to
T.M.F.

Mój problem rozwiąże już atmega6 z 16K flasha, chyba będzie w sam raz. Nie jest to skomplikowane urządzenie i prawie udało mi się zmieścić to w

8K. Myślałem że może jednak da się to jakoś zrobić. Mógłbym zrobić konfigurację urządzenia po UDP a nie TCP ale musiałbym pisać dodatkowy program obsługi na peceta, a przeglądarka jednak jest na wszystkich systemach.

Paweł

Reply to
invalid unparseable

J.F. napisał(a):

Można. Tylko po co ? Kostka 4MB flash kosztuje parę złotych , a napisanie takiej procedury do pakowania i rozpakowania nie tylko zajmie czas ale będzie niewygodne przy ew. zmianie strony bo przecież coś musi tę stronę pakować ( pewnie jakiś kawałek napisany na PC ). Poza tym algorytm , który proponujesz jest wybitnie nieefektywny, bo sam słownik może wyjść bardzo duży. Lepiej jakiś typowy bezstratny algortym kompresji użyć ( są gotowce ).

Reply to
"Miłosz K."

Bez obrazy dla autora tekstu . Można kupić atmega 128 i to powinno rozwiązać cały problem . Mnie by było szkoda mojego cennego czasu za parę złotych .

Pozdrawiam

Reply to
UsUn_To_:-

Przyznaje sporo racji. Ale szeregowa ? Wygospodarowanie magistrali troche kosztuje, choc polowe juz chyba ma do rtl.

I tak ktos strone na pececie przygotuje i przesle.

Ale za to prosty :-)

Przyznaje ze efektywnosc moze byc kiepska. Duzo zalezy jakie to strony i co mu sie czesto powtarza. "<title>" to moze byc kiepski przyklad jak ma np dwie strony czyli az dwa razy uzyte.

Hm - na ile sie orientuje to tez wymagaja slownika. W tym przypadku slownik dobrany do charakteru stron bedzie efektywniejszy.

J.

Reply to
J.F.

J.F. napisał(a):

może LZO?

w.

Reply to
Wojtek Kaniewski

Doczep 8-pinową pamięć DataFlash, np. AT45DB041B. Kosztuje niecałe 9 zł:

formatting link
512 kilobajtów pojemności a to wystarczy na dużą stronę z wieloma obrazkami. Podłączenie banalne szeregową magistralą SPI.

Reply to
Adam Dybkowski

Nie używaj ramek:) A tak na serio: "użyj zewnętrznej pamięci" napisali Ci już inni, więc nie bedę powtarzać. Natomiast o czym nikt nie wspomniał to to, że warto zwrócić baczną uwagę na kod htlmowy.

- Generatory/edytory stron potrafia wpakować w niego sporo śmiecia, który ma minimalny wpływ na działanie strony. Htmltidy potrafi zdziałać w takim przypadku cuda.

- Jeśli masz większą liczbę stron o zbliżonym wyglądzie, wywal wszelkie formatowanie z htmla do zewnetrznego arkusza stylów css. Pozbędziesz się w ten sposób formatowania, definicji czcionek, kolorow itp z samego htmla, pozostanie czysty opis struktury dokumentu. Opis formatowania i wygladu elementow na stronie będzie w dodatkowym pliku dołączonym do strony. Ten sam arkusz css możesz wykorzystać z wieloma stronami, możesz nawet ściągać go z innego serwera (jeśli taka możliwość wchodzi w grę).

- Jeśli strony mają wspólny nagłówek/stopkę, części wspólne zapisz w pamięci oddzielnie i dopiero podczas wysyłki łącz z fragmentami indywidualnymi dla stron. Zgaduję że podobny efekt chcesz osiągnąć przy pomocy ramek.

- Znaki białe zwykle jedynie poprawiają czytelność kodu. Przeglądarce jest wszystko jedno czy dostanie strone w postaci jednej długiej linijki, czy ładnie powcinany i sformatowany kod. Wywal zbedne spacje, tabulatory i znaki końca linii.

- No i wreszcie... HTTP 1.1 obsługuje kompresję gzip. Wrzuć do pamięci skompresowany html i w takiej postaci go wysyłaj.

- Skonfiguruj poprawnie polskie ogonki w Outlooku :) (Kilka pomocnych linków:

formatting link
pzdr. j.

Reply to
Jacek R. Radzikowski

Nie ma lekko. To przegladarka zglasza serwerowi, ze "umie" kompresje. W przeciwnym wypadku serwer ma obowiazek nie stosowac kompresji. Trzeba by trzymac dwie wersje strony czyli jeszcze bardziej pamieciozerne rozwiazanie (skracajace tylko transfer).

Reply to
Adam Dybkowski

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.