♫ ♩ ♪ The Birthday Massacre ⚡ ☘ ⚡ Red Stars ♪ ♩ ♫
https://youtu.be/GDxYFzxAkWg
Tryptyk Protokolarny
☘
część druga - I2C
Magistrali I2C przedstawiać raczej nie muszę, wiadomo że znana pod alternatywną nazwą TWI (Two Wire Interface) jest jednym z popularniejszych sposobów wewnętrznej komunikacji pomiędzy komponentami systemu mikroprocesorowego. Puzderko AD2 i jego WaveForms stanowią bardzo efektywne narzędzia do analizy przebiegów na szynie I2C, to nie podlega dyskusji. Uważam jednak, że warto również poznać możliwości AD2 SDK w zakresie czynnego udziału w takiej komunikacji, udziału jako master – nadzorca. I o tym dalej.
Będziemy pracować z ekspanderem I/O typu PCF8574 wraz z garstką LED-ów oraz pamięcią EEPROM 24C512:
Noty katalogowe tu:
https://www.nxp.com/docs/en/data-sheet/ ... F8574A.pdf http://ww1.microchip.com/downloads/en/d ... oc1116.pdfSchemat układu doświadczalnego jest banalny, całość podłączona jak poniżej:
Czerwone gwiazdy
Zaczniemy od WaveForms i tego, co udostępniają nam okienka aplikacji – proszę, oto dla wprawy test zapisu bajtu danych do ekspandera PCF8574 celem wyświetlenia wzorka na cudnych staropolskich diodkach LED jarzących się przyjemną czerwienią.
Zauważmy, że dla A2,A1,A0 zwartych do masy jako adres kostki podajemy wartość 0x20, czyli wersję 7-bitową adresu sprzętowego, zgodnie z prawą kolumną w ` Table 4.PCF8574 address map`. Wniosek z tego taki, że bit determinujący zapis/odczyt aplikacja WaveForms dodaje sobie sama, przekształcając wewnętrznie (<< )podaną wartość na efektywny adres 0x40 do zapisu lub 0x41 do odczytu.
Po chwili zabawy z okienkami naszkicujemy program w Pascal, zestaw funkcji do obsługi I2C, podobnie jak dla UART jest sensownie zaprojektowany i zapewnia obsługę typowych przypadków jakie mogą nas spotkać przy pacy z magistralą: konfiguracja + inicjalizacja, odczyt bajtu, zapis bajtu, sekwencja zapis-odczyt danych wielobajtowych.
Do migania ledami wystarczy nam operacja zapisu jednego bajtu do kostki pod zadany adres, czyli kluczowa część programiku z użyciem funkcji FDwfDigitalI2cWrite lub FDwfDigitalI2cWriteOne będzie wyglądała następująco:
i2c_pcf8574_1.lpr pisze:Kod: Zaznacz cały
FDwfDigitalI2cRateSet( hAd2, 500 ); // taktowaie na przykład 500Hz
FDwfDigitalI2cSclSet( hAd2, 0 ); // SCL - DIO_0
FDwfDigitalI2cSdaSet( hAd2, 1); // SDA = DIO_1
FDwfDigitalI2cClear( hAd2, @nak );
if nak = 0 then
begin
writeln( 'I2C err, możliwy problem z zasilaniem lub rezystorami pull-up na SDA/SCL :(' );
exit;
end;
repeat
for i := 0 to length( pattern )-1 do
begin
//FDwfDigitalI2cWrite( hAd2, $40, @pattern[ i ], 1, @nak );
//lub
FDwfDigitalI2cWriteOne( hAd2, $40, pattern[ i ], @nak );
delay ( 100 );
end;
until false;
Cały projekt w lokalizacji:
https://github.com/bienata/AnalogDiscov ... _pcf8574_1Zauważmy, że we wszelkich wywołaniach SDK adres podajemy w formie 8-bitowej, czyli dla naszego ekspandera to będzie 0x40, operujemy wartością do zapisu jako podstawową. Jedynkę na najmłodszym bicie potrzebną do ustalenia adresu do odczytu SDK doda sobie samo (bitowe OR), gdy uzna to za konieczne. To jest pewna niekonsekwencja względem WaveForms i należy o tym drobiazgu pamiętać.
Tradycyjnie krótki filmik z pobłyskującej czerwono instalacji:
https://youtu.be/qNPdQLCzmaY
I dla rozbudzenia tych przysypiających zagadka - co intrygującego/charakterystycznego/nietypowego jest na poniższych oscylogramach przedstawiających przebiegi SDA/SCL?
Tak, dżenderuśny Rigol potrafi pokazać adres w trybie Normal (7-bit) oraz w trybie R/W (8-bit), no fajnie.
Ale co jeszcze? Czas start.
Chora róża
Taki wiersz drzewiej pan William Blake napisał - `The Sick Rose` i w tych klimatach następne demko będzie, gdzie zapoznamy się z operacjami odczytu jedno- i wielobajtowego z pamięci EEPROM. Kostka 24C512 została zaprogramowana pewną zawartością przy pomocy oryginalnego chińskiego (a nie jakiegoś tam europejskiego klona) programatora typu TL866A, fotografia pamiątkowa dla ilustracji:
Dodatkowa informacja taka, że wpisana zawartość uplasowana jest od adresu 0x0000, zawiera kody ASCII w kwocie około 3kB, jako znacznik końca przyjęłam wartość 0xFF, która nie występuje w treści przekazu, za to konsekwentnie wypełnia nieużywany, dalszy obszar pamięci EEPROM.
Choćby pobieżna lektura specyfikacji kostki 24C512 wykaże, że możliwe jest kilka wariantów odczytu danych, z bardziej praktycznych to odczyt bajtu precyzyjnie wskazanego przez 16-bitowy adres oraz odczyt całego ciągłego bloku danych wskazanego przez adres początkowy. Każda metoda ma swoje zalety, wady oczywiście też – popatrzmy zatem na pierwszy przykład:
i2c_24c512_1.lpr pisze:Kod: Zaznacz cały
for i := 0 to $FFFF do
begin
address [0] := (i shr 8) and $ff;
address [1] := i and $ff;
FDwfDigitalI2cWriteRead (hAd2, $A0, @address, 2, @data, 1, @nak );
if data = $a then continue;
if data = $ff then break;
write( char(data) );
end;
Tu mamy odczyt bajt po bajcie i jak nietrudno przewidzieć narzut (pojadę fachowo – overhead) komunikacji jest dość znaczny. Popatrzmy na oscylogram elementarnej transakcji: aby pozyskać jeden bajt danych musimy przesłać wejściowe 2 bajty kontekstu – adres wewnątrz kostki.
Łatwo zgadnąć, że ten sposób czytania jest kosztowny czasowo, z drugiej strony - działamy precyzyjnie.
Drugi wariant odczytu naszej zawartości to transmisja blokowa. Tu na wstępie dialogu z kostką pamięci podajemy jej adres startowy, następnie odbieramy do bufora cały ciągły blok danych, to tak ogólnie. A ponieważ szukamy w treści naszego znacznika 0xFF to nie wciągniemy wszystkiego co jest niczym kreskę nosem, ale podzielimy zabawę na mniejsze bloki po na przykład 256 bajtów. Tu widać wadę - zapewne kiedyś zaczytamy z kostki paczkę danych, z których większość już nas nie będzie interesować. Programik przyjmuje postać:
i2c_24c512_1.lpr pisze:Kod: Zaznacz cały
done := false;
for i := 0 to $ff do
begin
address [0] := i;
address [1] := 0; // czytamy paczkami po 256 bajtow
FDwfDigitalI2cWriteRead( hAd2, $A0, @address, 2, @dataBuff, $ff, @nak );
for x := 0 to $ff do
begin
if dataBuff[x] = $a then continue;
if dataBuff[x] = $ff then
begin
done := true;
break;
end;
write( char(dataBuff[x]) );
end;
if done then break;
end;
Kompletny projekt tu:
https://github.com/bienata/AnalogDiscov ... c_24c512_1Po odebraniu każdego bloku jest on wypisywany na ekran, znacznik 0xFF kończy demonstrację. Oscylogram jednej sekwencji odczytu bloku danych widać poniżej jak i zysk – ile danych dostajemy w zmian za dwubajtowy adres początkowy, który jest już gdzieś hen po lewej stronie diagramu, tu widać złapany jeden z cykli odczytu sekwencyjnego (sequential read):
I ponownie w nawiązaniu do zagadki - skąd wiadomo, że to właśnie odczyt? No skąd?
No i proszę oto finalny materiał filmowy, przy okazji rozjaśni się, skąd moje wczorajsze rojenia o zmianie czcionki w oknie Console Lazarusa.
https://youtu.be/e30jwzvuMJ0
Zauważmy jak czasowo prezentuje się działanie pierwszej, a jak drugiej pętli czytającej kostkę. Narzut samej pętli napędzającej odczyt jest znikomy w porównaniu z czasem konsumowanym przez synchroniczne wywołanie FDwfDigitalI2cWriteRead taktowanej w sumie niewielkim sygnałem zegarowym.
W podsumowaniu
Powyższa pisanina chyba dość dobrze pokazuje z jaką łatwością można w Pascalu (czy innym języku, dla którego dostępnej jest WaveForms SDK) tworzyć własne programiki wykorzystujące AD2 w roli nadzorcy (mastera) komunikacji I2C. W praktyce otwiera to drogę do szybkiego testowania czy poznawania (research) układów z interfejsem I2C, a w sytuacjach awaryjnych umożliwia np. doraźne odczytanie zawartości kostki EEPROM czy zapisanie jej nowym wsadem. No i jak w poprzednim przypadku – mamy sporą elastyczność w wyborze pinów na linie SDA i SCL, to pozwoli uniknąć przekładania kabelków przy pracy z kilkoma układami jednocześnie na przykład podczas testów porównawczych.
#slowanawiatr