Kysymys:
Miksi STM32F4-keskusyksiköissä ei ole EEPROMia?
scico111
2019-02-20 04:14:07 UTC
view on stackexchange narkive permalink

Miksi STM32F4-sarjan MCU: eissa ei ole EEPROMia?

Minulla on enimmäkseen Microchip MCU: ita ja niissä on käytettävissä EEPROM, mutta huomasin juuri, että sitä ei ole saatavana STM32F4 MCU: ista ... Ja näyttää siltä, ettei muissa perheissä, kuten 'F0, F1, F2 ja F3joko.

Onko parametrin arvojen tallentamiseen mahdollista EEPROM: n puuttuessa?

"Mikä voisi olla hyvä syy?"kysymykset eivät sovi Stack Exchangen tehtävään, ja "niin tärkeä muistialue" on hyvin ** sovelluksen mukainen **.STM32L4: ssä ei näytä olevan EEPROMia, mutta L0: lla ja L1: llä on se.Tai voit lisätä ylimääräisen sirun, jos sinulla on tarve, johon emulointi ei toimi.
Onko emuloidun eepromin vs. ulkoisen eeprom-sirun käyttö tarpeeksi turvallista?
Se olisi täysin * sovelluksesta riippuvainen *.Koska et ole sanonut mitään siitä, mitä yrität tehdä kysymyksessä, jonka on otettava huomioon yksityiskohdat äärimmäisen yksityiskohtaisesti, kukaan ei voi auttaa sinua.
Todennäköisin selitys on, että sovellus (t), joille siru alun perin kehitettiin, ei tarvinnut sitä.Muista, että JOKA koskaan kehitetty siru on suunniteltu tiettyä suurikokoista sovellusta varten, ja vasta myöhemmin se on lisätty valmistajan yleiseen luetteloon.Uuden sirumallin yläraja on aivan liian korkea, jotta siruja voidaan suunnitella spekulatiivisesti.
"niin tärkeä muistialue" - kenelle tärkeä?Työskentelen parhaillaan projektissa, jossa käytetään STM32F4-laitetta, eikä minulla olisi mitään hyötyä pienestä sisäisestä EEPROMista.Lisäkustannukset, jotka se lisäisi laitteeseen, tekisi varmasti eron.
Pienet määrät kaikkea ei välttämättä ole kallista, mutta mittakaavassa, miljoonina määrinä, yksikön kokonaiskustannuksina, se voi olla hyvin merkittävä.
Tarvitset siihen L0-sarjan.Emuloitu EEPROM ohjelman salamassa on todella työläs työskennellä, suosittelen voimakkaasti, että pysyt poissa siitä.
Ehkä valmistajat syyttävät sitä, että on parempi antaa EEPROMia tarvitseville asiakkaille pienet kustannukset sen ulkoisesta lisäämisestä sen sijaan, että kuormittaisivat kaikkia asiakkaita sisäisen EEPROM: n kustannuksilla, joita monet tai useimmat asiakkaat eivät tarvitse.
Kolme vastused:
duskwuff -inactive-
2019-02-20 04:20:56 UTC
view on stackexchange narkive permalink

Kaikissa STM32-keskusyksiköissä on itse ohjelmoitava flash-muisti.Jos sinun on tallennettava käyttäjäasetukset, voit tallentaa ne salama-alueelle.

ST tarjoaa kirjaston EEPROM-emuloinnin suorittamiseksi STM32F4: llä.(Samankaltaisia kirjastoja on myös suurimmaksi osaksi niiden muista osista.) Vaikka et aio käyttää kyseistä kirjastoa, heidän sovellushuomautuksensa, joka selittää sen toiminnan, saattaa olla mielenkiintoista lukea.>

Tämä on oikein, mutta se on huono korvike.Suoritin ei voi toimia, kun salamaa kirjoitetaan tai pyyhitään, ja pyyhkiminen kestää kauan.On temppuja (multi flash-pankit, ram-toiminnot), mutta yksikään ei ole yhtä siisti kuin vain sisäinen eeprom kuten AVR ja PIC.
@Jon: llä 577 Microchip PIC32- ja Atmel 32-bittistä MCU: ta, jotka ovat tällä hetkellä tuotannossa, vain 63: lla on Data EEPROM.https://www.microchip.com/ParamChartSearch/chart.aspx?branchID=211&popular=1
@Jon, Etkö ole varma, miksi uskot "Suorittimen suorittaminen ei onnistu, kun salamaa kirjoitetaan tai tyhjennetään ..." Olen käyttänyt tätä menetelmää F1-laitteessa.Jos suoritin olisi pysähtynyt Flashiin kirjoituksen aikana, luulen, että olisin huomannut
@user28910, se ei ole mielipiteen asia.Se on tuotedokumentaatiossa.Ehkä käytit kaksoispankkilaitetta (suurempia).Ne voidaan suorittaa ulos yhdestä pankista kirjoittaessaan toiselle, mutta tämä tarkoittaa sinun tarvetta pitää kaikki asiaankuuluvat koodit oikeassa pankissa.
@Bruce Abbott mielenkiintoinen asia.Tiesin, että siruja oli ilman eepromia, mutta en tiennyt, että se oli niin laaja.
@user28910 Hän tarkoittaa, että hän ei voi suorittaa koodia samalta flash-pankilta, jota kirjoitetaan / poistetaan.Mikä pätee mihin tahansa MCU: han markkinoilla, ja huomaat varmasti, koska se ripustaa tai menee hajanaiseen.On täysin mahdollista suorittaa flash-kirjoitinohjain yhdestä pankista samalla kun ohjelmoidaan toista.Tai todellakin suorittaa koodi RAM-muistista.Se on edelleen köyhän miehen EEPROM ja huono ratkaisu.
Vaikka tämä on hyödyllinen käytännön ratkaisu toimenpideohjelman todelliseen ongelmaan, se ei vastaa kysymykseen "miksi", eikä sitä olisi pitänyt hyväksyä vastauksena.IMnsHO.
elchambro
2019-02-20 10:42:05 UTC
view on stackexchange narkive permalink

EEPROM on solukooltaan erittäin kallista (johtaa suurempaan kuolemaan ja siten korkeampiin kustannuksiin).Valmistajat alkoivat yrittää päästä eroon EEPROMista heti, kun ensimmäiset Flash-pohjaiset ohjaimet julkaistiin.

Etenkin kun otetaan huomioon EEPROM-määrän vaihtelevat käyttäjien vaatimukset, on järkevämpää jäljitellä Flashissa rajoituksista huolimatta.Toisin kuin (esimerkiksi) kiinteällä 512 tavulla EEPROMia, kun yksi asiakas käyttää vain 20 tavua, mutta maksaa 512: sta.

On kuitenkin olemassa datasalama, joka käyttäytyy melko samanlaisesti kuin EEPROM, kirjoitusjaksojen jne. Kannalta. Mutta vaatii usein monien tavujen poistamisen, kuten esimerkiksi 8 tavun palat kerrallaan.Ohjelmasalaman pyyhkimiskoko on valtava.
Jarhmander
2019-02-20 21:46:19 UTC
view on stackexchange narkive permalink

Jos haihtumaton muisti, joka on ohjelmoitava ja tavutason pyyhittävä, on tärkeää (toisin kuin Flash-muisti, jossa kokonaiset sektorit / sivut on poistettava), katso STM32L0ja STM32L1 -sarja.Heihin on upotettu todellisia EEPROM-tietoja.



Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 4.0-lisenssistä, jolla sitä jaetaan.
Loading...