AT91SAMS764 - błąd?

Witam wszystkich.

Jestem po pierwszych bojach z tym procem. Wrażenie dość miłe, przynajmniej na razie, jednakże... Przy zabawie z SPI (pomijając moje, jak to na początku bywa banalne błędy) wystąpił następujący problem: SPI włączone w trybie "master", "Variable Peripheral Select" z włączonym CSAAT w SPI_CSRx. Wpisując pierwszą daną do SPI_TDR, odpowiednia linia NPCS przyjmuje stan LO i go utrzymuje. Kolene dane są wysyłane poprawnie. No i wysyłam ostatni bajt ustawiając w SPI_TDR flagę LASXFER. Po wysłaniu tego bajtu odpowiednia linia powinna zmienić stan na HI. Tak się jednak nie dzieje, pozostaje stan LO... Po różnych próbach zauważyłem, że:

-jeśli włączony jest dzielnik FDIV w SPI_MR sytuacja wygląda tak, jak opisałem;

-jeśli jednak nie używam FDIV, zakończenie komunikacji (ustawiony LASXFER) działa poprawnie.

Nie wiem, czy to ja, czy on popełnia błąd. W "dejtaszicie" nic nie wyczytałem na ten temat (no chyba, że coś mi na oczy poszło).

Spotkał się ktoś z tym problemem? A może są jeszcze jakieś inne kruczki, o których wypadałoby wiedzieć?

Pozdrawiam M

Reply to
Meleks
Loading thread data ...

Witam,

W układzie tym mogą być różne dziwne kwiatki. Jeśli nie jest to opisane w erracie - zapytaj producenta. Ja np. znalazłem brak w dokumentacji - SSC potrafi taktować transmisję tylko podczas wysyłania ważnych danych pod warunkiem że wybierzemy tryb 2 który nie jest opisany w dokumentacji. Kolejna rzecz to timery - zdarzenie "Compare A" nie zgłasza u mnie przerwania, natomiast B i C działają bez problemu.

Paweł

Użytkownik "Meleks" snipped-for-privacy@poczta.neostrada.pl> napisał w wiadomości news:opssh70706r58qyv@rafal...

Reply to
invalid unparseable

No, to nie wiem teraz, czy wybór tego układu jako poligon doświadczalny był dobrym pomysłem. Jednak z drugiej strony, jak wszystko od początku idzie jak po maśle, to wiadomo, że kiedyś pieprznie, nie wiadomo jednak kiedy, ale wiadomo na pewno, że w jak najmniej odpowiednim momencie :-) Jak na razie na nim (AT91...) bedę uprawiał swoje eksperymenty. A tak przy okazji, nie ma jakiejś "upublicznionej" listy bugów tego procka? Zapewne przydałaby sie wielu ludziom. Zaoszczędziłaby duuużo czasu na szukanie błędów w programie, których nie ma :-)

No i jeszcze to: Jak szybko producent reaguje (poprawia błędy) na sugestie użytkowników? Nigdy nie miałem z tym do czynienia :-) Do tej pory "trafiały mi się" sprawdzone układy :-)

Pozdrawiam M

Reply to
Meleks

Proponuję poczytać dokument-erratę ze strony Atmela.

Paweł

Reply to
invalid unparseable

Producent reaguje zwykle wypuszczając (z dużym opóźnieniem) stosowne erraty. Natomiast na poprawianie błędów się nie nastawiaj - procesory AT91SAM7Sxx mają dużo błędów identycznych z większym bratem AT91RM9200, które wciągnęli z dobrodziejstwem inwentarza tworząc serię 'SAM' (porównaj erraty). Niewykluczone, że w SAM'ach potwierdzą się też inne błędy już obczajone w '9200 - warto poczytać erratę tamtego procesora i najlepiej też kilku podobnych wynalazków Atmela.

Absolutnym rekordzistą w niepoprawianiu błędów sprzętu jest wg mnie Texas Instruments. Znane problemy w procesorach DSP propagują się już przez kilka kolejnych scalaków (przeszły z poprzedniej serii), a erraty tylko rosną. Wiele błędów nie ma obejścia (workaround: none) więc od sprytu kompilatora C (lub programisty w asemblerze) często zależy, czy kod wynikowy będzie miał szansę działać.

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.