Napečení ATtiny85

[Celeron]

Nedaří se mi v Arduino IDE napíct přes USBasp programátor čip ATtiny85.
Mám v IDE doinstalovaný ATtiny85 core, který může měnit nejen Clock ale i fuse.
Pokaždý se mi zahlásí chyba SCK s výpisem že je potřeba SCK 187,5 kHz.
Když napíkám ATmega 328p, tak vše proběhne v pořádku.
Zkoušel jsem napečení ATtiny85 přes USBasp z BAScom. Ta samý chyba ale v Bascom je možnost SCK nastavit na 187,5 kHz a níže. Potom už napečení proběhne OK. V nejhorším budu projekty z IDE kopírovat hexy nebo biny do BAScomu, ale je to docela pakárna hledat kam to IDE ukládá.
Netušíte prosím někdo, jestli se někde v Arduino IDE dá nastavit SCK pro USBasp na 187,5 kHz, nebo nevíte jinou fintu jak to rozhejbat?
Díky!

[eleferner]

Tohle souvisi s tim, ze kmitocet SCK musi byt treba 8x mensi nez je kmitocet jadra. U techto malych procesoru byva kmitocet jadra od vyroby jen 1 MHz, takze SCK vychazi pomerne nizky a programovani trva dlouho. Pri masove vyrobe je na to trik, ze pomoci fuses se kmitocet jadra zvedne treba na 8 MHz, nahrnou se data do Flash a fuses se zase vrati zpatky. Treba bys to mohl pouzit jako workaround.

Tady ty kmitocty rozebiraji pro ATTiny13:

https://www.eevblog.com/forum/microcontrollers/sck-frequency-for-programming-attiny13a/

A v USBasp pry jde upgradovat firmware, aby tu chybu nehazel:

https://www.youtube.com/watch?v=NDwDCTnSTzg

[Celeron]

Jo, někde jsem četl, že čínský klony USBasp mají proti Fischlově originálu automatickou volbu SCK, která nefunguje jak má a je potřeba napíct origo FW od Fischla.
To video, co jsi dal, je potřeba druhej USBasp. Vypadá to, že to dělá v AVRdue s příkazovým řádkem. Vzhledem k tomu jeho žvatlání mu moc nerozumím a obávám se, že i kdybych použil místo druhýho USBasp UNO jako Arduino ISP, tak to nedám.
Ale naťukl jsi mě na věc, co by to vyřešila, v BAScomu, kterej umí měnit kmitočet SCK, přecvaknout ATtiny85 na 8 MHZ a pak by možná mělo makat i v IDE. Zkusím, díky za tip.

[Celeron]

Vyzkoušel jsem v BAScomu napíct do ATtiny85 obligátní Blink s Interním oscilátorem 8 MHz. Prolezlo to bez chyb ale oscilem se na noze nic nedělo. Tedy dělo, ale z jedný sekundy jich bylo osm. Zkusil jsem vypnout předděličku osmi a už to jede stejně rychle jako ATmega 328p.
Divný ale je, že program maká v ATtiny správně jen když se nahraje do Flash buferu BAScomu zkompilovanej soubor ve formátu HEX. Pokud nahraju to samý ve formátu BIN, tak ATtiny nemaká.
Bohužel, ta moje doměnka, že pokud nastavím v BAScomu v ATtiny interní oscilátor 8 MHz, že potom půjde programovat ATtiny přes USBasp přímo v Aeduino IDE byla lichá, stále to řve že chce SCK 178,5 kHz. Zajímavý ovšem je, že v BAScomu pokud zvolím SCK "automat", tak to s 8 MHz oscilátorem v ATtiny chodí. Pokud ho vrátím na 1MHz tak přestane. Pavěda...

[RayeR]

Ten hex muze obsahovat i fuse bity, zatim co bin je jen flash, tak proto asi ten rozdil...

[JirkaZ]

*.hex pro Atmel přeci nemůže obsahovat pojistky....

Nebo se mýlím? Rád se nechám poučit...

[Celeron]

Neobsahuje. V Bascomu i v AVRdude, což je podkladek pod Arduino IDE se pečou fuse a lock zvlášť od flash, případně eeprom. Záleží co si nastavíš, jestli to udělá po pečení flash nebo ne.
To pečení mě už chodí na všem. Doporučovanej driver od Zaziga je na W7/32 i W7/64 nepoužitelnej, chce to originál od autora USBasp.

[Mahoney]

Obsahuje, resp. záleží jak si to nastavíš, ale obecně jo. I v Arduino IDE, když dáš Projekt - Export kompilovaného bináru, tak ti to do složky s projektem vygeneruje dva HEX soubory, jeden s bootloaderem a jeden bez, a tam si to můžeš prohlídnout.

Tady je jednoduchej sketch, kde si je v Arduino IDE můžeš vyčíst přímo z brouka, a tady jsou vysvětlivky. Na Tině to bude možná malinko odlišný, ale definice najdeš v datasheetu té Tiny (strana 148, a dej pozor na to, že 0 = NASTAVENÁ fuse; clock sources na straně 25) a v hlavičkových souborech přímo ve složce toho prostředí (../hardware/tools/avr/avr/include/avr/iotn85.h)

[Celeron]

Hmm, tak proč teda v Bascomu se LB, FS, FSH, FSE nahrávají samostatně ihned jakmile ji změníš? Write PRG se dělá samostatně a nic na nich nezmění, nebo jsem si dosud nevšiml.

[Mahoney]

Špatně to chápeš, to jestli je to prostředí umí zapsat přímo z menu nijak nesouvisí s tím, jestli jsou fuses v HEX zrovna momentálně uloženy nebo ne, to platí obecně a závisí to na konfiguraci prostředí (hlavně co se týče překladu). Fuses prostě v HEX být můžou i nemusí. Bascom neznám, ale jestli to v něm nejde nastavit, tak jen proto, že si s tím autor nedal tu práci.

[JirkaZ]

V prostém *.hex (univerzálním pro všechny způsoby použití) obsahujícím program pro Atmel pojistky nikdy nejsou (na rozdíl třeba od PICu).

Pokud to nějaké prostředí (IDE, obslužý program k programátoru atd.) umí, tak je to nestandardní a ryze proprietární záležitost a umí to zpracovat zase jen tentýž sw. Někdy se to ukládá jako projekt (třeba u Asixu a jistě i mnohde jinde), kde pojistky jsou uloženy jako samostatný soubor.

[Celeron]

Tak to by mě teda zajímalo, kdo z Vás dvou má pravdu.
Jen tak ze srandy jsem si nechal převýst v Xeltecu stejnej projekt z HEX bez Bootloaderu na BIN a porovnal ho s BINem, co vypadnul přímo z AVRdude. A světe div se, oba BINy byly naprosto stejný. Předpokládám, že pokud by HEX soubor obsahoval něco navíc, tak by musely být BINy rozdílný.

[Ruprecht]

[Habesan]

Zde je popsáno další, ryze proprietární řešení:
Kanda.com/