Ezt a fúziós periféria dolgot szerintem mind a Microchip mind pedig az Atmel most már csak ugatja.

Amíg egy ATmega8-al egyenértékű (illetve többet is tudó) ST mikrovezérlő 20-30 db-os ára 70-80 Ft, addig szerintem nincs miről beszélni. Tessék csak megnézni: STM8S003 vagy STM8S005.
Ez az ATMEL felvásárlós dolog fejlesztők és gyártók számára csak azt hozta ahogy most már látom a piacon, hogy pártolnak át a bizonytalanság miatt. Az ST viszont remekül jön ki jelenleg ebből.

16MHz órajel, 8K flash, 1K RAM, több 16 bites timer, beeper hardver, stb, 80 Ft-ért. Jó, tény, hogy nem is gyártanak a hobby világnak szóló DIP tokos mikrovezérlőt.

Wbt: Arra gondolt a költő, hogy ideje a 8-bites architektúrának követnie az ijesztő mértékben növő ARM piacot, ahol gyakorlatilag minimális (avagy semmilyen) módosítással ugrálhatsz mikrovezérlők között, periféria kínálat, stb. között. Elképzelésem szerint ezt akarhatták célnak ezzel a fúzióval, csak a gyanúm, hogy elkéstek fele. STM8-ra is teljesen ingyenes C fordító áll rendelkezésre, az ARM-okkal is ez a helyzet (gcc), annyi különbséggel, hogy ott a fizetős IAR valóban fényévekkel jobb, szebb és stabilabb gépi kódot ad.
Sem az ATMEL, sem az ST, se az NXP nem úgy gondolkodik, hogy a fordítón keresi agyon magát, sőt a programozáshoz szükséges HW-eket, debuggereket, stb, is ledokumentálva a nyilvánosságra hozta. A fúzióval együttjáró törekvések között hivatalosan is ott szerepelt a Microchip részéről, hogy az ATMEL termékcsaládot is el akarja látni az óriási programozó/debugger supporttal és mega-giga tool-okat fognak kiadni. Szép, szép, csak ennek a piacon ára van. A 7000 Ft-os eredeti ATMEL mkII-ből így lett 30.000 Ft-os "csodaszép" ATMEL-ICE.
Ja, hogy egy original ST-Link 6000 Ft egy a nyílt protokoll miatti tökéletesen működő klón meg 1200 Ft.

Ha kicsi és olcsó mikrovezérlő kell (atmega szintig) akkor STM8, vagy STM32F0 (Cortex-0).

Érdekes mozgások vannak a piacon, amit természetesen nem a hobby kategória határoz meg.Valóban úgy tűnik, hogy ST reagált legjobban ezekre a változásokra. Például a NXP nemrég vásárolta fel a Kinetis-t, aztán az egészet megvette a Qualcomm.
Bővebben: Link

Az miért lehet, hogy szűz, Ebayes Atmega328p-re sikeresen felmegy a program, vissza is tudom olvasni, de mintha nem akarna elindulni az IC, tehát nem csinál semmit.
Külső, 16Mhz-es kvarccal csinálom, nélküle a progi sem megy fel rá.

Való igaz, hogy bennem is komolyan megfordult az STM8/32-re való váltás (be is szereztem minden vackot, kicsit játszottam is velük), csak az idő, mire átszokok, na az igen kevés. Az azért most pozitívum, hogy végre van kicsi, de ADC-vel és UART-al rendelkező AVR, de sokkal hamarabb kellett volna (igaz árat még nem tudok). Kis vackokhoz az STM8 ideális, egyre több Kínai cuccban látom, igaz az STC 8051 komp. vezérlők is megjelentek főleg Japán cuccokban (nagyon szeretik a 8051-et és már pörgős is 1clk-s végrehajtással 40MHz-ről és nem drága). Szóval nagyon úgy néz ki, váltani kell. (jaj, már megint átolvasni pár ezer oldal pdf-et)

Idézet:
„... ST mikrovezérlő 20-30 db-os ára 70-80 Ft, addig szerintem nincs miről beszélni. Tessék csak megnézni: STM8S003 vagy STM8S005...”

Kevesen forgalmazzák Magyarországon... A HeStore -ben sincs.
FDH ~400Ft+Áfa, RS Comp. ~270 Ft +Áfa.

Különválik az ipari / hobbi célú felhasználás (nagyon helyesen).
- a DIP-es mikrovezérlőknek lőttek, megvehetsz dev board-ot is ugyanannyiért (a DIP drága)
- hobbi célú mikrovezérlőn az Arduino rendszernek futnia kell (gyors, látványos programozás)
- az ipari mikrovezérlők meg legyenek olcsók

A hobbi szintű használatnál az ST még nem komoly játékos. Elvileg működik az ST Arduino alatt, de kényelmetlen programozni, vettem dev board-ot, de nem láttam benne sok fantáziát. Egyszerűen nem áll kézre. Megveszed az eszközt, letöltöd a libet, kipróbálod. Ez a hobbi elektronika. Drágább, mint az ipari, de az időd is drága. Ha nem gyártasz 1 millió darabot, akkor nem probléma + 2000 Ft-ot kifizetni.

Hobbi szinten komoly játékos az ESP család lesz. Nem is mentem rá nagyon az ST mikrovezérlőkre, várom, hogy lemenjen az ESP32 ára.

Reset láb rendben van?

Ha még csak IDE terén, Arduinoban tudsz gondolkozni?
Nem is érdemes ARM magos procit használnod!

És mit fog érni az ESP32-es nagyobb sebessége?
Ha GLCD-t + Toucht akarsz alkalmazni?
A kevés lábszám miatt már I2C bővítőt kell használnod, és már buktad is az ESP32-ön, nyert sebességet!

Látszólag minden rendben volt. Külső táppal megindult, és azóta megy...

22 GPIO-ja van az ESP32-nek. Az Arduino UNO-nak 20 van összesen.

ARM-ot mondom kipróbáltam, Linux alatt szétszívtam az agyam és rájöttem, hogy nincs értelme erőltetni. A legtöbb IDE windows alatt ment, én meg nem fogok operációs rendszert váltani pusztán ARM miatt. Sokkal egyszerűbb más mikrokontrollerrel szórakozni, ami jobban illeszkedik a Linux rendszerhez.

Az ARM dev board már 2 éve porosodik a fiókomban. A legnagyobb baj, hogy haladni szeretek, nem beta verziós Linuxos szkriptekkel szórakozni. Feldugom az USB-t, program feltölt, megy.

Van ST-LINK programozóm is, ugyanúgy porosodik. Nem fogok baromkodni kábelekkel, programozóval, meg miegymás. USB bedug, program megy. Amelyik board erre nem képes, az felejtős.

Ez viszont a Linuxos-osok baja, semmi köze az ARM-hoz!
Amit inkább vállalkozói alkalmazásnak találtak ki, azok számára, akik független akartak maradni a Mikrofostól!

Ezért nem szivügyük az ARM fejlesztés.

Szerinem nem a Linuxosoké. Láthatóan jól megvannak más tök jó processzorokkal is.

Meddő vita!

Linuxot ingyen adják, mégis igen kevesen alkalmazzák!
Én úgy vagyok vele, mint te az ARM-al!
Értelmetlen pazarlásnak érzem a rászánt tanulási időt.

> Amit inkább vállalkozói alkalmazásnak találtak ki, azok számára, akik független akartak maradni a Mikrofostól!

A Linuxosok nem azért használnak Linuxot, mert függetlenedni akarnak a Microsofttól.
Többször gondoltam, hogy visszaváltok, de fél óra múlva megint a Linux futott. Baromira kényelmetlen a Windows.

Csak nézz szét hány projekt használ Windows alatt MinGW fordítót. Ezeket az alkalmazásokat eleve Linuxra írták, csak portolták Windowsra is. Hozzáteszem, hogy az Arduino is stabilabb Linux alatt. Láthatóan ott fejlesztik, a Windows-os verzió meg hellyel-közzel megyeget.

Sokáig a Windows-os Arduino az avr-gcc 2009-es verzióját használta. Akkora kódot is generált. Senki nem vette a fáradtságot, hogy frissítse. Mostanság már vannak újabb gcc-k Windows alatt is.

Így van, ha a diskurzusba belekerült az arduino mint érv a fordítók között, akkor itt a vége a vitának.

A Linux-ot egyaltalan nem vallalkozoi alkalmazasnak talaltak ki. Kezdettol fogva egy ingyenes rendszer volt. Tulajdonkeppen egy ingyenes UNIX x86-ra, amit aztan portoltak szamtalan mas processzorra is. Nagyon elterjedt rendszer lett belole, lasd a netes- es fileszerverek jelentos resze, Android telefonok, stb. Asztali PC-n is eleg elterjedt. ARM szempontbol, koszoni szepen, teljesen jol lehet rajta fejleszteni. Csak ehhez tudni kell, hogy a UNIX-ot eredetileg muszaki es tudomanyos munkara talaltak ki, tehat a Linux maga a DE, I nelkul. Szovegszerkeszto, kulonbozo forditok, debuggerek, ezernyi utility (pl. make). Egyetlen baj van vele, hogy erteni kell hozza. Nem irja meg a programozo helyett a startup kodot meg az LCD drivereket, mint ezek a mai IDE-k. En Linux-on fejlesztek 1997 ota, es nagyon jol elvagyok vele. Es nem LED-es villogokrol van szo, hanem komoly munkakrol.

Profikkal nem vitatkozom!
Én, mint amatőr, aki szinte mindent a netről tanult, nem vagyunk 1 súlycsoportban!
A Linux-ot meg végkép nem ismerem.



Ezzel is csak az a baj, hogy mit lehet kivágni belőle a kukába!

> A Linux-ot meg végkép nem ismerem.

Telepítsd az Android Terminal Emulatort a telefonodon és megismerkedhetsz a Linuxszal.
Több Linuxot adnak el, mint Windows-t évente. Az utolsó kínai routerben is linux fut.

Szerintem valahol nagyon elszaladt veletek a linux falova!
Ez itt AVR es topik! És az AVR kontra ARM még talán belefér!

A Linux kontra WIN már nagyon OF!

Igazából arra akartam felhívni a figyelmet, hogy világ létezik a látótereden túl is.
Tele van az internet projektekkel, ahol egy Android telefon vezérel egy AVR kütyüt USB kábelen keresztül. Sőt vannak panelek, ahol a Raspberry Pi-vel (Linux) összedrótoznak egy Arduino-t, hogy a chip IO képességeit a pi számítási kapacitásával keresztezzék.

Azzal, hogy felesleges megtanulni a Linuxot többen nem értünk egyet. Az AVR IO képességei fantasztikusak, mögé kell nyomni egy Raspberry/Banana/Orange Pi-t és kinyílik a világ előtted.

AVR-t ebben az esetben puffernek használod hogy ne a drága kártyát tedd tönkre, ha félrekötnéd a vezetékeket.

Igen, és ha meghirdeted az Androidos App-odat? Lefölözik a haszon 90%-át!
De szerintem ezt a vitát már innen kivágják a Modik!

És attol még nem vagyok szükebb látókörű, hogy megvagyok Linux nélkül!

Nem értek egyet. Legutóbb az Attiny85-öt fordítva raktam be. A GND ment a VCC-re, a VCC meg a GND-re.
Magyarul: fordított tápot kapott. Amikor láttam, hogy mi van és éreztem, hogy melegszik, akkor gondoltam kuka.

Megvártam, míg kihűlt, visszaraktam megfelelő irányba és láss csodát: működött. Mintha mi sem történt volna.

Az AVR IO portként fantaszikus, ami mögé komoly rendszereket is berakhatsz.
Nincs másik chip a piacon, ami ekkora baromkodást túlélne.

Sziasztok!
Egy tapasztalatot szeretnék megosztani:
Ha van egy #define részetek, ami matematikai műveleteket tartalmaz, pl: (310*100)/16,
akkor mindenféleképpen rakjátok zárójelbe az egészet, így: #define VMI ((310*100)/16),
mert ha nem, és beillesztitek egy ilyen sorba pl: ertek=atlag*VMI/1000; , akkor hibára fog futni a számítás, mert a fordító egy-az-egyben beilleszti a define-os számítást a sorba, és megváltozik a számítási sorrend. Szerintem már sokszor jártam így, és mindig zárójelezés segített ki, esetleg raktam elé egy (long)(VMI) kényszerítést, amitől persze megjavult az ertek valtozó, de nem tudtam, mi a hiba oka. Most már tiszta.

Szia!
Ez benne is van a nagykönyvekben, mármint az expression zárójelezés. A miértek is, ahogy írtad.
Bővebben: Link

Nálunk a munkahelyen minden kódot valaki másnak ellenőrizni kell és ha nem szép, akkor vissza küldjük a készítőnek javításra. A zárójelezés lehagyása nálam bőven elég arra, hogy ne kerüljön be a kód a rendszerbe.



Minden egyes változót az összes előfordulási helyen zárójelbe kell rakni. Kivétel nincs.

Kemény. Elég sok mindenre kell figyelni.

I2C EEPROM loggolási algoritmust ismertek?

Ami fontos lenne:
- ne legyenek kitüntetett EEPROM cellák, amit túlterhelünk írással.
- ne kelljen a teljes EEPROM-on végigmenni, hogy megtaláljam, hogy honnan folytassam a logok írását
- az utolsó napi logokat könnyen el tudjam érni, hogy min max hőmérsékletet számoljak
- a logok számát ismerni kellene
- és időben visszafelé átküldeni
- egy log 3-8 byte-ot foglal el, de lehet, hogy 8 byte-os lesz mind

Szia. Szerintem végigolvasni az eepromot nem gond. Egyszer kell, amikor indul az AVR, utána változóban elmentve mindig jelen lesz a kellő információ, hogy hol is tartottál. Az eepromban kell egy speciális kódsorozat, ami semmiféleképpen sem szerepelhet a mentett adatok között, ha lehet, több byte hosszú. Így körbe-körbe tudod írni az eepromot. Ellenőrző értékek sem ártanak, mert ha elmegy a táp, és pont írsz, akkor hibás adat lesz lementve, erre is figyelni kell! A logok számát könnyen ki tudod számolni, ha körbeértél már egyszer, akkor a speciális kódsor után is logok lesznek (nem 0xff, mint amit gyárilag tartalmaz az eeprom), ha pedig még nem értél körbe, akkor a sorszám alapján tudod, hol tartasz. Ha pedig a logok mérete változó, akkor azt is el tudod tárolni az eepromban, hogy hány byte tartozik össze, (3-8byte, ez 6 különböző érték, 3biten ábrázolható, és hozzáfűzhető az egyik byte-hoz, amin nincs kihasználva mind a 8bit, így akár ugrálva is tudsz számolni), de ha indulásnál megszámolod, az sem tart túlságosan sokáig. Nekem a TFT inicializálása kb. 1mp, szóval indulásnál bele kell, hogy férjen ennyi időhúzás, esetleg megteheted menet közben is, amikor már minden "él". Jó kis programozási feladatok ezek.

Feltételezem, hogy a logoláshoz kell pontos idő. Az időhöz RTC, az RTC-ben van ram és elemről megy.
Ebben a ramban eltárolhatod az utolsó log címét + CRC-t. Ha nem jó a CRC amit a címből számítasz.
Csak akkor kell a végét keresni az eepromnak.

Mondjuk, ennek csak akkor van értelme ha 2 logolás között lekapcsolsz mindent.
És az RTC ébreszti megszakítás kéréssel a rendszert, az újabb logolás idején!