Witam

W miniony weekend przez 2 dni siedziałem i szukałem, czemu mi I2C
nie działa w STM32. Na googlu wyszukałem, że wiele osób miało takie
problemy, ale mieli złą inicjalizację itp... Próbowałem wszystkiego. Ich
przykłady działały u mnie, ale po "wklejeniu" w projekt przestawały.
Okazało się, że w Erracie napisano, że I2C ma konflikt z kontrolerem
pamięci zewnętrznej i nie mogą działać jednocześnie.... No to pięknie!
Kiedyś większe problemy miałem z LPC23xx, tam to errata była sporo
większa i nie działał na przykład kontroler pamięci w ogóle (w pierwszej
rewizji), brał parę mA z baterii podtrzymującej zegarek (jeśli włożyło
się ją przy wyłączonym zasilaniu głównym) itp.
I tak się zastanawiam, czemu te mikrokontrolery dziś są takie
"wadliwe"?? Czemu tak duże są do nich erraty?? Ja rozumiem, że koszty
uruchomienia produkcji takiego układu scalonego są potężne, dlatego nie
wykonuje się krótkich serii prototypowych... Ale skąd w ogóle ten
problem się bierze??
Czy to efekt pośpiechu? Braku testów? Zwykłych błędów?? Czy może
jakiś efektów, które ciężko przewidzieć? Intryguje mnie zwłaszcza nazwa
"Silicion Limitations" użyta w Erracie do STMa, która sugeruje, że oni
zrobili wszystko OK, tylko po przelaniu na krzem przestało działać ;)...
Jak tego typu błędy wyglądają w innych układach?? Mniej lub bardziej
skomplikowanych?? FPGA, uP do PCtów na przykład (pewien Intel źle
dzielił, ale poza tym nie słyszałem, żeby miały jakieś wady tego typu),
a jak to wygląda w układach analogowych, prostych cyfrowych? Czy był
kiedyś wzmacniacz operacyjny poczwórny, w którym można było na raz
korzystać tylko z trzech wzmacniaczy?? ;)...
I to, co mnie interesuje najbardziej. Układ został wyprodukowany, to
chyba można wtedy sprawdzić jak działa, ewentualne ograniczenia wpisać
do oficjalnej dokumentacji (w odpowiednich rozdziałach) i tyle, a nie
wypuszczać jakieś erraty. Czy to nie jest efekt pośpiechu przy
wypuszczaniu na rynek nowego układu??

Taki niedzielny temat na luźną dyskusję.

--
Pozdrawiam
Konop

do góry

On 2011-08-28 17:35, Konop wrote:
> Okazało się, że w Erracie napisano

Chyba najbardziej denerwującym zjawiskiem jest zwykle skurw... pisanie
że działa tak-a-tak, a 300 ston niżej ze jednak nie działa w ogóle,
sorry. Jak by nie można było mieć dokumentacji z erratą wplecioną w
tekst tam gdzie opisują funkcjonalność. Zapewne to ta sama choroba
psychiatryczna co tworców ustaw i poprawek - tekst jednolity jest
wygodny, ale niedostepny. Bo nie.

do góry

W dniu 2011-08-28 17:41, Sebastian Biały pisze:
> On 2011-08-28 17:35, Konop wrote:
>> Okazało się, że w Erracie napisano
>
> Chyba najbardziej denerwującym zjawiskiem jest zwykle skurw... pisanie
> że działa tak-a-tak, a 300 ston niżej ze jednak nie działa w ogóle,
> sorry. Jak by nie można było mieć dokumentacji z erratą wplecioną w
> tekst tam gdzie opisują funkcjonalność. Zapewne to ta sama choroba
> psychiatryczna co tworców ustaw i poprawek - tekst jednolity jest
> wygodny, ale niedostepny. Bo nie.
A widzisz, też się kiedyś nad tym zastanawiałem. Doszedłem do wniosku,
że erraty i wspomniane przez Ciebie poprawki do ustaw są dla ludzi,
którzy w tym "siedzą". Prawnik zna ustawę na pamięć i w razie jej
zmiany, to one go interesują. Byłoby bez sensu, żeby dać mu nowy tekst
jednolity i powiedzieć "wskaż 320 różnic, których dokonaliśmy" - on
potrzebuje tylko tych różnic. Podobnie z ludźmi znającymi dokumentacje -
ich interesują różnice. Dla Ciebie czy dla mnie - ludzi po raz pierwszy
czytających te papiery lepszy byłby "tekst jednolity" dokumentacji.
Dlaczego oprócz erraty go nie udostępniają? Nie wiem. Może to kwestia
jakichś mechanizmów w firmie, takiej, a nie innej polityki. Każda zmiana
firmowych papierów, to nie tylko umieszczenie ich na serwerze. Dla
przykładu, jeżeli dokonujesz certyfikacji urządzenia, to musisz
przekazać do odpowiedniego urzędu jego dokumentację. Po uzyskaniu
certyfikatu nie wolno Ci zmienić ani literki w dokumentach. Każda zmiana
wymaga zwrócenia się do urzędu, a to kosztuje. Może podobny mechanizm
działa w przypadku dokumentacji procesorów?
Brak "tekstu jednolitego" dokumentacji aż tak mi nie przeszkadza.
Pobieram dokumentację "bazową", pobieram erraty, najpierw zapoznaję się
czego erraty dotyczą i potem, czytając interesujące mnie fragmenty
dokumentacji bazowej uwzględniam to, co było w erratach. Wymaga to
oczywiście więcej "wysiłku" niż przy czytaniu "tekstu jednolitego", ale
nie jest aż tak źle :-)

do góry

Użytkownik "philips" <p...@o...pl> napisał w wiadomości
news:j3dv6u$d25$1@news.onet.pl...
> Brak "tekstu jednolitego" dokumentacji aż tak mi nie przeszkadza. Pobieram
> dokumentację "bazową", pobieram erraty, najpierw zapoznaję się czego
> erraty dotyczą i potem, czytając interesujące mnie fragmenty dokumentacji
> bazowej uwzględniam to, co było w erratach. Wymaga to oczywiście więcej
> "wysiłku" niż przy czytaniu "tekstu jednolitego", ale nie jest aż tak źle
> :-)

Czytając erratę można od razu dokonać selekcji układów :) Należy pamiętać,
że errata nie musi uwzględniać wszystkich błędów. Mam na to jeden przykład,
od dwóch lat producent (przez dystrybutora) zlewa ewidentną nieprawidłowość.
Poradziłem sobie zmieniając koncepcję urządzenia.

Michał

do góry

Użytkownik "Konop" <k...@g...pl> napisał w wiadomości
news:j3dn7q$p2h$1@inews.gazeta.pl...
> Czy to efekt pośpiechu? Braku testów? Zwykłych błędów?? Czy może jakiś
> efektów, które ciężko przewidzieć? Intryguje mnie zwłaszcza nazwa
> "Silicion Limitations" użyta w Erracie do STMa, która sugeruje, że oni
> zrobili wszystko OK, tylko po przelaniu na krzem przestało działać ;)...
> Jak tego typu błędy wyglądają w innych układach?? Mniej lub bardziej
> skomplikowanych?? FPGA, uP do PCtów na przykład (pewien Intel źle dzielił,
> ale poza tym nie słyszałem, żeby miały jakieś wady tego typu),

W erratach mikrokontrolerów z rdzeniami ARM widać chyba tylko błędy
działania peryferów, natomiast nie ma nic o rdzeniu. Coś przez mgłę kojarzę
jeden przypadek złego działania jakiegoś rozkazu, ale nie pamiętam w jakim
uC (ST, NXP lub Atmel). Daje to do myślenia.

Michał

do góry

On 28.08.2011 20:14, Michał Lankosz wrote:
> Użytkownik "Konop" <k...@g...pl> napisał w wiadomości
> news:j3dn7q$p2h$1@inews.gazeta.pl...
>> Czy to efekt pośpiechu? Braku testów? Zwykłych błędów?? Czy może jakiś
>> efektów, które ciężko przewidzieć? Intryguje mnie zwłaszcza nazwa
>> "Silicion Limitations" użyta w Erracie do STMa, która sugeruje, że oni
>> zrobili wszystko OK, tylko po przelaniu na krzem przestało działać ;)...
>> Jak tego typu błędy wyglądają w innych układach?? Mniej lub bardziej
>> skomplikowanych?? FPGA, uP do PCtów na przykład (pewien Intel źle
>> dzielił, ale poza tym nie słyszałem, żeby miały jakieś wady tego typu),
>
> W erratach mikrokontrolerów z rdzeniami ARM widać chyba tylko błędy
> działania peryferów, natomiast nie ma nic o rdzeniu. Coś przez mgłę
> kojarzę jeden przypadek złego działania jakiegoś rozkazu, ale nie
> pamiętam w jakim uC (ST, NXP lub Atmel). Daje to do myślenia.

Nie wiem, czy chodzi o to samo, ale ST miał, w którejś rewizji testowej
STM32 błąd w rdzeniu. Oczywiście nie przyznali się do tego, a w erracie
było napisane, że kompilatory gcc i iar są niekompatybilne z rdzeniami
starszymi niż "xyz".

do góry

Użytkownik "Konop" <k...@g...pl> napisał w wiadomości
news:j3dn7q$p2h$1@inews.gazeta.pl...
> Witam
>
[...]

mam przyjemność tworzyć oprogramowanie na sporego SoCa (TMS320TCI6618) i po
natrafieniu na kolejną minę sprzętową postanowiłem dowiedzieć się nieco o
jego historii ... okazało się, ze większość errat do spadek po niedokładnej
specyfikacji albo po założeniach wykonawcy poczynionych bez konsultacji z
projektantem (oczywiste rzeczy nie zawsze są oczywiste dla wszystkich). do
tego dochodzi jeszcze presja czasowa, nieścisłości językowe (twórcy
specyfikacji bywają niezbyt biegli w angielskim pisanym) i tym podobne
ludzkie czynniki.


@

do góry

On 2011-08-28 19:51, philips wrote:
> A widzisz, też się kiedyś nad tym zastanawiałem. Doszedłem do wniosku,
> że erraty i wspomniane przez Ciebie poprawki do ustaw są dla ludzi,
> którzy w tym "siedzą". Prawnik zna ustawę na pamięć i w razie jej
> zmiany, to one go interesują.

Działa to tak: masz tekst jednolity, a poniżej historię z uwzględnieniem
zmian. I to powinno być bardziej użyteczne niż oczopląs z czytaniem
erraty do erraty i bawianiem się w system kontroli wersjii z robieniem w
głowie diffa na tekście.

> Byłoby bez sensu, żeby dać mu nowy tekst
> jednolity i powiedzieć "wskaż 320 różnic, których dokonaliśmy"

Chodzi o to żeby obie wersjie były dostepne, teks jednolity przede
wszystkim.

> Po uzyskaniu
> certyfikatu nie wolno Ci zmienić ani literki w dokumentach.

Efektem czego lądujesz z kłamliwym tekstem i poprawką tych kłamstw w
jakims innym dokumencie (o którym możesz nie wiedzieć).

> Pobieram dokumentację "bazową", pobieram erraty, najpierw zapoznaję się
> czego erraty dotyczą

Niestety to tak nie działa. To działa tak: strona 1: "Supportujemy
pierdyliard UARTów w hardware, konkurencja klęka!", strona 300:
"Wszystkie są zjeb..., sorki, ale możecie sobie zrobić softwareowo".

do góry

Regułą jest chęć bycia "the first".
Każdy zaś producent ,jesli wierzyć informacjom ,jest No. 1.
Po latach już nie wierzę.
Babole zdarzają się wszystkim.
Dokumentacje techniczne są na coraz bardziej dennym poziomie.
W datalach tłumaczą rzeczy nieistotne, pomijają najważniejsze.
Około pól roku temu na skutek mojej korespondencji AD wreszcie opracowało
porządniejszą wersję dokumentacji do jednego z DDSów. Po kilku latach
produkcji.
O dziwo ,że wszystkimi moimi uwagami, powstałymi na podstatwie testów i
udokumentowanymi zrzutami ekranu oscyloskopu się zgodzili.
To samo dotyczy firmy Cypress na której PSoC się kiedyś nabrałem.
Never again.

do góry

"Sebastian Biały" <h...@p...onet.pl> wrote in message
news:j3e69o$bom$1@news.onet.pl...

> Niestety to tak nie działa. To działa tak: strona 1: "Supportujemy
> pierdyliard UARTów w hardware, konkurencja klęka!", strona 300: "Wszystkie
> są zjeb..., sorki, ale możecie sobie zrobić softwareowo".

Albo liczyłeś na DMAm które akurat nie działa w twoim przypadku i cała
zabawa do piasku, bo musisz w pętli sypać dane między czymś a czymś.
Albo okazuje się, że nie działają przerwania albo przestają działać jak coś
tam innego zrobisz.

Np co do kontrolerów ethernetowych to łatwiej postawić zewnętrzny niż
kupować droższe PHY do wbudowanego MAC-endżinu :-) Bo i starszy scalak
lepiej znasz i pewnie ma mniej błędów :-)
Ostatnio olewam wbudowane MAC-i byle działało DMA.

do góry