Pytanie do serwisantów.

Widziałem ją wcześniej. Wystaje wtyczka. Wystarczyło zostawić na krześle aby ktoś przysiadł na tablet. Te 2-3cm plus ciężar ciała robi dźwignię.

Zamiast przeprosić to jeszcze się stawiasz :-) Ja od Ciebie nic więcej nie kupię ale ciekawe jakie zdanie mają inni? :-) Ciekawe jak po 20 latach zachowujesz się do obecnych klientów?

Po prostu zachowałeś się z tym softem podle. Ukryłeś się i nie odpowiadałeś. Nawet nie pamiętam czy to był rok czy dwa lata czy więcej ale zlałeś klientów, którzy Cię karmili, Twoją żonę i dzieci. W końcu chyba natłok zmusił Cię do zrobienia softu, bo odkryłem po długim czasie, że dałeś nowy soft ale już wszyscy co musieli wydali kasę na inne produkty.

W dniu czwartek, 18 sierpnia 2016 20:06:42 UTC+2 użytkownik Piotr Gałka napisał:

Dlatego stosuje się chip USB-UART któregoś z dużych producentów, którzy mają ludzi którzy potrafią pisać (i certyfikować) sterowniki i uaktualniać je na nowe wersje systemu, a nie uprawia partyzantkę. Bo inaczej to się skończy tak, jak jest teraz - na trzymaniu jakichś antycznych komputerów z wersjami Windowsa albo wręcz DOSa, na których akurat działa jakiś napisany na kolanie program. Sytuacja wyjątkowo popularna w elektronice i np. CNC, że trzeba trzymać jakiś złom, bo program który robi 2 obli- czenia na krzyż i wysyła przez UART 2 liczby całkowite co sekundę jakimś dziwnym kodowaniem nie działa na niczym innym.

Pozdrawiam,

Jeśli dobrze zrozumiałem historię, to Piotr stworzył/sprzedał onegdaj oprogramowanie działające pod kontrolą systemu DOS, niekompatybilne z Windows. Jeśli faktycznie do tego sprowadza się cała sprawa, to nie widzę problemu... Mogę się tylko domyślać że w wymaganiach stało "system MSDOS lub kompatybilny". Windows się do tego nie zalicza. Co innego gdyby pewnego ranka przestało działać samo z siebie na wspieranej platformie, ale tu chyba nie o tym mowa.

Sam tworzę oprogramowanie i z tego żyję - jak klienci marudzą że chcieliby aby działało na systemie X/Y/Z lub by korzystało z bazy SQL innej niż ta pod którą napisałem kod, to uprzejmie odsyłam w krzaki lub

- jeśli to bardzo ważny kontrahent - proponuję mocno płatny custom development.

Mateusz

To nie oprogramowanie ale urządzenie elektroniczne, które wymagało oprogramowania. Ja kupiłem jego programator wcześniej i dokupowałem tylko przejściówki do innych układów scalonych ale byli tacy co kupili już praktycznie niedziałający produkt, bo nie miał oprogramowania, które dało się uruchamiać. Czystego DOS-a to już nikt dawno nie używał. Używało się go pod windows klikając w niego. A późniejsze zachowanie to było draństwo, bo ani za darmo ani za pieniądze nie było aktualizacji i sprzęt stał się bezużyteczny. Klientów na drzewo wysyłać nie można. Co innego jest rodzaj SQL a co innego sprzedać fizycznego produktu, którego nie ma jak użyć.

To nawet nie o to chodziło. Myślę, że miał sprzedaż dużą i zachował się nieodpowiedzialnie w stosunku do klientów elektroników. Pewnie sobie myślał, żeby trzymali stary złom i go to nie obchodzi. Prawdopodobnie nie chciało mu się tego softu utrzymywać i się schował przed klientami elektronikami. I wyleciał z rynku programatorów i narzędzi dla elektroników za to postępowanie. Znalazłem pliki. To nie były 2 lata ale 5 lat przerwy. Totalne olanie nas wszystkich. Prawdopodobnie poprawił kilka linijek i skompilował. Draństwo. Jak znajdę starszy to w hex edytorze porównam... ======================================================================

Program PICCOLO (c) M i c r o M a d e ================ Gałka i Drożdż spółka jawna

Wieniawskiego 16, 64-920 PIŁA tel/fax: (+48) 67 213-24-14 e-mail: snipped-for-privacy@micromade.com.pl

====================

Najaktualniejsze informacje o programie piccolo.exe.

Spis treści:

------------ 1. Wywołanie programu 2. Programowane elementy 3. Kolejne wersje programu

1. Wywołanie programu ======================

PICCOLO [/m]

/m - praca w trybie 'mono'.

1. Programowane elementy: =========================

Programator 'Piccolo':

-----------------------

EPROM standard: 2716,2716A,2716B 2732A,2732,2732B 2764A,2764, 27128A,27128, 27256,27256-21V 27512,

EPROM (CMOS): 27C64,27C128,27C256,27C512,

PAGE EPROM: 27513,27C513,27011,27C011,

EPROM w/LATCH: 87C64,87C256,87C257,68C257,

EEPROM: 2804,2816A,2816A-T(with timer),2817A 2864,2864RB(Ready/Busy),2864DP(Data Pooling), 2864DPPM(Page Mode Data Pooling), 28256,

RAM (test): 6116, 6264,62256,

Przystawka 'Picco-mb': 27010,27C010,27C1001,27C100(Mask ROM),

---------------------- 27C020,27C2001, 27C040,27C4001, 27C080,

Przystawka Picco-p49: 8748,8749

----------------------

Przystawka Picco-p51:

---------------------- Ind. Standard: 8751H,8744H,8751BH,8752BH,87C51,87C52 Intel: 8751H,8744H,8751BH,8752BH, 87C51,87C52,87C54,87C58, 87C51FA,87C51FB,87C51FC Philips: 87C51,87C52,87C575,87C652,87C654,87C524,87C528 Atmel: 89C51,89C51-5,89LV51,89LV51-5, 89C52,89C52-5,89LV52,89LV52-5, 89C55,89C55-5,89S8252

Przystawka Picco-at20:

---------------------- Atmel: 89C1051,89C2051,89C4051

1. Kolejne wersje programu piccolo.exe =======================================

Data,wersja Opis =========================================================================

1989 Początkowa wersja programu. Programowanie EPROMów v 1.0 2716 do 27512. Program w wersji mono.

1990 Program w wersji color. Dołożenie obsługi symulatorów v 2.0 (przystawek do programatora).

1991 Zmiana interface'u użytkownika. Programowanie v 3.0 mikroprocesorów 8748,8749.

1992 Uzupełnienie listy programowanych elementów o: v 4.0 - EPROMy 1Mb do 8Mb, - mikrokontrolery 8751, 8752, - EEPROMy 2804 do 28265, Obsługa symulatora 'Picco-512'.

30.05.94 Umożliwienie wymuszenia pracy programu w trybie mono. v 4.60 Służy do tego celu opcja /m przy wywołaniu programu. Na razie jest to jedyna opcja rozpoznawana przez program.

25.11.94 Umożliwienie ujemnego przesunięcia ładowanego do bufora v 4.61 zbioru. Adres ładowanego bajtu jest zwiększany o podany ofset, a następnie obcinany do rozmiaru bufora: adres = (adres+ofset) & 0xFFFFF Zbior zaczynający się od adresu 0x8000 można załadować na początek bufora podając ofset F8000.

11.02.95 Spacja jest teraz akceptowana w czasie edycji bufora v 4.62 (część ASCII okna edytora).

6.06.95 Zmiana zbiorów *.doc i *.hlp towarzyszących programom ze v 4.63 standardu mazowii na dos852.

22.09.95 Wprowadzenie programowania mikrokontrolerów produkcji v 4.70 Atmel oraz podział mikrokontrolerów serii 8751 na grupy: - Industry Standard, - Intel, - Philips, - Atmel. Programowanie security (Encryption Tabele i Lock Bits) jest teraz wykonywane automatycznie po zaprogramowaniu mikrokontrolera. Przy wyborze typu mikrokontrolera ustala się, które funkcje security mają być wykonywane. Ta zmiana została wymuszona przez pewne specyficzne cechy mikrokontrolerów Atmel, które uniemożliwiają wykonanie funkcji security niezależnie od normalnego programowania pamięci programu.

Wprowadzenie pozycji Chip Erase do menu Programmer - kasowanie mikrokontrolerów zawierających Flash Memory. Intel zmienił opis mikrokontrolera 87C51. Nowy ma dwa razy większą (0x40) Encryption Tabele i 3 bity security. Programowanie starego 87C51 Intela jest umieszczone w grupie Industry Standard.

10.10.95 Wprowadzenie pozycji Security w menu Options. v 4.71 Pozwala ona na zmianę ustawień programowanych zabezpieczeń bez zmiany typu elementu.

18.10.95 Opracowanie przystawki dla mikrokontrolerów v 4.72 89C1051 i 89C2051 (Atmel) i wprowadzenie ich do listy programowanych elementów.

Dla tych mikrokontrolerów funkcje: Program, Verify i Read zostały zmodyfikowane tak, że dotyczą zawsze całego bufora (nie można programować w/g pliku).

5.12.97 Uzupełnienie listy programowanych mikrokontrolerów v 4.73 produkcji ATMEL o 89C51-5, 89LV52, 89LV52-5, 89C55, 89C55-5, 89S8252.

Mikrokontrolery 89C55 i 89C55-5 mają po 20 kB pamięci programu. Ponieważ linia adresowa A14 została w nich podłączona inaczej niż w procesorach innych producentów niezbędna okazała się modyfikacja przystawki Picco-p51. Programowanie tych mikrokontrolerów wymaga przystawki Picco-p51 v2.2 lub nowszej. Dla wersji SMD wymagana jest przystawka Picco-p51s v1.2 lub nowsza. Mikrokontroler 89S8252 ma 8 kB pamięci programu (FLASH) i 2 kB pamięci danych (EEPROM). W czasie programowania obie te pamięci zajmują jeden ciągły obszar: 0000H do 1FFFH - pamięć programu i 2000H do 27FFH - pamięć danych. Jednak nie trzeba wytwarzać jednego pliku zawierającego dane dla obu tych obszarów gdyż do bufora programu Piccolo można ładować kilka plików.

14.01.98 Dodanie komunikatu dla 89C55 i 89C55-5 że wymagana v 4.74 jest przystawka Picco-p51 v2.2 lub Picco-p51s v1.2

18.04.98 Poprawienie błędu, wprowadzonego w wersji 4.73. v 4.75 Błąd dotyczył wszystkich "dużych" mikrokontrolerów ATMELa (programowanych z przystawkami Picco-p51 i Picco-p51s). Błąd się ujawniał tylko gdy programowane dane zawierały dłuższe odcinki jednakowych bajtów.

01.10.98 Wprowadzenie mikrokontrolera ATMEL 89C4051. v 4.76

07.01.99 Poprawa błędu programowania 89C4051. v 4.77

13.09.04 Rezygnacja z kompatybilności procedur komunikacji RS232 v 4.78 z komputerem XT (może też AT) aby zapewnić pracę pod Windows'XP.

W dniu 2016-08-19 o 16:20, bat pisze:

Ale z tego co rozumiem, to nie musiał. Zrobił pod DOS, taki kupiłeś i w DOS-ie działa. A to, że nie chciał zrobić pod WIN, to jego sprawa. Patrząc z formalnej strony.

Robert

bat pisze: [..]

Kupując produkt masz określone wymagania sprzętowe/programowe które są wspierane, skoro kupiłeś to się zgodziłeś na spełnienie wymagań. Nie bardzo rozumiem co stoi na przeszkodzie by odpalić dos nawet na współczesnej maszynie. Wsparcie dla kolejnych systemów to Twoje pobożne życzenie które producent może zapewnić ale wcale nie musi. To tak jakbym psioczył na Brother'a że nie wydają sterowników do HL-3400CN dla windy wyższej niż 2k. Taka decyzja firmy i mogę im skoczyć.

Tak ten Micromade od klientów wymagał niemożliwego aż klienci przestali kupować ich produkty :-) Taki z tego morał. A szkoda. Gdyby zrobił nowszy model na więcej scalaków to bym kupił na bank kolejny produkt.

To były inne czasy i ich widocznie nie rozumiesz.

Z formalnej tak ale jak skończył z tymi programatorami to widzimy :-)

Ale wiesz co... tam nie było nawet mowy czy to tylko dla DOS czy nie. Działał pod Windows aż do W98 czy nawet milenijki. Nikt nie miał nawet w głowie pracy pod DOS-em.

Użytkownik "bat" snipped-for-privacy@man.com napisał w wiadomości news:np74k8$laq$ snipped-for-privacy@gioia.aioe.org...

Nigdy nie mieliśmy dużej sprzedaży.

Dokładnie odwrotnie. Zachowywałem zgodność z XT/AT bo miałem sygnały, że ludzie używają takich komputerów w warsztatach i zależy im abym ich nie zmuszał do zmiany. U jednego nawet byłem kilka razy i nawet wysłałem mu raz, czy dwa razy program do sprawdzenia (czy działa pod XT) przed wypuszczeniem.

Nie zrezygnowaliśmy z tego rynku. Od 199? przygotowywaliśmy serię urządzeń (programator EPROM, EEPROM, GAL, emulator EPROM, programator Atmeli InSystem). Seria nazywała się TopLess bo urządzenia nie miały górnej części obudowy (płytka z nadrukiem była obudową). Stworzyliśmy system przełączanych pętli prądowych - z jednego COMa (zasilanie przełącznika pętli z COMa) można było obsługiwać do 10 urządzeń z zapewnioną izolacją galwaniczną. Dwużyłowy kabelek mógł mieć do 100m długości z zachowaniem prędkości 115200. Długość połączenia (komputer w pokoju, a uruchamiany układ (energetyka) na hali) i izolacja była ważna dla Emulatorów a chcieliśmy wszystko mieć tak samo. Emulatory i programator InSystem zasilały się z układu, a programatory z wtyczkowych zasilaczy 9V.

Wszystkie prototypy były gotowe i mieliśmy je oprogramowane tak, że kilka aplikacji mogło chodzić na komputerze i każda gadała ze swoim urządzeniem mimo, że wszystkie połączone do tego samego COMa i już, już mieliśmy się pokazać z kompletem nowych urządzeń, ale ...... wstąpiliśmy do Unii. Wyszło mi, że nie da się zapewnić wymaganej przez CE odporności na ESD dla urządzenia bez góry obudowy no i kilka lat pracy poszło do śmieci :(.

Piccolo i Picco-GAL były zasilane ze złącza klawiatury więc naturalnie wymierały (w 2003 sprzedaliśmy kilka sztuk (chyba bliżej 0 niż 10)). Przeprojektowywanie TopLessów na NieTopLessy nie miało sensu, bo już było jasne, że teraz jest era USB i nie byliśmy do tego absolutnie przygotowani.

Gdyby ta zmiana była związana nie tylko z Windows XP ale też z wcześniejszymi Windowsami na pewno znalazła by się o tym wzmianka w tym pliku.

Tobie wydaje się wszystko takie proste. Jakiś 1.5 roku temu napadli mnie ludzie, że napisany przez mnie w 1995r Assembler 8051 nie działa pod Windows 10. Ja pracuję pod Windows XP. Nie mam dostępu do komputera z Windows 10. U mnie tamto exe działa. Co z tym zrobić. Program napisany pod DOS, exe z 1995r przekompilowane Turbo C++ 1.0. Wygrzebałem (z trudem) źródła z 1995r. Wtedy w 1995 mnie coś napadło, że koniecznie muszę (ambicja) zrobić ten assembler jako jednoprzebiegowy. Szybko się okazało, że na komputerze z 640k RAMu np. assemblacja programu do DSM-51 już wymagała 70% dostępnej pamięci. Udało mi się zwiększyć maksymalną długość assemblowanego programu (o około 25%) dzięki przeciążeniu operatora new.

Najpierw przepuściłem źródła przez Turbo C++ 1.0. Wszystko przeszło i uzyskałem działający u mnie exe. Uznałem, że może chodzi o to, że system jest 64 bitowy. Czyli muszę to przekompilować jakimś nowym kompilatorem. Zainstalowałem sobie Buildera

2010. Ale moje źródła, za żadne skarby nie chciały się przekompilować. Wszystkie moje stringi mu się nie podobały, a assemler to praca na stringach - wszystkie mnemoniki, parametry typu rejestry itd. Poległem. Nie jestem programistą (programuję tydzień/dwa tygodnie w roku). Od innego użytkownika tego Assemblera dowiedzieliśmy się jak obejść problem i przekazaliśmy temu pierwszemu i u niego też zadziałało. Pół roku temu pojawiła się znów. Tym razem spróbowałem pod Builderem 5, który znam lepiej. Ten nie miał nic przeciwko moim stringom. Ileś rzeczy musiałem zmodyfikować i w końcu się przekompilowało, ale próba uruchomienia i access violation. Nie jestem na tyle biegły aby umieć namierzyć taki błąd. Stwierdziłem, że pewnie to moje przeciążenie new daje o sobie tak znać. Uznałem, że muszę ten assembler napisać od nowa. Wydrukowałem wszystkie źródła i zacząłem je czytać - no nic nie pamiętam, a jest tego kilkadziesiąt stron. Napisanie od nowa oceniłem na 2..3 miesiące. No nie mam tyle czasu. Wróciłem do tego access violation. Już nie pamiętam, ale w końcu jakoś metodą prób, błędów udało mi się znaleźć przyczynę problemów. Główny problem był taki, że w Turbo C++ int miał 16 bitów a w Builderze 32 bity. Wydawało by się, że jak więcej bitów na zmienną to nic złego się nie może stać, ale może. Przejrzałem wszystkie użycia int w programie. Się okazało, że to co uzyskałem działa pod Windows 10. Ale dlaczego - pojęcia nie mam. Przecież to jest program, który tylko działa na plikach. Tu nie może być mowy o braku dostępu do UARTów jak w przypadku Piccolo. Nie przekompilowałem go też na 64 bitowy. P.G.

Użytkownik snipped-for-privacy@gmail.com napisał w wiadomości news: snipped-for-privacy@googlegroups.com...

mają ludzi którzy potrafią pisać (i certyfikować) sterowniki i uaktualniać je na nowe wersje systemu, a nie uprawia partyzantkę.

Na płytce 29mm x 14mm (HAK2) z trudem zmieściły mi się: wtyk USB, procesor, stabilizator, zabezpieczenie ESD i dławik CM, przy założeniu, że ze względu EMC druga strona musi być masą. Nie wiem jak miałbym tam wcisnąć jeszcze trzeci scalak. P.G.

Użytkownik "Mateusz Viste" <mateusz.viste@localhost> napisał w wiadomości news:57b70d29$0$3348$ snipped-for-privacy@news.free.fr...

Sprzedane było urządzenie obsługiwane przez oprogramowanie pod DOS. Różniło się (przynajmniej początkowo) od innych tym, że inni, aby zapewnić obsługę nowych scalaków wymagali przysłania urządzenia do fabryki w celu (przypuszczam odpłatnej) zmiany oprogramowania wewnętrznego (wtedy nie było jeszcze Flash-y więc polegało to na skasowaniu EPROMu i zaprogramowaniu nowym programem), a my napisaliśmy oprogramowanie wewnątrz na tyle uniwersalnie, że mogliśmy obsługiwać pojawiające się na rynku nowe scalaki jedynie poprzez zmianę oprogramowania na PC. Kolejne wersje programu były dostępne za darmo ! 'bat' załączył plik z którego widać co w której wersji zostało dołożone. Jak pojawiło się Windows, to programy DOSowe nadal działały, aż kiedyś kolejna wersja Windows zablokowała dostęp programom DOS do UARTów. Głowy nie dam, ale prawie na pewno ten problem rozwiązałem wcześniej, a nie przy tej ostatniej zmianie opisanej jako dopasowanie do XP.

OIDP ta ostatnia zmiana dotyczyła tylko kwestii timeoutów w komunikacji. Do odmierzania czasu (od czasów DOS) używałem jakichś pętli, które na początku pracy programu sobie kalibrowałem według zegara komputera. Nie wiem dlaczego pod XP to przestało działać. Mogłem problem namierzyć i rozwiązać dopiero jak sam dorobiłem się komputera z XP (pracuję na nim do dziś). Wychodzi, że było to w 2004 roku. P.G.

Czyli to wszystko partyzantka :-)

Użytkownik "bat" snipped-for-privacy@man.com napisał w wiadomości news:np71et$arn$ snipped-for-privacy@gioia.aioe.org...

Nie natłok tylko wreszcie miałem komputer na którym mogłem namierzyć problem (jeśli masz na myśli XP a nie jak wcześniej pisałeś 98). P.G.

Czyli nie umiałeś programować i sprzedawałeś produkt z góry skazany na takie problemy. Miał wadę fabryczną od początku. - No pięknie, partyzantka na całego :-) Wszyscy winni tylko nie Ty :-) Zamiast się uczyć to się schowałeś przed klientami :-) Odeślę Ci symbolicznie piccolo żebyś sie nim udławił :-)

No jeszcze lepiej. Nie miałeś komputera i sprzedawałeś niesprawdzony produkt :-)

Nigdy nie używałem scalaka USB-UART więc może czegoś nie wiem. Czy daje się namierzyć swoje urządzenie bez wysyłania śmieci do wszystkich innych COMów dostępnych w systemie. Podobno też jak ktoś wyjmie i włoży takie urządzenie to nie ma gwarancji, że ono będzie tym samym COMem. P.G.