Igen, a régi oldalon volt hozzá kézikönyv - még nem tudtam az új lapra átrakni...
Azt hittem már senki nem használja az Arduino láz mellett

A Wayback-on fenn van még a teljes Bascvom-AVR online könyv.
Így lassan az oldalra is kirakom (TavIR.hu)

Köszönöm az ötletet, át fogom böngészni a topikot.

Én Bascomban programozok, AI is segít, de ha van valami konkrét kérdés kereshetsz, itt a fórumon is van külön topikja. Bővebben: Link

"Milyen környezetre gondolsz?"

A fejlesztőrendszerre. De a beletett munka is sok, ahogy néztem.

Ezt hagyjuk is, ez a Nyugat ópiuma. : -)

Ez hátrányos megkülönböztetés azokkal szemben akiknek kevesebb vagy több ujjuk van mint tíz. Lehet az oktális és hexa számrendszert ennek a kompenzálására vezették be.

Használtam Bascomot! Utoljára WS2812 RGB LED gyűrű modult programoztam vele arduino minire. Jó móka volt!

Köszönöm, letöltöttem. Milyen környezetre gondolsz?

Talán tavir.hu .

Nagyon hangulatos. Utoljára a Borland dokumentációiban láttam hasonló részletességű leírásokat, még azt is elmagyarázták, mi az az ABC.

"Decimal and Binary Number Systems

Normally, we count things in base 10. The base is completely arbitrary. The only reason that people have traditionally used base 10 is that they have 10 fingers, which have made handy counting tools"

: -)

És erre a BASCOM fórumra hivatkozik: https://www.mcselec.com/index2.php?option=com_forum&Itemid=59 Létezik még, láttam márciusi hozzászólásokat is.

Az láttad, ugye, hogy a főoldalukon van egy közel 2000 oldalas, tavaly frissített pdf mintapéldákkal?

https://quasarelectronics.co.uk/Item/bascom-avr
"Download User Manual"

Amúgy szép ára van a környezetnek. : -)

Bascom

Sziasztok!
Használ valaki BASCOM-ot Atmel chipekhez?
Szeretnék foglalkozni vele, és kellene hozzá irodalom. Oktató anyag, leírás, mintapéldák, stb.
Azért ez, és nem más, mert ez megvan, telepítve van, tudok chipet égetni az AVR studióval.
Viszont a programokat eddig nem én írtam, csak a hardvert terveztem, és szeretném megtanulni.
Előre is köszönöm a segítséget.

A mester adja a resetet és nagyon pontos időben vár egy adatot, különben eldobja magát. Általánosan merült fel az alapállapot utáni első tranzakció mikéntje, de most megvilágosodtam, hogy milyen irányba kell nézelődnöm. Az, hogy az adás lehetősége tiltott, rendben, de itt pl. azt jelzi vissza, hogy nincs kész az adatvételre a regiszter (mint ha most adás folyamatban lenne), ez kavart meg AVR-nel/ennél a vacaknál. Néha nagyon tudom szégyellni magam, hogy átsiklok alapdolgokon...

Ohh, én marharépa, hát AVR-nél duplapufferelt, ennél az őskövületnél meg nincs ilyen, még az újabb klónoknál sem Azért nyavalyogtam ám, mert egy többprocos rendszerben reset után nagyon gyorsan van adatmozgatás, így (?) próbálnak valamit védeni, órajelre kiszámolták, mikor kell mennie adatnak... és hasonló kisagyas dolgok (amik még kiderülnek). Marad a gyorsabb klónra átportolás. Köszönöm!!!

Én ezt az egészet úgy gondolom (úgy tanultam), hogy bekapcsolás (tápfesz megérkezik, indul a kütyü) után és (akár hard- , akár soft- ) RESET után is minden (használni tervezett) egységet fel kell készíteni a használatra (inicializálás). Ebben benne van, az is, hogy milyen szabvány szerint (baud-rate, bitszám, stopbitek, stb...) kommunikáljon. Ezek után kész arra, hogy rendesen működjön, vagyis ezután kell neki megmondani, hogy üres az adópuffer, engedélyezni az adás IT-t, stb...
Futottam már bele olyan hibába, hogy figyelmetlenül írtam meg az inicializálást, és nem értettem, hogy miért nem azt csinálja a uC, amit szeretnék látni... Azután rájöttem, hogy bizony törölni/alaphelyzetbe állítani kell mindent.

Egyébként szerintem jogos, hogy induláskor "le van tiltva" az adás lehetősége (a foglaltság kb. ezt jelenti...). Ilyenkor bármi lehet bárhol a regiszterekben, RAM-ban... Ha engedélyezve lenne, akkor (főleg egy rosszul megírt program esetében) elkezdhetne magától küldeni valamit, akár csak egyetlen byte-ot, ami adott esetben a fogadó-oldalon ki tudja mit okoz. (A uC gyártója biztosan nem tudhatja...) Éppen ezért jogos, hogy minden kifelé történő akciót csak a program(író) kifejezett engedélyezése után tudjon végrehajtani.

Szerintem...

AVR-nél a UCSRnA, TXCn mondja, hogy az adás kész, a shift regiszter üres, RESET után ez 0, azaz az adás nincs kész. de én nem ezt használom adás előtt. Helyette UCSRnA, UDREn. Ez azt mondja, hogy a UDREn kész új adat fogadására, a buffer üres. Ez RESET után 1, azaz üres a buffer, adásra kész.

AVR IT nélküli küldés:



A következő byte-ot egyébként sem akkor kell berakni a bufferbe, ha már kiment az előző, hanem amikor a buffer UDRn üres (ekkor még megy az adás a shift regiszterből), de ahogy látod a TXC1-et lehet törölni, te is megteheted első adás előtt, ha azt szeretnéd.

Az IT-s küldés ennél bonyolultabb, de ott is a UDRE IT-t kell használni a következő byte küldéséhez, nem a TX Complete-et.

Reset után nyilvánvaló, hogy semmi sem volt még küldve, tehát van egy tiszta állapotod. Megkülönböztetheted az első alkalmat, amikor feleslegesen elugrik az interruptra az összes többitől, amikor ténylegesen elküldött bájt után jön az interrupt.

Jó esetben, hogy ne kelljen ilyen logikát tenni az interrupt rutinba, hogy aztán azt mindig lassítsa, létezik valami trükk is, pl.: SETB TI, CLR TI, és csak utána engedélyezed globálisan az interruptokat. A bit törlésének elvileg törölnie kell az interrupt-állapotot a kontrollerben.

Bocsánat, elúszás volt. Nem-nem, nem STM specifikált, általános volt a kérdésem! Tehát egy pl. soros rutin úgy kezdődik, hogy megnézzük, az adó üres-e? De reset után jópár uC-nél ez 0 (foglalt), akkor az első byte hogyan mehet ki? (ott várakozik szegény) persze felülbírálva (sok helyen ezt használják) akkor is belenyomja a bufferbe (ez a megoldás bit/utasításpazarlás, mert soha többet nem használjuk), ha nincs kész. Egyszerűbb lenne resetkor 1-be állítani az "adómeghajtó üres" bitet, de nem. Nem?!? (sajnos nem találtam általános uC topic-ot, de AVR-nél is így van, nyelv nem számít, környezet nem számít, általános volt a kérdésem). Közben ránéztem egyéb perifériákra, egyre szörnyűbb a helyzet (matek tárproc is reset után azt jelzi, nincs kész, lehet felülbírálni első nekifutáskor...nem így tanultam) Biztos én vagyok értetlen, de ezért kérdezek.

Szia, te most STM8 családhoz szeretnél tanácsot kapni?

Ez itt az AVR családdal foglalkozó topic, azok nézik akit AVR-t (ATmega, ATtiny) programoznak. Jó lenne, ha megfelelő topicban tennéd fel a kérdést, ha nincs akkor nyitni kell egy "STM8 - Miértek hogyanok" néven ezt a kérdést meg itt töröltetni a moderátorokkal.

Az is jó lenne, ha megadnád pontosan milyen kontrollert, milyen nyelven, milyen környezetben programozod, előbb kapnál segítséget.

Soros port 1. byte küldése

Sziasztok!
Hogyan kell kiküldeni soros porton reset után az első adatot?
Pár uC-t néztem, reset után 0 a TI flag, vagy nevezzük bárhogy, ami azt jelenti, hogy
nincs kész az új adat fogadására (soros puffer nincs kész, pl. ad). Kínai ASM programokat néztem, ott bevezettek egy külön bitet (legyen busy), ami akkor is belenyomja a soros pufferbe az adatot,
amikor nincs kész (elméletileg), aztán nullázza, soha többet nem kerül rá a vezérlés (mert beáll a soros üres flag). Most vagy én vagyok a hülye hozzá (99%), vagy reset után miért nem áll be 1-be a bit? Áthidaltam, hogy inic-ben 1db 00h byte-ot kiküldtem, fogjuk rá a bekapcsolási tranziensre, de ez nem normális, szerintem. Főleg érdekes, hogy van olyan uC amiben van SETBit TI utasítás, de akkor bebillen az interrupt flag, amikor a globálisat engedélyezem, elugrik rá. Bár szimulátorban néztem, 3 sim 3 választ adott... Nem nagy gond, csak kérdezem a nagytudású hozzáértőktől. STM nagyokon nem néztem, lehet, ott jól megy, 8-bites apróságokon kértem AI segélyt is, össze-vissza-balfékséget adott.

Köszi az infót.
Elfogattam a megépítését, így tisztába kell tennem a részleteket.

Forrás nincs, de az ITT lévő kommentek alapján tényleg 18 MHz-esre van tervezve. Akkor viszont ne L-es kontrollert használj, hanem a sima ATmega8-at.

Bővebben: Link

Igen, max. 8 MHz-es quartz lehet a 8L mellett és 16 MHz-es a sima 8 mellett.
Van aki próbálkozik a túlhajtással, de ez ahhoz már túl nagy a 8L-nek.
Ha megvan a program forrás szinten, akkor abból valószínűleg kiderül milyen kell.
Milyen áramkör ez egyébként, hol találtad?

Atmega8L

Szép kora estét mindenkinek.
A mellékelt kapcsolási rajz részleten az Atmega8l külső 18Mhz quartz szerepel, ez gondolom csak tévedés lehet, az adatlap szerint 8Mmhz kell, vagy tévedek?

Lehet választani bin és hex között (jobb oldal a filenév utáni lenyíló).

Köszönöm!
A BASCOM 2.0.8.5 - ös .bin file-t kér, a MikroC kimenete .hex kiterjesztésű, tehát nem eszi, hogy az USBASP programozómat kipróbáljam, kezeli-e?
Van valami, ami a .hex file- t átteszi .bin - be?

AVRATJTAGICE mkII féleségek

Sziasztok!
Feltöltő-debuger dobozok, 3 fajta. Nagyokban, az egyikben 1db uC, vonalmeghajtók. Másikban űrsikló cuccok (ugyan az a típus), 2db M128, FIFO, 512kB SRAM stb. Mivel tud többet az egyik-másik? A legkisebben meg csak 2db kicsi uC van.

A bascom kezeli az USBASP-OT amit linkeltem.

Ez van. Kép mellékelve.
A Bascom-Avr nem kezeli az USB portot ( legalább is, amit letöltöttem).
Az AVR dude 1 pillanatra bevillan, mint régi DOS-os kép.
A Zadigtól leáll a gép.

Megvárom, míg bejön az MK II rendelésem.