Szia!

Az ATmega8L-nek alacsonyabban van az alsó feszültséghatára. 2,7V-nál még tudja a 8MHz-es órajelet. Én használtam ATmega8L-t 16MHz-en, természetesen 5V-os tápfeszültségnél. Ebben a környezetben úgy gondolom, mindegy melyik verziót választod, menni fog. ATmega88-at is rakhatsz bele, mert készült ehhez való *.hex, egyébként csak láb-kompatibilisek, egyik programja nem jó a másikba. Mivel programozod fel a programozódba az AVR-t?
A 74HC126-nak nincs 1-1 helyettesítője.

Szia, azt még nem tudom. Ha lehet, valakit megkérek, hogy programozza fel.

Akkor melyik Atmegát ajánlod ami Topi áramköréhez és a Hex fájlhoz megfelelne?

Én ezt ggondoltam megrendelni.

Ez biztosan jó lesz hozzá.

Köszönöm.

Azt nem tudod véletlenük, hogy a HEStore vállalja-e a felprogramozott ATMEGA8-16PU forgalmazást?

Régen ugye ezt forgalmazták KIT- ként, de már kifutottnak írják. Én felhívnám őket, hogy megoldható-e, az a legtisztább. Vagy adsz fel hirdetést, hogy fel tudja-e valaki neked programozni, esetleg veszel valakitől egy felprogramozott IC-t, amit meg most veszel, megmarad fejlesztéshez...

Én is erre gondoltam, az apró, vagy a telefon.

Köszönöm a tanácsaidat.

Sziasztok,
Innen letöltöttem az Atmel CryproMemory AVR könyvtárát.
A mintaprogramot megnyitottam au AVR Studio 7-ben, kiválasztottam az Atmega328-at, amikor rákattintok a Start Debugging-ra, akkor undefined reference hibákat adja elő:

Csatoltam a mappát, amiben vannak a fájlok.
Szerintetek mit nem csinálok jól?
A választ előre is köszönöm!

A mappa lemaradt.

Próbáld a 'Solution Explorer' ablakban hozzáadni a 'GccApplication1' mapában szereplő *.c fájlokat!
(kivéve main.c)

Utánna már csak pár paramétert nem talál!
Azokat viszont, biztos neket kel megadnod, kézzel!
A megépített HW alapján.

A 'GccApplication1.cproj' töltöttedbe a Atmel Studioba?

Köszönöm a válaszodat!
Hozzáadtam a .c fájlokat, de ugyanazt csinálja, probáltam .h fájlokat is hozza adni, de így is ugyanazt csinálja.

Hozzá kell adni a lib_CM.a lib-et itt:

Á! Köszi!

Így már csak ezt kell belőni: # define F_CPU 1000000UL

Nekem csak ezek jönnek elő:

Debug/GccApplication1 Properties.

Elindult, köszönöm szépen mindenkinek a segítséget!
Holnap beállítom, hogy az Arduino-ra töltse fel a bootloader-en keresztül a programot és ha van rá igény, akkor írok pár sort az AT88SC25616-os (ez a legnagyobb méretü Atmel CryptoMemory) CryptoMemoriá-ról.
További szép estét mindenkinek!

Igen!
Érdekelnek a tapasztalataid!

Írjál le mindent! Azt is, hogy hol vetted a AT88SC25616-ost?

Az AT88SC25616-os egy CarProg klón-ban volt benne, de Aliexpressen-en is lehet kapni 5 darabot 12 dolcsiért.
Romániában vásároltam kb.5 éve a CarProg klónt, ez egy EEPROM/motorola mcu programozó, de tud motorvezérlő egységet is programozni. Van benne egy kontor, ami 500 müvelet után letilt, ez gyorsan fogyott hála az eeprom csipesznek (Kb. 10-szer kellett kiolvasni egy eepromot, ahhoz, hogy normálisan kiolvassa, az írásról nem is beszélve), és a munkaközben lefagyó programnak.
250 használat kezdte kiírni hibaüzenetként, hogy még mennyi van hátra, használtam ameddig kb. 40-hez elért, utána elküldtem Bukarestbe, ahol állítólag újraprogramozták benne az AT91SAM7S256-ot, visszaküldték, a hibaüzenet nem jött elő, a 10-edik probálkozás után kiolvasta az eeprom-ot, müködött mint új korában. Az egyiknap amikor bedugtam a sorozatszámnál ÿÿÿÿÿÿÿÿÿÿÿÿÿÿ jött elé, és nem engedett a program semmire se rákattintani. Utánanéztem, azt írták, hogy el lehet dobni, mert az AT88SC25616-ban sérült meg a program. (Programot azóta se találtam bele.) Vásároltam egy másikot, ami jelenleg üzemképes. Megprobáltam a réginek az MCU-jába újraírni a programot, amit .hex fájlban megtalátam, de most amikor bedugom az USB-be unknown device-ként jelenik meg. A forumokon azt írják, hogy ez egyértelmüen az AT88SC25616 hibája (én azért írtam Keil-ben egy próba programot, ami az SDA és SCL-t kapcsolgatja, hogy lássam, hogy az MCU jó-e benne, szkóppal rámértem, és jónak bizonyult.) Az AT88 üzemképes, mert kommunikál az Arduinoval kb. 8 féle címen (az I2Cscanner-el néztem.)

Száz szónak is egy a vége, valahogy a müködő AT88-ból ki kell olvassam a programot és átírjam a régibe, de előtte kísérletezek a régivel, hogy hogyan lehet ráírni és hogy lehet az I2C-n folyó titkosított adatokból visszafejteni a tartalmat. (A CryptoMeria titkosítás megfejtésére van kész program a neten.)

Délután feltöltöm a mintaprogramot az Arduino-ra és nekifogok a tanulmányozásnak.

Még egy kérdés: A lib_CM.a egy lefordított könyvtár, aminek a tartalmáról nem feltétlen kellene tudnia a programozónak? Vagy miért nem .c-ben van mint a többi?

Sziasztok! Vásárlási tippet szeretnék kérni. Kotorászok attiny9 vagy 10 breakout board után (fontos lenne a dip-6 kiszerelés, mert olyan helyre kerülne mechanikailag). Lehet valahol kapni készen kiszerelve, vagy az ilyesmit mindenki saját maga gyártja házilag?

Természetesen a titkosító programot is tikosítani kel! Ha nyilvánossá tennék, akkor az már nem lenne titok!

Köszi, az eddigit, és várjuk a folytatást!

Sziasztok! Lehet inkább a kezdő topikba kellene feltennem a kérdést, de miért van az, hogy az AVR (attiny85) a 46.684397 és 0,017453 szorzásakor az reáltermen az alulról a 6. sort adja eredményül, miközben a helyes eredmény a számológépen látható, a változók single tip.

A lebegőpontos számokkal való műveleteknek (szinte) mindig hibája van. Ennek oka, hogy véges felbontással tárolhatóak a lebegőpontos számok (olvass utána: exponens, mantissza). A 8 bites mikrokontrollerek ráadásul a legrosszabb pontosságú lebegőpontos számokat használják (single precision), de még azokkal is szoftveresen kalkulálnak (ezeket komolyabb ARM alapú uC-k gyakran hardveresen is támogatják).
Attól függően, milyen célúak a számítások, gyakran érdemesebb integer alapra áttenni a számításokat, hogy elfogadható pontosságú (és sebességű!) eredmény kapjál. Tipikus hiba: Rengeteg lebegőpontos szám összeadása, ahol az összeg folyamatosan egyre nagyobb lesz a hozzáadott értékhez képest (elképesztő hibát összehozhat ez).

Köszönöm, de sajnos ez a rosszabb eset, hogy nem én rontottam el valamit...

Ha neked ez az eredmény nem elég jó, akkor te rontottad el. Nem a megfelelő eszközt használod a probléma megoldásához.

Ma nagyot nem feszítettem, egyedül a programfeltöltést oldottam meg az Arduino-ra, az UART komunikáció kódját be copy-pasteltem, de nem küld el semmit se. Még odáig sem értem el, hogy megnézzem, hogy jó portra küldi-e.
Holnap ha többet nem is, de az UART kommunikációt elindítom.

Persze igazad van, én arra gondoltam, hogy nem a számítás menetét rontottam el. (két gps koordináta távolságáról van szó). Melyik kontrollert ajánlanád ilyesmi számításokra, (szögfüggvények is vannak.)?

Tudomásom szerint az avrgcc csak 32bites lebegőpontos számításokat támogat, így inkább az ARM-ok felé kellene kacsingatnod.

Igazából jó lenne tudni, hogy AVR alatt minek kell 8 tizedes pontosság és miért nem elég a 32 bites float. A fenti képen látszik, hogy minden szép és jó, a 32 bit ezt tudja.

Azt írják, hogy az avr.h-ban le lehet cserélni, hogy a double 64 bites legyen.

Próbáld ki, hogy lecseréled 64-esre. Nálam most nincs gép.

A GPS koordináták 8 tizedes pontosságban adják a milliméteres pontosságot. A fenti hibával az az érdekes helyzet állt elő, hogy a legegyszerűbb képlettel számolt koordináták közti távolságnál elvileg minél kisebb a távolság annál kisebb a hiba (mert nem számolunk a gömbölyűséggel) helyett minél nagyobb a távolság, százalékosan annál kisebb a hiba. Tehát pl. ha egy métert kellene mérni akkor csak 91cm-ert mér, ami ugye majd 10% hiba, ha 10 métert akkor 9.76-ot ami már csak 2,4% hiba és így tovább. Tehát ha nagyon kicsi számokkal kell számolnia akkor van "baj". Itt most azt kell elképzelni, hogy adott egy 6 millió méteres egyenlő szárú háromszög aminek az alapja 91 centi , és itt kell radiánban szögeket számolni.... Szóval tudomásul vettem, hogy AVR térképészethez kevés, de geocaching-re még jó lehet

> AVR térképészethez kevés

Kipróbáltad átírni az avr-gcc-t, hogy 64 biten működjön a double (lásd fentebb)? Nem látom, hogy miért ne tudna az AVR ilyet kiszámolni. C64-en is ment a 64 bites double C alatt.

"Szóval tudomásul vettem, hogy AVR térképészethez kevés" - ez kicsit durva. Nem az AVR hibája, hogy nem megfelelően van használva. Sima számolásról van szó. Ha egy 4 magos gép ki tudja számolni a koordinátát, akkor az AVR is ki tudja ugyanakkora pontossággal, csak esetleg lassabban. Tehát képes rá, csak tudni kell használni.