[Ku pamięci] Online Gerber viewer

Jakiś już czas temu natknąłem się na fajną stronkę do oglądania plików gerber. Ostatnio musiałem się znowu jej trochę naszukać więc wrzucam ją tu aby mieć na przyszłość :)

http://mayhewlabs.com/webGerber/

USB VID i PID dla każdego od NXP

Następna niespodzianka od NXP.
Dla osób które tworzą urządzenia z USB i wykorzystują do tego celu mikrokontrolery z rodziny LPC11Uxx producent umożliwia uzyskanie do 3 darmowych numerów PID.
Dzięki temu nie musimy płacić za członkostwo w USB-IF. Minusem niestety jest to, że licencja obejmuje tylko do 10k urządzeń.

Czekamy teraz na podobny program dla LPC13xx , LPC17xx i pozostałych :)

Źródło: http://www.lpcware.com/content/project/usb-vid-pid-program

"Product Longevity Program" dla mikrokontrolerów NXP z rdzeniem ARM Cortex-M

Ostatnio będąc na szkoleniu Freescale firma ta chwaliła się, że jako jedyna gwarantuje, że ich mikrokontrolery będą produkowane przez ileś następnych lat.

Okazuje się, że NXP postanowił również uruchomić podobny program. Firma gwarantuje, że mikrokontrolery z rdzeniem Cortex-M będą w ofercie co najmniej przez 10 lat od wprowadzenia do sprzedaży. Na razie programem objęte są najprostsze mikrokontrolery z rodziny LPC11xx (rdzeń Cortex-M)

źródło: http://www.nxp.com/news/press-releases/2012/03/nxp-introduces-longevity-program-for-arm-cortex-m-microcontrollers.html

Nowe procki od NXP

No no, portfolio mikrokontrolerów z rdzeniem Cortex M3 od NXP ciągle się powiększa. Robi się coraz ciekawiej :)
http://www.nxp.com/news/press-releases/2012/03/nxp-expands-memory-options-for-popular-lpc1300-family-of-usb-microcontrollers.html

Kolejny eval board do kolekcji - KwikStik

Takie ot cudeńko otrzymałem na szkoleniu Freescale. Pierwszy mój eval z rdzeniem Cortex M4 (mikrokontroler Freescale K40X256)

Szczegóły na  http://www.kinetis.pl/node/42

Używanie słówka kluczowego inline zamiast makr w C

Dobry kod zawiera zwykle dużą liczbę relatywnie małych funkcji czy metod, które mogą być łączone ze sobą na wiele sposobów (jak klocki Lego). Często jednak pisząc kod tworzymy mniej, bardziej złożonych i mniej uniwersalnych funkcji. Sprawia to, że kod jest bardziej podatny na błędy i często sprawia problemy przy testowaniu czy szukaniu błędów.

Często powodem takiego stanu rzeczy jest nieużywanie małych funkcji aby nie obniżać wydajności systemu. Ciągłe wywoływanie  małej funkcji może znacznie zmniejszyć prędkość wykonywania całego programu. Oczywiście można zainwestować w szybszy procesor ale nie zawsze jest to możliwe do wykonania. Może nam zależeć na minimalizacji czasu wykonania jakiejś funkcji.

Rozważmy taki przykład. Mamy funkcję, która dodaje 1 do jakiejś wartości ale z tzw. nasyceniem aby nie przekroczyć maksymalnej wartości (żeby zmienna się nie "przekręciła"):

  int SaturatingIncrement(int x)
  { if (x != MAXINT)
    { x++;
    }
    return(x);
  }

Możemy mieć więc kod wyglądający jak poniżej:
  ...
  x = SaturatingIncrement(x);
  ...
  z = SaturatingIncrement(z);

Na pewno zauważysz, że jeśli wielokrotnie funkcja ta będzie wykonywana to kod będzie wykonywał się wolno. Zwykle rozwiązania są 2. Niektórzy, kopiują kod z funkcji i używają go mniej więcej tak:
  ...
  if (x != MAXINT)  { x++; }
  ...
  if (z != MAXINT)  { z++; }

Dużym problemem z tym jest to, że jeśli znajdziesz błąd, musisz przejrzeć cały program i poszukać wszystkich wystąpień takich fragmentów kodu i ręcznie je poprawić.

Trochę lepszym rozwiązaniem jest użycie makr:
#define SaturatingIncrement(w)  { if ((w) != MAXINT)  { (w)++; } }

które, pozwala wrócić mniej więcej do oryginalnego kodu. Kod więc może wówczas wyglądać tak:
  ...
  SaturatingIncrement(x);
  ...
  SaturatingIncrement(z);

ale preprocesor wykryje użycie makra i zamieni to na taki kod dla kompilatora:
  ...
  if (x != MAXINT)  { x++; }
  ...
  if (z != MAXINT)  { z++; }

eliminując tym samym kilka niepotrzebnych taktów przy wywołaniu funkcji.

Fajną rzeczą w makrach jest to, że jeśli znajdziesz błąd to musisz poprawić go tylko w jednym miejscu i sprawia, że kod jest dużo bardziej czytelny. Tak czy inaczej złożone makra mogą być niewygodne i być źródłem tajemniczych błędów (np. wiesz dlaczego jest "(w)" zamiast po prostu w?).

Dobrą wiadomością jest to, że we większości kompilatorów C jest lepsze rozwiązanie. Zamiast używać makr można użyć funkcji ze słówkiem kluczowym "inline".

  inline int SaturatingIncrement(int x)
  { if (x != MAXINT)
    { x++; }
    return(x);
  }

Słówko inline mówi kompilatorowi aby rozwinął kod funkcji w linii gdzie wywołana jest funkcja (tak jak makro). Ale zamiast zamiany tekstu w preprocesorze jest do dokonywane przez sam kompilator. Można więc pisać tyle funkcji inline ile się chce bez płacenie niepotrzebnymi taktami zegara. Dodatkowo, kompilator sprawdzi poprawność typów czy inne analizy aby pomóc wykryć błędy co nie było możliwe z makrami.

Można się jednak spotkać z kilkoma dziwactwami związanymi z inline. Niektóre kompilatory ignorują słówko inline jeśli funkcja przekracza jakąś określoną liczbę linii kodu. Inne z kolei pozwalają wywołać w ten sposób funkcje która jest zdefiniowana w tym samym pliku .c. Niektóre kompilatory muszą mieć zaznaczoną flagę aby wymusić inline zamiast zwykłego słówka inline przy definicji funkcji. Niestety aby być pewnym, że inline działa poprawnie, trzeba sprawdzić kod wyjściowy (w asemblerze) i zobaczyć jak nasz kompilator to obsługuje.

Nowe zastosowania dla rejestrów RTC

Chcę dzisiaj pokazać nowe zastosowanie rejestrów zegara czasu rzeczywistego, które są dostępne w niektórych (wielu?) procesorach ARM jak również jak podejrzewam we wielu innych architekturach. Fragment z dokumentacji procesora firmy NXP przedstawiłem na rysunku poniżej.

Rejestry RTC procesorów z rodziny LPC17xx

Najbardziej interesująca jest kolumna Reset Value. Można zauważyć, że wartości zaznaczone na czerwono mają wartość "NC". "NC" oznacza, że rejestry te są nienaruszone podczas resetu procesora. Ponadto, rejestry te mogą być również zasilane z alternatywnego źródła zasilania, więc są one również odporne na utratę zasilania. Do czego to się przydaj? Otóż znalazłem kilka zastosowań dla nich poza oczywistym przeznaczeniem jakim jest przechowywanie daty i czasu (dla rejestrów RTC) i zapewnienia nieulotnej pamięci przez rejestów ogólnego przeznaczenia (General Purpose Registers).

Komunikacja z Bootloaderem
Większość dzisiejszych aplikacji wbudowanych zawiera program ładujący (bootloader). Chociaż istnieje kilka sposobów uruchamiana bootloadera, to najpopularniejszym i dostępnym we większości mikrokontrolerów sposobem jest wymuszenie resetu przez watchdog. Jednak sam reset nie wystarczy. Wymagana jest zwykle jakaś komunikacja między główna aplikacją a aplikacją ładującą. Bootloader musi co najmniej wiedzieć, że został celowo uruchomiony w celu wykonania aktualizacji oprogramowania a nie zostało to spowodowane przez błąd w programie i nieprzewidziany reset przez watchdoga. Może również się zdarzyć, że wymagana będzie informacja o tym z jakiego źródła ma być pobrany nowy program. W przeszłości istniała tendencja do przekazywania tych informacji poprzez pamięć EEPROM. Teraz mając powyższe rejestry można je wykorzystać do tego celu.

Debugowanie
Jeśli borykasz się z niespodziewanymi resetami systemu, to jest to stosunkowo prostą sprawą, aby napisać kilka linii kodu, który zapisuje w tych rejestrach informacje o kontekście. Na przykład większość RTOSów zapewnia mechanizmy wywołania funkcji użytkownika przez przełączeniem zadania. W funkcji tej banalne jest zapisanie do jednego z rejestrów ID zadania. Wtedy to tylko kwestia ustawienia breakpointa na wejściu do funkcji main() i odczyt które zadanie było uruchomione w momencie resetu. Zawężenie podejrzanych bardzo ułatwia sprawę.

Podejrzewał, że można znaleźć jeszcze wile zastosowań tych rejestrów. Na prawdę chciałbym aby rejestry tego typu były powszechne i dostępne w każdej rodzinie procesorów.