atarionline.pl #FujiNet - karta sieciowa SIO dla Atari 8-Bit. - Forum Atarum

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

  • :
  • :

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

    • 1: CommentAuthorsun
    • CommentTime16 Jun 2020
     
    @bocianu: czyli co? Czekamy na ntp dla Sparty? :)
    • 2:
       
      CommentAuthorbocianu
    • CommentTime16 Jun 2020
     
    @sun: no już wszystko co potrzebne jest - wystarczy napisać :D
  1.  
    Mamy już klienta NTP wbudowanego w FujiNet. Używa protokołu APETIME, więc jeśli uruchomisz APETIME, zsynchronizuje się on z NTP.
  2.  
    Oscar Fowler (@jamm) ciężko pracował refaktoryzując firmware #FujiNet, usuwając połączenia do biblioteki Arduino i zastępując je połączeniami do ramki ESP-IDF. Ostatecznie będzie to oznaczać krótszy czas uruchamiania systemu i bardziej efektywne wykorzystanie zasobów w ESP32.
    Dlaczego to robimy?
    Początkowo, gdy rozpoczynaliśmy ten projekt, każdy pojedynczy element był napisany jako całkowicie autonomiczny szkic Arduino, jeden szkic dla każdego elementu, który chcieliśmy przetestować. To w końcu pozwoliło nam szybko sprawdzić, czy to, co robiliśmy, było wykonalne. Szybko zebraliśmy prawie czterdzieści szkiców testowych w ciągu dwóch miesięcy. Arduino pozwoliło nam skoncentrować się na wdrożeniu wystarczającej ilości logiki, aby była to dowolna liczba urządzeń peryferyjnych SIO, a także zapewniło bogactwo klas i funkcji, których nie musieliśmy wdrażać.
    Tymczasem Jeff Piepmeier (@jeffpiep) uznał, że do budowy firmware'u produkcyjnego należy wykorzystać PLATFORM.IO. Przypadek ten opierał się na kilku bardzo solidnych podstawach, a mianowicie na tym, że znacznie łatwiej było rozłożyć różne bity kodu na osobne biblioteki i wykorzystać je z głównego kodu. Dostarczył on również bardzo ładny edytor w postaci VS.CODE, który jest naprawdę miłym ulepszeniem w stosunku do edytora Arduino zarówno pod względem użyteczności jak i skalowalności. Jeff był w stanie wykonać swoją pierwszą pracę nad emulacją drukarki w PLATFORM.IO. Zaczął też pracować nad tym, aby wziąć pracę, która zaczęła się układać pod szkicem Multilatora, i podzielić ją na ładne klasy C++ rozłożone na kilka bibliotek, a także zaimplementować wirtualną magistralę SIO, której potrzebowaliśmy w głównym kodzie, aby połączyć wszystkie te różne urządzenia wirtualne razem. Do końca stycznia wszystkie prace nad Multilatorem ześlizgnęły się do miękkiego lądowania, a my przenieśliśmy się w całości do bazy kodowej PLATFORM.IO.
    To było wspaniałe zobaczyć D: R: i P: urządzenia pracujące razem pod jednym dachem. Z powodu całej ciężkiej pracy wszystkich zaangażowanych, wszystko to zebrało się w całość i zadziałało prawie całkowicie za pierwszym razem, z pluskwami wypracowanymi w ciągu następnych kilku tygodni, a do lutego, zacząłem pracować nad pierwszymi kawałkami tego, co stanie się urządzeniem N:.
    Jeff znalazł również czas, aby zakraść się do syntezatora mowy SAM. Znalazłem port SAM do C jakiś czas temu i zapamiętałem go, przekazałem Jeffowi, a w pewien weekend w marcu #FujiNet zaczął mówić.
    Tymczasem w marcu otrzymaliśmy bardzo potrzebną pomoc od Ricka Lopeza aka 8bitandmore, który zbudował FujiNet na podstawie schematów i zaczął ulepszać i zmieniać R: urządzenie, aby działało jeszcze lepiej, naprawiając błędy.
    I otrzymaliśmy specjalną niespodziankę od Marcina Sochackiego (@TheMontezuma), który również zbudował ESP32 na płycie chlebowej i wsparł SIO2BT!
    W miarę zbliżania się marca, powoli zacząłem wykuwać więcej z urządzenia N:, w postaci adapterów protokołu TCP i UDP. Ponieważ zaimplementowałem firmware dla tej części systemu, napisano serię programów testowych, które rozmawiały z #FujiNet przez SIO, aby zweryfikować niskopoziomowe działanie różnych części kodu, które N: handler będzie ostatecznie używał. Zminimalizowało to liczbę punktów debugowania do jednego, a nie dwóch, a funkcje sieciowe zaczęły spadać.
    W międzyczasie, w kwietniu, zaczęliśmy dostrzegać pomoc i wkład Oscara Fowlera (@jamm), który zaczął przeszukiwać kod i powoli poprawiać go, czyniąc go lepszym.
    Zaczęliśmy w maju z nową wersją sprzętową, która naprawiła pewne problemy, które omówię poniżej, i zacząłem pracować nad rozszerzeniem N: do obsługi sieciowych systemów plików na poziomie plików.
    W miarę rozwoju tej funkcjonalności, zaczęliśmy mieć problemy:
    * Emulacja druku ssała RAM. Również 320K na ESP32, do którego przenieśliśmy się, ponieważ zabrakło nam 80K dostępnego barana na ESP8266, było wyczerpane, powodując zderzenia i problemy ze stabilnością. Do zbudowania pliku PDF potrzeba dużo pamięci RAM! Problem ten został rozwiązany poprzez kolejną zmianę sprzętu, która zwiększyła pamięć RAM do maksimum dostępnego dla ESP32 (8 megabajtów PSRAM).
    * Emulacja Bluetooth zabierała nie tylko cenną pamięć RAM, ale także przestrzeń flash. Poprawka miała na celu nie tylko zwiększenie pamięci RAM, jak to zrobiliśmy powyżej, ale także zwiększenie ilości pamięci flash do maksimum (16 megabajtów).


    * W miarę jak wiązaliśmy wszystko razem, stawało się jasne, że czas rozruchu znacznie się wydłużył, ze względu na dużą ilość wymaganej inicjalizacji. Sytuację pogarszał czas potrzebny do przetestowania PSRAM. Podczas gdy cała inicjalizacja miała miejsce, FujiNet nie mógł odpowiedzieć na nic z Atari w tym czasie, a co ważniejsze, nie mógł się uruchomić. Stało się jasne, że potrzebna jest drobniejsza kontrola nad procesem inicjalizacji, aby nie tylko skrócić czas inicjalizacji, ale także precyzyjnie określić priorytety i odłożyć na później aspekty inicjalizacji, aby wychować na tyle dużo urządzenia, aby mogło ono przynajmniej reagować na uruchomienie programu CONFIG, podczas gdy reszta urządzenia mogła inicjować w tle.
    * Szeregowe procedury I/O, które ostatecznie wysyłają i odbierają ruch SIO, nie są tak wydajne, jak mogłyby być. Czas na SIO jest absolutnie krytyczny, z oczekiwanym czasem odpowiedzi w mikrosekundach dla takich rzeczy jak potwierdzenie (ACK), a buforowana natura UARTów oznaczała, że musieliśmy przepłukać UART, aby upewnić się, że rzeczy takie jak pakiety potwierdzenia (ACK) zostały wysłane na czas, oznaczało to, że dalsza transmisja danych będzie opóźniona o kilka milisekund, i chociaż nie jest to szkodliwe, oznacza to, że można to zrobić szybciej, ale tylko wtedy, gdy będziemy bezpośrednio kontrolować sprzęt.
    Oprócz frameworka Arduino (oraz frameworków takich jak Pumbaa i Simbaa, które umożliwiają używanie innych języków, takich jak Python i Lua, do pisania kodu), PLATFORM.IO oferuje możliwość budowania i zarządzania projektami napisanymi dla frameworka ESP-IDF, który jest frameworkiem dostawcy dostarczanym przez Espressif do tworzenia oprogramowania C i C++ na projektach ESP32. Duża część klas Arduino jest w rzeczywistości wdrażana jako owijki wokół ESP-IDF i ta niepotrzebna owijka może być usunięta.
    Ponadto, wiele elastycznych opcji dostępnych w ESP-IDF (takich jak określenie większej liczby dozwolonych połączeń TCP, ustawienie wielkości bufora, zmiana sposobu uruchamiania i inicjalizacji, itp.), po prostu nie jest dostępnych w Arduino API, musimy się do nich bezpośrednio dostać. Nie wspominając już o tym, że wersja ESP-IDF obecna obecnie w opublikowanym frameworku Arduino jest starsza od najnowszej wersji tego frameworka, która została wydana przez Espressif, a która naprawia szereg błędów, na które natknęliśmy się podczas tworzenia tego oprogramowania, z których najbardziej znanym był domyślny rozmiar nagłówka POST dla transakcji HTTP, który uniemożliwiał naszemu administratorowi sieci poprawną pracę z przeglądarką Chrome.
    Więc Oscar zaczął brać, zrywając zależności od Arduino.h, i z każdym błędem, który się zdarzył, napisał równoważne funkcje i klasy, aby zastąpić funkcje utracone z Arduino, wzywając do ESP-IDF w razie potrzeby. Był to bardzo powolny proces, wymagający przejścia przez całą bazę kodową (ponieważ każdy z nas aktywnie pracował nad kodem!) i ukradkiem zastąpienia wywołań Arduino przez fnSystem, i tak dalej, wywołań.
    Oscar dotarł do punktu, w którym kod został gruntownie zawiązany w naszych nowych bibliotekach, a funkcjonalność działała zgodnie z oczekiwaniami, więc zdecydował się stworzyć nowy projekt w ramach katalogu platformowego o nazwie FujiNet_idf, który był projektem łączącym tylko framework ESP-IDF, a nie łączącym Arduino, w ogóle. Po około tygodniu pracy, kod został skompilowany, a dwa dni później uruchomił swój pierwszy dysk. Ciężka praca w infrastrukturze w celu pozbycia się zależności od Arduino opłaciła się, a ilość działającej funkcjonalności po pierwszej udanej budowie zaskoczyła nas wszystkich, na pewno.
    Więc co dalej?
    Zabieram kilka tygodni, żeby się zrelaksować, podczas gdy Oscar kontynuuje debugowanie i poprawianie kodu w wersji ESP-IDF, w celu osiągnięcia parytetu funkcjonalności z obecną wersją produkcyjną. Największym problemem jest obecnie radzenie sobie z przerwami na wyjściu szeregowym przy dużych prędkościach. Podejrzewamy problem czasowy, który musimy rozwiązać (teraz, gdy jesteśmy jedną warstwą bliżej gołego metalu) i mamy nadzieję, że zostanie on szybko rozwiązany.
    Teraz, gdy @Mozzwald oficjalnie wykonał wstępny test produkcyjny w ilości 50 jednostek, nacisk jest na to, aby zapiąć to, co mamy, aby przygotować się do założenia tych jednostek produkcyjnych. Będzie to dokładnie to, co mamy z różnych urządzeń peryferyjnych D, P, R i N, jak również SAM, z naciskiem na naprawianie błędów w CONFIG (w czym pomaga Rick aka 8bitandmore), i będziemy tworzyć płynny sposób na uaktualnienie firmware'u FujiNet, ponieważ więcej funkcjonalności w tym roku i dalej.
    W oczekiwaniu na dostarczenie tych początkowych 50 jednostek testowych zacząłem pisać plan testów pełen procedur testowych, które nie tylko służą do walidacji, ale także do instruowania funkcjonalności #FujiNet.
    Chcę podziękować wszystkim, którzy przyczynili się do powstania tego projektu... krwi, potu i łez. To dzięki nam wszystkim mamy jedno z największych urządzeń peryferyjnych, jakie kiedykolwiek udało nam się podłączyć do komputera Atari. Mam nadzieję, że dzięki temu projektowi, który jest realizowany w sposób całkowicie jawny, stworzy atmosferę, która zachęci ludzi do wniesienia wkładu w coś naprawdę zabawnego i niesamowitego. Mam również nadzieję, że dzięki temu wszystkiemu, co robimy w sposób otwarty, nieuchronnie zapewnimy, że urządzenie to pozostanie użyteczne dla przyszłości społeczności Atari i stanie się modelem do przykręcania użytecznego interfejsu sieciowego do platform retrokomputerowych.
  3.  
    #Atari8bit #FujiNet Ponieważ tak szybko wyprzedaliśmy się z początkowego biegu, @mozzwald założył formularz rejestracyjny dla zainteresowanych kupujących #FujiNet, aby ocenić wielkość następnego biegu. Jak poprzednio, $65 z walizką, $55 bez walizki. Dostaniesz e-maila, gdy nastąpi następna runda.

    ->link<-

    Dziękuję wam wszystkim za cierpliwość i zainteresowanie.
    • 6: CommentAuthorGonzo
    • CommentTime18 Jun 2020
     
    Thomas Cherryhomes - jaki translator tak dobrze tłumaczy?
    • 7:
       
      CommentAuthorDracon
    • CommentTime18 Jun 2020 zmieniony
     
    @Gonzo
    DeepL - autorstwa naszego rodaka, siedzącego w Niemczech.
    Tu więcej:
    ->link<-
    :)
    • 8: CommentAuthorAlex
    • CommentTime19 Jun 2020
     
    Fakt DeepL jest zajebisty! Ale mnie rozwailła "płyta chlebowa" (eng. bread board) :D
    • 9:
       
      CommentAuthorDracon
    • CommentTime19 Jun 2020
     
    O co chodzi z "zabrakło nam 80K dostępnego barana na ESP8266" ? xD
  4.  
    Do syntezy pliku PDF, na przykład na wirtualnej drukarce, od podstaw potrzeba dużo barana.

    Ponadto, duże bufory dla kanałów kart sieciowych. :)

    bufor wyjściowy syntezatora mowy dla przetwornika C/A

    Obsługa protokołu SSL/TLS

    i tak dalej.
    • 11: CommentAuthorpin
    • CommentTime19 Jun 2020
     
    ... przez ten Fujinet to ludzie wreszcie wrócą do używania sprzętu, a nie emulatora ;). Mam także nadzieję, że nikt tego do niego nie zaimplementuje :)))
    • 12: CommentAuthormono
    • CommentTime19 Jun 2020
     
    baran to jest RAM
    • 13: CommentAuthorpirx
    • CommentTime19 Jun 2020 zmieniony
     
    hehehe
    added myself to the "waiting list" :]
    • 14: CommentAuthorpin
    • CommentTime19 Jun 2020
     
    :) - I tower You ;)
    • 15:
       
      CommentAuthorbocianu
    • CommentTime21 Jun 2020
     
    Melduje, że napisałem pierwszą sieciową grę na Atari, wykorzystującą #FujiNet.

    Nie jestem może specjalnie oryginalny, bo jest to gra w szachy, ale da się grać przez internet na jednym z najstarszych i największych serwerów sieciowych FICS (Free Internet Chess Server) ->link<-

    Gra jest już w pełni funkcjonalna, udało mi się już rozegrać kilka próbnych partii. Dorobię może jeszcze sterowanie joystickiem, ale to jak uporam się z innymi drobiazgami.

    Żródła jak zwykle dostępne na moim gitlabie: ->link<-

    Grę można uruchomić też bezpośrednio z serwera fujinet.pl
    /ChessNet.atr
    • 16: CommentAuthorCyprian
    • CommentTime21 Jun 2020
     
    no cacy
    • 17: CommentAuthorpirx
    • CommentTime21 Jun 2020
     
    śliczne
    • 18: CommentAuthorxxl
    • CommentTime21 Jun 2020
     
    powoli widac roznice miedzy idea sieci jak w dragon cart a tej opartej o ESP :D

    brawo :)
    • 19: CommentAuthorpin
    • CommentTime21 Jun 2020
     
    Tak. Ta niestety zawsze będzie wolna, choć urządzenie w sumie ciekawe :)
    • 20: CommentAuthorxxl
    • CommentTime21 Jun 2020
     
    ta, stety jest dla kazdego atari :D - rowniez xegs czy 65xe oraz jest prosta w oprogramowaniu :-) i pozostawia mase pamieci dla usera.

    ESP jeszcze dobrze sie nie zadomowil a juz powstaja gry sieciowe :-)

    Twoj faworyt dragon na rynku jest x lat i ile powstalo oprogramowania? zero :D nie widze zalet dragona w porownaniu z Fujinet.
    • 21: CommentAuthorpin
    • CommentTime21 Jun 2020 zmieniony
     
    Bo Dragon 2 ze stosem w sobie ma dopiero sens. Coś tam takiego robili chłopaki na Aage, są też prototypy rodzimej produkcji. Choć, do takich zastosowań jak gierki po sieci to ten fujinet będzie jak malina. No i fakt, że jest dobrze oparty o OS to istotnie plus. Możesz się czegoś nauczyć od kolegów, Panie XXL ;)

    Inna sprawa to też to, do czego się takich rzeczy używa. Np serwer, który postawiłem na DragonCarcie i Contiki nie dałby się "postawić" na Fujinet. Przyczyna raczej oczywista.
    • 22: CommentAuthorxxl
    • CommentTime21 Jun 2020
     
    mylisz sie jak zwkle :-) postawienie serwera http na tym jest banalne (na WiFiPrime juz jest, a Fujinet ma o wiele mocniejszy proc)
    • 23: CommentAuthorpirx
    • CommentTime21 Jun 2020
     
    co ciekawe fujinet dałoby się zaimplementować na karcie / PBI / ECI, to nawet nie byłoby takie strasznie trudne od strony software'owej. tylko chyba nie ma sensu - do casualowego odpalania gierek zamiast sio2sd wystarczy sio w turbo.
    • 24: CommentAuthorpin
    • CommentTime21 Jun 2020
     
    @XXL - jeśli serwer będzie "siedział" w urządzeniu to pewnie masz rację. Ale to już nie jest Atari ;)
  5.  
    @pin - prawie dwadzieścia lat, DRAGON CART musiał się sprawdzić. Popełnili krytyczny błąd "jedyne co musimy zrobić, to zaprojektować sprzęt" i nie pomyśleli o tym, co projektują w kontekście "systemu" części, które wszystkie muszą współpracować i być łatwe do zrozumienia.

    To żywe piekło do programowania, więc prawie nic nie zostało do tego napisane. (Mówi się jak ktoś, kto dosłownie miał jednego z autorów IP65, przychodzi do niego i próbuje pomóc mu przenieść PLATOTERM do Smoczego Koszyka, tylko po to by się poddał, ponieważ odkryłem, że stos TCP/IP IP65 jest tak opóźniony w połowie, że nawet nie implementuje zmiany rozmiaru okien dla pakietów TCP, co jest rozpaczliwie potrzebne do kontroli przepływu, gdy program kliencki musi zrobić dużo przetwarzania!)

    A Atari po prostu nie jest w stanie poradzić sobie z wieloma nowoczesnymi rzeczami w dzisiejszych sieciach. SSL/TLS jest tego wielkim przykładem.

    Dodaliśmy już adaptery protokołów dla kilku różnych protokołów, takich jak HTTP/S, FTP i TNFS, a wkrótce pojawi się więcej (SMB, NFS, SSH, itd.). W #FUJINET będą też wbudowane parsery dla XML i JSON, które będą mogły pobierać dane wejściowe i otrzymywać zapytania. Pozwoli to na obsługę klientów, którzy potrzebują skomplikowanego przetwarzania danych, jak np. interakcja z Twitterem lub Facebook API.

    Przestańcie też z tym idiotycznym argumentem czystości. Urządzenia peryferyjne Atari są z definicji rozproszonymi urządzeniami obliczeniowymi, po prostu zapewniamy im dużą moc obliczeniową do robienia naprawdę interesujących rzeczy.
    • 26: CommentAuthorpin
    • CommentTime21 Jun 2020
     
    @Thomas Cherryhomes - to taki tutejszy folklor, nie przejmuj się tym ;)
    • 27: CommentAuthorxxl
    • CommentTime21 Jun 2020
     
    Thomas: robisz rzecz przełomową, jak to bywa w takich przypadkach musisz się przygotować na ataki pseudoatarowcow ale nie przejmuj się za niedługo internet w Atari to będzie standard.

    robisz dobrą robotę.
    • 28: CommentAuthorpin
    • CommentTime21 Jun 2020
     
    @XXL - masz kogoś konkretnie na myśli? :-)
  6.  
    #Atari8Bit pierwszą grą dla #FujiNet jest klient Free Internet Chess Server (FICS) o nazwie ChessNet napisany przez @bocianu przy użyciu MAD Pascal! Niesamowita praca!
    • 30: CommentAuthorpirx
    • CommentTime22 Jun 2020
     
    Dobra, to teraz patch do M.U.L.E.
    • 31:
       
      CommentAuthorKaz
    • CommentTime22 Jun 2020
     
    Bomba Bocianu! Będzie grane! :D
  7.  
    If MULE could somehow be patched to be networked, that would be amazing.

    -Thom
    • 33: CommentAuthorpirx
    • CommentTime23 Jun 2020
     
    well... After a thought MULE will be a problem, generally old games with action elements not specifically planned for SIO based communication will be a problem as the transmission halts most of other tasks. Is there a way?
  8.  
    Lucasfilm did a custom SIO routine for BallBlazer that allowed their disk to load while the intro played.. *shrug* so maybe? This is still very new territory.

    -Thom
    • 35:
       
      CommentAuthoranonymus
    • CommentTime23 Jun 2020
     
    Probably I am not a target for this product, but maybe basic Windows games like hearts and so on May be a good start?
  9.  
    Indeed, and I have been not only writing example code, but working with other developers to get new games on the system. This was purely speculation.
  10.  
    Oznacza to, że konieczne jest przeprowadzenie pewnych badań na temat tego, kiedy wysłać dane sieciowe, aby zmaksymalizować interaktywność (podejrzewam, że będziemy musieli skłaniać się ku wysyłaniu jak najmniejszej ilości danych). Nie jestem dobrze przygotowany, aby zrobić to samemu i będzie potrzebował ludzi bardziej utalentowanych niż ja, ale myślę, że możemy z powodzeniem robić gry zręcznościowe przez interfejs sieciowy.
    • 38: CommentAuthorpirx
    • CommentTime23 Jun 2020
     
    Oh, you can do action games as well, you just need to plan for very small number of cycles available during serial transmission.
    How small a packet can be?
    Say, I want to send to server 6 bytes and receive other 6 bytes. TNFS is possibly a way to do this(?)
  11.  
    pirx: the network (N:) device (0x71 to 0x78), can read and write data in a huge number of protocols, as well as being able to do pure UDP or TCP. TNFS is meant for file sharing so it isn't a good fit for this, but that's okay. :)

    For games, UDP is the best option, as you can quickly switch destinations for packets, and even have the option to multicast (send one packet to multiple destinations simultaneously, depends on the network topology.)

    So once you send an 'O'pen command to say, UDP://some.server.pl:2000/

    you can then send 'R'ead, 'W'rite, and 'S'tatus commands. The number of bytes specified in both daux and dbyt. Status tells you how many bytes are waiting, and the INTERRUPT/PROCEED lines can tell you if there is data waiting so you don't waste time bombing the SIO bus with status requests.

    If we can standardize on a protocol that can be used for games, we can make a protocol on the ESP itself to handle the details and make it REALLY easy to use from the Atari side.

    The ESP itself is also powerful enough that not only could it run a local server (for parties), it can handle mDNS to announce games that can easily be queried. Lots of amazing possibilities here.
    • 40: CommentAuthorpirx
    • CommentTime24 Jun 2020 zmieniony
     
    nice! as soon as I get my hands on the interface I'm trying to port some of my stuph to fujinet.
    • 41: CommentAuthorAlex
    • CommentTime24 Jun 2020 zmieniony
     
    Thomas: I had similar idea many years ago, but.. never mind :) Did you think about pics converter? Converting JPEG/GIF/PNG files on-the-fly to the desired Atari format? It's easy for ESP and would allow Atari to "see" ;)
  12.  
    indeed, very doable. would love somebody to write a nice portable image converter, we can then work a way to integrate it.
    -Thom
    • 43: CommentAuthorAlex
    • CommentTime25 Jun 2020
     
    I think that for the beginning just a simple 2/4/16 color resizable bitmap would be enough :) There are opensource libraries available you can use to implement this feature in the firmware I think.
  13.  
    yeah, there are quite a few.

    I can give chalk talks on how to modify and extend the firmware, and in fact, I WANT to do this, so I can get people making new features we never thought of, or didn't have time to do.

    -Thom
    • 45: CommentAuthorAlex
    • CommentTime25 Jun 2020
     
    Good news Thom :)
    • 46:
       
      CommentAuthorKaz
    • CommentTime6 Jul 2020
     
    Chłopaki starają się oszacować zapotrzebowanie na następną partię interfejsów, można taką informację o swoich chęciach zakupowych dać tutaj:

    ->link<-

    Ależ piękne jest to, że można sobie wybrać styl obudowy: 400/800, XL, XE :D
    • 47: CommentAuthorMADRAFi
    • CommentTime6 Jul 2020
     
    szacunkowy koszt to $65 + koszt przesylki
    • 48: CommentAuthorCyprian
    • CommentTime6 Jul 2020 zmieniony
     
    @MADRAFi to jest cena za całość?
    Jeśli tak to poproszę jedną sztukę do XL.
    • 49: CommentAuthorMADRAFi
    • CommentTime6 Jul 2020
     
    wejdz w link Kaza, przeczytaj.
    To nie jest lista do zamowienia. Tak $65 to cena za to co na zdjeciu w dowolnym kolorze. Do tego transport. Prosze pamietac ze produkcja nie bedzie w PLa prawdopodobnie Chiny ->USA->Wysylka.

    Ja nadal czekam na Chinczyka ktory ma zrobic shielda pod ESP32. Jak przyjda gotowe plytki to zloze urzadzenie i dam znac. Pliki gerbera sa dostepne i darmowe. Mozna sciagnac wersje THT (przewlekane pcb) zamowic i samemu zlozyc.
    • 50: CommentAuthorCyprian
    • CommentTime7 Jul 2020
     
    @MADRAFi dzięki za wyjaśnienie,
    tak to jest jak się czyta forum na szybko, w toalecie :)