Pamięć FRAM (SPI) firmy Cypress i Arduino

[FlyingDutch]

Cześć,

pracuję nad pewnym projektem (dość złożonym opartym na mokro-kontrolerach STM32F103). Ogólnie projekt nadzoruje pewną liczbę kanałów analogowych, do których są podłączone urządzenia elektryczne dość dużych mocy (uC poprzez przetwornik ADC mierzy prądy płynące w kanałach, stan bezpieczników itp). System jest zbudowany modułowo i nowe kanały można dodawać dodając płytkę sterującą z modułem wykonawczym zawierającym 8 kanałów. Moduły są połączone szeregowo magistaralą CAN miedzy sobą i głównym modułem sterującym (który robi też wizualizację stanu wszystkich modułów).  Ostatnio doszły mi nowe założenia dotyczące potrzeby naliczania sumarycznego czasu pracy poszczególnych nadzorowanych kanałów (maksymalnie może ich być 48, czyli 6 modułów sterujących). Czas pracy kanału musi być aktualizowany z dość dużą dokładnością - aktualizacja sumarycznego czasu pracy co 10 sekund. Ponieważ maksymalne czasy pracy urządzeń podłączonych do kanałów mogą wynosić nawet kilkadziesiąt tysięcy godzin potrzebuję do celu rejestracji tych czasów niezawodnych pamięci nieulotnych. Mój wybór padł na kostki pamięci FRAM z magistralą SPI ze względu na olbrzymią możliwą liczbę zapisów (setki trylionów cykli) oraz gwarancję przechowywania zawartości przez długi czas. Użyte w projekcie mikro-kontrolery STM32F103 nie posiadają w swojej strukturze pamięci EEProm jedynie pamięć Flash o max. liczbie cykli około 10 tysięcy, stąd potrzeba dodania kostek pamięci FRAM do płytek kontrolnych (jedna płytka kontrolna będzie pamiętała czasy pracy 8-miu kanałów, które nadzoruje. Stąd wynika potrzeba modyfikacji schematu płytki modułu kontrolnego i druku.

Ponieważ dotychczas nie używałem pamięci FRAM w swoich projektach, zdecydowałem, że wypróbuję działanie pamięci FRAM korzystając z Arduino UNO.  Wybrany przeze mnie typ pamięci FRAM to: 

FM25L16B firmy Cypress (Pamięć FRAM, szeregowa, 16Kb, 2Kbx8, interfejs SPI, obudowa SO8):

https://www.maritex.com.pl/polprzewodniki/pamieci/fram/pamieci_fram/fm25l16b-g.html

Tutaj link do karty katalogowej tej pamięci:

https://www.maritex.com.pl/product/attachment/34271/FM25L16B.pdf

Pamięć ta ma 2KB pojemności i szeregową magistralę SPI, dzięki czemu można ją łatwo podłączyć do CPU STM32F103. Zanim jednak przerobię płytkę kontrolną z STM32 postanowiłem najpierw wypróbować tą pamięć FRAM z Arduino. Znalazłem bibliotekę do "Arduino IDE" dla pamięci FRAM firmy Fujitsu (na Githubie):

https://github.com/adafruit/Adafruit_FRAM_SPI

Jest to pamięć użyta w shieldzie firmy Adafruit (pamięć FRAM firmy Fujitsu o pojemności 8KB z interfejsem SPI):

https://www.adafruit.com/product/1897

Porównałem kartę katalogową pamięci FM25L16B firmy Cypress  z kodem bibliteki do Arduino i okazało się, iż ta pamięć nie obsługuje jednej operacji - mianowicie:

 OPCODE_RDID   = 0b10011111     /* Read Device ID */

Dlatego trzeba było wykomentować użycie tej operacji w metodzie: boolean Adafruit_FRAM_SPI::begin(int8_t cs, uint8_t nAddressSizeBytes)

boolean Adafruit_FRAM_SPI::begin(int8_t cs, uint8_t nAddressSizeBytes)
{
  if (cs == -1)
  {
    //Serial.println("No cs pin specified!");
    return false;
  }

  _cs = cs;
  setAddressSize(nAddressSizeBytes);

  /* Configure SPI */
  pinMode(_cs, OUTPUT);
  digitalWrite(_cs, HIGH);
  //digitalWrite(_cs, LOW);

  if (_clk == -1) { // hardware SPI!
    SPI.begin();

#ifdef __SAM3X8E__
    SPI.setClockDivider (9); // 9.3 MHz
#elif defined(STM32F2XX)
	// Is seems the photon SPI0 clock runs at 60MHz, but SPI1 runs at
	// 30MHz, so the DIV will need to change if this is ever extended
	// to cover SPI1
	SPI.setClockDivider (SPI_CLOCK_DIV4); // Particle Photon SPI @ 15MHz
#else
	SPI.setClockDivider (SPI_CLOCK_DIV2); // 8 MHz
#endif

    SPI.setDataMode(SPI_MODE0);
  } else {
    pinMode(_clk, OUTPUT);
    pinMode(_mosi, OUTPUT);
    pinMode(_miso, INPUT);
  }

  /* Make sure we're actually connected */
  uint8_t manufID;
  uint16_t prodID;
  /*
  getDeviceID(&manufID, &prodID);
  
  Serial.print("Manufacturer ID: 0x"); Serial.println(manufID, HEX);
  Serial.print("Product ID: 0x"); Serial.println(prodID, HEX);

  if (manufID != 0x04 && manufID != 0x7f)//if (manufID != 0x04 && manufID != 0x7f)
  {
    Serial.print("Unexpected Manufacturer ID: 0x"); Serial.println(manufID, HEX);
    return false;
  }
  if (prodID != 0x0302 && prodID != 0x7f7f)
  {
    Serial.print("Unexpected Product ID: 0x"); Serial.println(prodID, HEX);
    return false;
  }
  */
  /* Everything seems to be properly initialised and connected */
  _framInitialised = true;

  return true;
}

Dołączam do postu zmodyfikowaną bibliotekę Arduino dla pamięci FRAM (Cypress):

Adafruit_FRAM_SPI-master.zip

 

Gdy teraz do Arduino UNO załadujemy poniższy program:

#include <SPI.h>
#include "Adafruit_FRAM_SPI.h"

/* Example code to interrogate Adafruit SPI FRAM breakout for address size and storage capacity */

/* NOTE: This sketch will overwrite data already on the FRAM breakout */

uint8_t FRAM_CS = 10;
Adafruit_FRAM_SPI fram = Adafruit_FRAM_SPI(FRAM_CS);  // use hardware SPI

uint8_t FRAM_SCK = 13;
uint8_t FRAM_MISO = 12;
uint8_t FRAM_MOSI = 11;
//Or use software SPI, any pins!
//Adafruit_FRAM_SPI fram = Adafruit_FRAM_SPI(FRAM_SCK, FRAM_MISO, FRAM_MOSI, FRAM_CS);

uint8_t           addrSizeInBytes = 2; //Default to address size of two bytes
uint32_t          memSize;

#if defined(ARDUINO_ARCH_SAMD)
// for Zero, output on USB Serial console, remove line below if using programming port to program the Zero!
   #define Serial SerialUSB
#endif


int32_t readBack(uint32_t addr, int32_t data) {
  int32_t check = !data;
  int32_t wrapCheck, backup;
  fram.read(addr, (uint8_t*)&backup, sizeof(int32_t));
  fram.writeEnable(true);
  fram.write(addr, (uint8_t*)&data, sizeof(int32_t));
  fram.writeEnable(false);
  fram.read(addr, (uint8_t*)&check, sizeof(int32_t));
  fram.read(0, (uint8_t*)&wrapCheck, sizeof(int32_t));
  fram.writeEnable(true);
  fram.write(addr, (uint8_t*)&backup, sizeof(int32_t));
  fram.writeEnable(false);
  // Check for warparound, address 0 will work anyway
  if (wrapCheck==check)
    check = 0;
  return check;
}

bool testAddrSize(uint8_t addrSize) {
  fram.setAddressSize(addrSize);
  if (readBack(4, 0xbeefbead) == 0xbeefbead)
    return true;
  return false;
}


void setup(void) {
  #ifndef ESP8266
    while (!Serial);     // will pause Zero, Leonardo, etc until serial console opens
  #endif

  Serial.begin(9600);
  
  if (fram.begin(FRAM_CS, addrSizeInBytes)) {
    Serial.println("Found SPI FRAM");
  } else {
    Serial.println("No SPI FRAM found ... check your connections\r\n");
    while (1);
  }

  if (testAddrSize(2))
    addrSizeInBytes = 2;
  else if (testAddrSize(3))
    addrSizeInBytes = 3;
  else if (testAddrSize(4))
    addrSizeInBytes = 4;
  else {
    Serial.println("SPI FRAM can not be read/written with any address size\r\n");
    while (1);
  }
  
  memSize = 0;
  while (readBack(memSize, memSize) == memSize) {
    memSize += 256;
    //Serial.print("Block: #"); Serial.println(memSize/256);
  }
  
  Serial.print("SPI FRAM address size is ");
  Serial.print(addrSizeInBytes);
  Serial.println(" bytes.");
  Serial.println("SPI FRAM capacity appears to be..");
  Serial.print(memSize); Serial.println(" bytes");
  Serial.print(memSize/0x400); Serial.println(" kilobytes");
  Serial.print((memSize*8)/0x400); Serial.println(" kilobits");
  if (memSize >= (0x100000/8)) {
    Serial.print((memSize*8)/0x100000); Serial.println(" megabits");
  }
}

void loop(void) {

}

otrzymamy następujący rezulatat:

Found SPI FRAM
SPI FRAM address size is 2 bytes.
SPI FRAM capacity appears to be..
2048 bytes
2 kilobytes
16 kilobits

Patrz zrzut ekranu:

Teraz wystarczy lekko zmodyfikować następny przykład dołączony do biblioteki Arduino, aby wypróbować operacje zapisu do pamięci FRAM (cała przesterzeń adresowa) i odczytu zapisanych wartości:

#include <SPI.h>
#include "Adafruit_FRAM_SPI.h"

/* Example code for the Adafruit SPI FRAM breakout */
uint8_t FRAM_CS = 10;

Adafruit_FRAM_SPI fram = Adafruit_FRAM_SPI(FRAM_CS);  // use hardware SPI

uint8_t FRAM_SCK= 13;
uint8_t FRAM_MISO = 12;
uint8_t FRAM_MOSI = 11;
//Or use software SPI, any pins!
//Adafruit_FRAM_SPI fram = Adafruit_FRAM_SPI(FRAM_SCK, FRAM_MISO, FRAM_MOSI, FRAM_CS);

uint16_t          addr = 0;

#if defined(ARDUINO_ARCH_SAMD)
// for Zero, output on USB Serial console, remove line below if using programming port to program the Zero!
   #define Serial SerialUSB
#endif

void setup(void) {
  #ifndef ESP8266
    while (!Serial);     // will pause Zero, Leonardo, etc until serial console opens
  #endif

  Serial.begin(9600);
  
  if (fram.begin()) {
    Serial.println("Found SPI FRAM");
  } else {
    Serial.println("No SPI FRAM found ... check your connections\r\n");
    while (1);
  }
  
  // Read the first byte
  uint8_t test = fram.read8(0x0);
  Serial.print("Restarted "); Serial.print(test); Serial.println(" times");

  // Test write ++
  fram.writeEnable(true);
  fram.write8(0x0, test+1);
  fram.writeEnable(false);

  fram.writeEnable(true);
  fram.write(0x1, (uint8_t *)"FTW!", 5);
  fram.writeEnable(false);
  //--------------------------------------------------------

}

void loop(void) {
  delay(10);
  //test of writing all memory 2K 
  uint8_t value;
  for (uint16_t a = 0; a < 2048; a++) {
    fram.writeEnable(true);
    delay(1);
    if ((a % 2) == 0) {
       value=0xAA;
       fram.write8(a,value); //0b10101010
    } else {
       value=0x55;
      fram.write8(a, value);  //0b01010101
    }
    delay(1);
    fram.writeEnable(false); 
    delay(1);  
  }

  // dump the entire 2K of memory! ------------------------
  fram.writeEnable(false); 
  for (uint16_t a = 0; a < 2048; a++) {
    value = fram.read8(a);
    delay(1);
    /*
    if ((a % 32) == 0) {
      Serial.print("\n 0x"); Serial.print(a, HEX); Serial.print(": ");
    }
    Serial.print("0x"); 
    if (value < 0x1) 
      Serial.print('0');
      */
    Serial.println(value, HEX); Serial.print(" ");
    delay(1);
    
  }
}

Niestey musiałem dodać kilka instrukcji delay(1), aby zapis i odczyt działały poprawnie. U mnie po uruchomieniu tego zmodyfikowanego programu odczytywałem dokładnie te wartości, które były zapisywane. Teraz kiedy ma wypróbowane działanie tych kostek pamięci, będę mógł je dodać do płytek kontrolnych i zmodyfikować program dla mikro-kontrolerów STM32F103 do ich obsługi.

Ponieważ moje ArduinoUNOI  ma poziomu logiki 5V musiałem w układzie testowym zastosować konwertery pouiomów logicznych - patrz układ testowy (w połączeniu z stm32F103 nie będą one konieczne):

A tutaj zamieszczone przykłady programów dla Arduino:

 

PrzykladrFRAM.zip

 

Mam nadzieję, że obsługa pamięci FRAM firmy Cypres (z interfejsem SPI) przyda się także innym użytkownikom Arduino.

Pozdrawiam

Edytowano Październik 31, 2018 przez FlyingDutch

[marek1707]

A jakie jest pytanie? 🙂

I co chcesz "wypróbować" na Arduino? Masz wersję 3V? Pamięć oczywiście zadziała, krytyczne jest zapewnienie stabilnych warunków podczas zmian stanu zasilania - wczytaj się dobrze w opisy wbudowanych w chip zabezpieczeń dot. sprzętowych i programowych blokad zapisu. W razie czego, jeśli dane są naprawdę ważne pomyśl o kodach kontrolnych lub nawet korekcyjnych.

[Elvis]

Ja używałem FRAM tylko raz i to dość dawno temu. Zapamiętałem dwie rzeczy - były drogie, ale działały bez zarzutu.

Jeśli tylko potrzebujesz zapisywać czas pracy urządzenia, eeprom, czy zwykły flash powinien w zupełności wystarczyć. Liczba cykli dotyczy kasowania i to jednej komórki. W przypadku eeprom to na ogół bajt - czyli mając 1000 bajtów, masz 1000x więcej zapisów. Flash wymaga kasowania stronami / podstronami, które są większe. Jednak typowa pamięć NOR flash pozwala na wielokrotny zapis raz skasowanej strony. Nie możesz zmienić stanu bitu z 0 na 1, bo to wykonuje kasowanie, ale w kolejnych zapisach możesz zmieniać wartość z 1 na 0. Czyli mając powiedzmy sektor 128kB, możesz każdy z miliona bitów zapisywać co 10 sekund... - masz więc 120 dni na jednym cyklu zapisu. Przy 10 tysiącach, pamięć powinna działać 3 tysiące lat 😉

[FlyingDutch]

51 minut temu, Elvis napisał:

Ja używałem FRAM tylko raz i to dość dawno temu. Zapamiętałem dwie rzeczy - były drogie, ale działały bez zarzutu.

Jeśli tylko potrzebujesz zapisywać czas pracy urządzenia, eeprom, czy zwykły flash powinien w zupełności wystarczyć. Liczba cykli dotyczy kasowania i to jednej komórki. W przypadku eeprom to na ogół bajt - czyli mając 1000 bajtów, masz 1000x więcej zapisów. Flash wymaga kasowania stronami / podstronami, które są większe. Jednak typowa pamięć NOR flash pozwala na wielokrotny zapis raz skasowanej strony. Nie możesz zmienić stanu bitu z 0 na 1, bo to wykonuje kasowanie, ale w kolejnych zapisach możesz zmieniać wartość z 1 na 0. Czyli mając powiedzmy sektor 128kB, możesz każdy z miliona bitów zapisywać co 10 sekund... - masz więc 120 dni na jednym cyklu zapisu. Przy 10 tysiącach, pamięć powinna działać 3 tysiące lat 😉

Cześć,

Elvis, nie chce mi się zbytnio kombinować i trochę bałbym się emulacji EEProm we Flashu STM32F103 (bałbym się przypadkowego nadpisania pamięci programu - wiem musiałoby się złożyć na to wiele czynników). Dodanie takiej kostki pamięci nie komplikuje mi mocno płytki. Pomyslę też o liczeniu jakichś sum kontrolnych co zaproponował Marek.

Pozdrawiam wszystkich 🙂

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[ethanak]

Lekko OT... ale mam pytanie.

Kolega naciska na mnie, aby zrobić mu licznik kilometrów (w zasadzie metrów) do motocykla. Nigdy nie używałem FRAM, jak na mój gust idealnie się do tego nadaje... warto się w to bawić?

[FlyingDutch]

2 godziny temu, ethanak napisał:

Lekko OT... ale mam pytanie.

Kolega naciska na mnie, aby zrobić mu licznik kilometrów (w zasadzie metrów) do motocykla. Nigdy nie używałem FRAM, jak na mój gust idealnie się do tego nadaje... warto się w to bawić?

Cześć,

myślę, że tak ;). W tym urządzeniu te aktualizacje muszą być wiarygodne (a przy tej częstotliwości zapisów, z dokumentacji wychodzi mi, że gwarantowany czas "nie zgubienia" zawartości pamięci FRAM wynosi ponad 300 lat). Te pamięci są bardzo tanie dzisiaj - powyższa opisana kostka kosztuje około 4,60 PLN i obudowa SOIP8 (magistrala SPI). Do mojego projektu wydaje mi się to idealne zastosowanie.

Pozdrawiam.

Edytowano Październik 31, 2018 przez FlyingDutch

[marek1707]

Nie podniecaj się. Niezawodność o której tu myślisz nie jest kwestią użycia tej czy innej pamięci. Równie dobrze możesz to zrobić na szeregowym RAMie zasilanym z baterii pastylkowej albo na fragmencie RAMu z jakiegoś RTC, który ma dodatkowo pomiar czasu i system nadzoru zasilania i przełączania źródeł a pobiera 0.5uA. Problem jest w zaprojektowaniu systemu jako całości, począwszy od mechaniki, montażu, poprzez zasilanie a skończywszy na oprogramowaniu. Musisz zapewnić odpowiednie warunki delikatnej elektronice, stabilne zasilanie bez zapadów podczas pracy rozrusznika, bez szpilek od szwankującego systemu zapłonowego itp, pracujące w szerokim zakresie napięć, temperatur, wilgotności i wstrząsów. Bez jednoczesnego zrobienia tego wszystkiego możesz tylko łudzić się tryliardem możliwych zapisów do FRAMu a urządzenie i tak w końcu przestanie działać i zostanie wyrzucone po jednym sezonie. Jeśli kod zgłupieje od zakłócenia przewodzonego lub promieniowanego - leżysz, jeśli nie zadbasz o stan linii CS czy WP także (a może nawet przede wszystkim) podczas włączania i wyłączania zasilania - leżysz, itd itp. Nawet jeśli użyłeś złej żywicy do uszczelnień lub choćby nie umyłeś dobrze płytek przed zalewaniem Twoja elektronika jest po roku zjedzona wilgocią i chemią. Co tu więc mówić o porównywaniu tej czy innej pamięci. Oczywiście, w warunkach laboratoryjnych, gdy na biurku napisałeś sobie trochę kodziku z zapisami i odczytami przez druciki to FRAM ma wyższość na EEPROMem z samych założeń konstrukcyjnych. Niestety są to cechy drugorzędne w świecie rzeczywistym - nie bądź dzieckiem, daj się zwieść folderom reklamowym. W elektronice do motoru zacznij od wybrania miejsca montażu, znalezienia szczelnej obudowy, sposobu amortyzacji płytek, ich zalania, przepustów kablowych, systemu zasilania, filtrów itd..A dopiero gdzieś tam na fafnstym miejscu możesz się zastanowić nad wyborem układu.

[kaczakat]

Jak się komuś nie spieszy to polecam: I2C (11/11 będą po 48c przy 10szt) również konieczna jest modyfikacja biblioteki, ale można się wzorować na Adafruit, działają bardzo podobnie, kupiłem sobie też SPI 256kb 10 za około 12$ SPI, ale tych jeszcze nie wypakowałem, choć powinno być mniej problemów z adresami.

[FlyingDutch]

34 minuty temu, marek1707 napisał:

Nie podniecaj się. Niezawodność o której tu myślisz nie jest kwestią użycia tej czy innej pamięci. Równie dobrze możesz to zrobić na szeregowym RAMie zasilanym z baterii pastylkowej albo na fragmencie RAMu z jakiegoś RTC, który ma dodatkowo pomiar czasu i system nadzoru zasilania i przełączania źródeł a pobiera 0.5uA. Problem jest w zaprojektowaniu systemu jako całości, począwszy od mechaniki, montażu, poprzez zasilanie a skończywszy na oprogramowaniu. Musisz zapewnić odpowiednie warunki delikatnej elektronice, stabilne zasilanie bez zapadów podczas pracy rozrusznika, bez szpilek od szwankującego systemu zapłonowego itp, pracujące w szerokim zakresie napięć, temperatur, wilgotności i wstrząsów. Bez jednoczesnego zrobienia tego wszystkiego możesz tylko łudzić się tryliardem możliwych zapisów do FRAMu a urządzenie i tak w końcu przestanie działać i zostanie wyrzucone po jednym sezonie. Jeśli kod zgłupieje od zakłócenia przewodzonego lub promieniowanego - leżysz, jeśli nie zadbasz o stan linii CS czy WP także (a może nawet przede wszystkim) podczas włączania i wyłączania zasilania - leżysz, itd itp. Nawet jeśli użyłeś złej żywicy do uszczelnień lub choćby nie umyłeś dobrze płytek przed zalewaniem Twoja elektronika jest po roku zjedzona wilgocią i chemią. Co tu więc mówić o porównywaniu tej czy innej pamięci. Oczywiście, w warunkach laboratoryjnych, gdy na biurku napisałeś sobie trochę kodziku z zapisami i odczytami przez druciki to FRAM ma wyższość na EEPROMem z samych założeń konstrukcyjnych. Niestety są to cechy drugorzędne w świecie rzeczywistym - nie bądź dzieckiem, daj się zwieść folderom reklamowym. W elektronice do motoru zacznij od wybrania miejsca montażu, znalezienia szczelnej obudowy, sposobu amortyzacji płytek, ich zalania, przepustów kablowych, systemu zasilania, filtrów itd..A dopiero gdzieś tam na fafnstym miejscu możesz się zastanowić nad wyborem układu.

Cześć Marek,

oczywiście masz rację. Zdaję sobie sprawę z większości zagrożeń o których napisałeś. Z kolegami elektronikiem i mechanikiem z którymi pracuję nad tym  projektem aktualnie pracujemy nad czwartą wersją płytek drukowanych do tego systemu i obudów (a także wiązek okablowania) , właśnie z powodów o których napisałeś. Staramy się zapewnić izolację od zakłóceń, lepiej zaprojektować druk i płytki dla modułów wykonawczych (nie wszystko działało tam tak jakbyśmy chcieli). Lepiej zaprojektować obudowy, tak aby było lepsze odprowadzanie ciepła, aby wyprowadzenia złącz były wygodniejsze w montażu, szczelność obudowy była odpowiednia. Wiem, że nie jest to łatwe i jest to raczej proces powolnego dochodzenia do założonych parametrów. Staramy się tak zaprojektować cały układ tak, aby pewne założenia nie stanowiły już na początku "wąskiego gardła" sytemu (stąd np. wybór magistrali CAN do komunikacji między modułami). Staram się też ulepszać ciągle kod całej aplikacji. Rozwiązanie z wykorzystaniem pamięci konfiguracji zegara RTC (podtrzymywanego  baterią pastylkową) mieliśmy w poprzedniej wersji płytek i nie za bardzo się sprawdziło (z różnych powodów - nie chciałbym się teraz na ten temat za dużo rozpisywać). Mamy także matrycę diód LED (16 wierszy na 8 kolumn) do wizualizacji stanu systemu , która była wykonana we wcześniejszych wersjach płytek na dyskretnych tranzystorach MOSFET (do montażu SMD), które to rozwiązanie nie sprawdziło się ponieważ pojawiały się na tych elementach błędy lutowania. Teraz są to trzy układy scalone  gdzie montaż nie nastręcza już problemów i jest łatwiejsze odprowadzanie wydzielanego ciepła  (i łatwo jest dokonać wymiany uszkodzonego modułu). To nie jest elektronika do motoru, aczkolwiek warunki w których pracuje są ciężkie (zarówno atmosferyczne jak i poziom zakłóceń).

Ten post napisałem z myślą o użytkownikach forum, którzy być może chcieliby wykorzystać pamięci FRAM w swoich projektach opartych na Arduino - taki był cel. Docelowy schemat i kod (dla STM32F103) użycia tych pamięci i tak będzie inny.

Pozdrawiam

[marek1707]

Ojej, ale ja właśnie nie do Ciebie pisałem, bo wszystko to było w kontekście bardzo wymagającej elektroniki samochodowo-motocyklowej i pytania ethanaka o licznik (kilo)metrów. Wydało mi się naiwnym podejście od d..., no od tylnej strony czyli wyboru elementów wg folderu reklamowego a potem drapaniu się w głowę co dalej.. Mamy FRAM, producent pisze że jakiś centezylion zapisów więc się nada. Oczywiście fajnie jest poeksperymentować i Twój druciak z Arduino posłużył mi za przykład zabawki nie mającej żadnego odniesienia do morderczych warunków rzeczywistych, ale jakoś w Twoim wypadku mam pewność, że sobie poradzisz a docelowy układ będzie sporo odbiegał od zamieszczonego zdjęcia 🙂 Powodzenia.

Jeżeli macie kłopoty z lutowaniem, to podrążcie temat. Czy elementy stare i wymagały wygrzewania po magazynowaniu, czy profil SMT nie teges, czy pokrycie PCB spaprane itd.. Zmiana tranzystorów na scalaki mogła tylko przykryć prawdziwy problem a takich rzeczy nie powinno się zamiatać pod dywan, szczególnie gdy macie poważniejsze plany co do rozwoju systemu. Może czasem warto - nawet przy seriach prototypowych - oddać się w ręce fachowców zamiast rzeźbić samemu? Czasem jeden rzut oka doświadczonego technologa i wiesz, że tu, tu i tu będą kłopoty z montażem/lutowaniem. Ja często korzystam z takich ocen i rad (przed skierowaniem projektu do produkcji, nawet w serii 20 sztuk prototypów) i za każdym razem jestem zaskoczony tym co wynaleźli. Inna sprawa, że nie są to płytki z trzema elementami na krzyż.. Warto też jak najwcześniej myśleć o testowaniu: o łatwym dostępie do złącz/padów testowych czy programujących, o samym testerze pakietów itp.

[FlyingDutch]

28 minut temu, marek1707 napisał:

Jeżeli macie kłopoty z lutowaniem, to podrążcie temat. Czy elementy stare i wymagały wygrzewania po magazynowaniu, czy profil SMT nie teges, czy pokrycie PCB spaprane itd.. Zmiana tranzystorów na scalaki mogła tylko przykryć prawdziwy problem a takich rzeczy nie powinno się zamiatać pod dywan, szczególnie gdy macie poważniejsze plany co do rozwoju systemu. Może czasem warto - nawet przy seriach prototypowych - oddać się w ręce fachowców zamiast rzeźbić samemu? Czasem jeden rzut oka doświadczonego technologa i wiesz, że tu, tu i tu będą kłopoty z montażem/lutowaniem. Ja często korzystam z takich ocen i rad (przed skierowaniem projektu do produkcji, nawet w serii 20 sztuk prototypów) i za każdym razem jestem zaskoczony tym co wynaleźli. Inna sprawa, że nie są to płytki z trzema elementami na krzyż.. Warto też jak najwcześniej myśleć o testowaniu: o łatwym dostępie do złącz/padów testowych czy programujących, o samym testerze pakietów itp.

Cześć,

prawie wszystkie problemy, które opisałeś występowały (np. problem odpowiedniego wygrzewania elementów po magazynowaniu itp.). Właśnie w nowych wersjach płytek PCB są dodane złącza (np. do kalibracji torów pomiarowych analogowych - użyte czujniki Halla ze wzmacniaczami pomiarowymi). Złącza testowe, napisałem ostatnio sporo kodu do testowania i wspomagania uruchamiania nowych modułów itp, testowania poprawności działania magistrali CAN, testów matrycy LED itp. i dużo innych testów automatycznych.

Powodzenie się przyda - dziękuję 😉

Pozdrawiam

[ethanak]

@marek1707- nie ma problemu, po pierwsze zdaję sobie sprawę ze wszystkich trudności, po drugie na szczęście do mnie należałby tylko projekt elektroniki (nawet bez płytki, kolega motocyklista jest lepszy w te klocki ode mnie) i program.

[FlyingDutch]

Cześć,

Marek, czy mógłbyś polecić jakiś konkretny kod korekcji błędów?  Docelowo chciałbym go zaimplementować przy obsłudze tej pamięci FRAM w układzie z STM32.

Pozdrawiam

[Gość es2]

53 minuty temu, FlyingDutch napisał:

Marek, czy mógłbyś polecić jakiś konkretny kod korekcji błędów?

Kody korekcyjne znacznie zwiększą wielkość danych a "naprawić" można ich niewiele. Jak dobrze pamiętam, aby wykryć i naprawić 1 bit w bajcie, potrzeba 4 bitów. Rozmiar danych wzrasta więc o o30% a odzyskasz 12,5%.

Chyba najrozsądniejszym rozwiązaniem, będzie CRC i dwie kopie danych.Jeśli pamięć jest dzielona na strony/sektory, to trzeba zadbać aby druga kopia zaczynała się od nowej strony/sektora.W przypadku FRAM takiego podziału nie ma. Warto jednak, aby druga kopia zaczynała się od adresu WIELKOSC_FRAM /2.

[FlyingDutch]

55 minut temu, es2 napisał:

Kody korekcyjne znacznie zwiększą wielkość danych a "naprawić" można ich niewiele. Jak dobrze pamiętam, aby wykryć i naprawić 1 bit w bajcie, potrzeba 4 bitów. Rozmiar danych wzrasta więc o o30% a odzyskasz 12,5%.

Chyba najrozsądniejszym rozwiązaniem, będzie CRC i dwie kopie danych.Jeśli pamięć jest dzielona na strony/sektory, to trzeba zadbać aby druga kopia zaczynała się od nowej strony/sektora.W przypadku FRAM takiego podziału nie ma. Warto jednak, aby druga kopia zaczynała się od adresu WIELKOSC_FRAM /2.

Cześć,

akurat miejsca w pamięci FRAM mam z dużym zapasem.  Twoja koncepcja, aby liczyć jakiś rodzaj sumy CRC i trzymać dwie kopie danych podoba mi się.

Pozdrawiam