2ⁿ byte legyen (16, 32, 64 ... stb.)

Nyilván ahány éves a kapitány.

Kicsit slampos vagy! Az "egy" és a "kell" véletlenül magyarul maradt.
Nos, ha engem kérdezel, asm-ben nincs ilyen. Vagy legalábbis én nem tudok róla.
Mivel asm.-ben (különösen a 18-as szériától fölfelé) direkt, és indirekt (ha már szereted az idegen kifejezéseket) úton elérhető és címezhető a RAM, így oda és akkora adatálományt pakolok ahová és amekkorát akarok. (Na jó, azért a RAM mérete befolyásoló tényező.)
Elérhetek ramokat közvetlenül, elő és utóinkrementálással, elő és utó dekrementálással. (hú de csúnya idegen szó) Ráadásul többszörösen is, azaz ugyanazt a területet egyidejűleg (ne köss bele, tudom, hogy egyszerre csak egy művelet lehetséges) sorban írhatom és olvashatom anélkül, hogy ez bekavarna.
Amúgy meg, hogy mekkora? Mindíg az adott feladat határozza meg.
Persze az is lehet, hogy nem értem a kérdést, és hülyeségeket írogatok.
Ez esetben röhögj egy jót!

Irtam mar par tucat soros porton dolgozo programot de en nem tudok egyetlen optimalis meretet vagy kepletet sem.
Altalanossagban akkor jo, ha a leheto legkisebb mennyisegu megszakitassal tudom kezelni az adatfolyamot. Ez pedig ugye totalisan feladat- es hardwarefuggo.
Szoval az egyszavas valaszom: ¯\_(ツ)_/¯

Mindössze azt szerettem volna megtudni, hogy ki az, aki 2ⁿ pufferméretet definiálna - szerintem ez jelzi, hogy az illető kolléga "bináris gondolkodású".
Elnézést kérek, ha feleslegesen, túlkomplikáltam a kérdést.

Nem röhögök, mert igazad is van.
A kérdést szándékosan úgy fogalmaztam meg, hogy gyakorló programozóknak szóljon.
A FiFo, és a deklaráció helyett nem találtam frappáns magyar kifejezést, de örömmel fogadok minden javaslatot. Ezen ne vesszünk össze, ha legközelebb feléd járok, vendégem vagy egy sörre.

Nem a kapitány kora, hanem a processzor szómérete a döntő.

Azt hittem valami furfangosabb . Bevallom erre nem gondoltam mert ez nekem eleg alap.
Azt hiszem pont iden 30 eve, hogy megirtam az elso gepi kodu programomat, hexa bevitellel egy intel sdk-en, es epp most is egy pdp-11/70-en mokolok, meg mindig assembly-ben es erosen fontolgatom, hogy heggesztek ra egy C forditot is (csak basic es fortran van).
Sajnalatos modon en a mai napig - teljesen feleslegesen - a ketto hatvanyait hasznalom, akar java vagy epp python/django kornyezetben is.
Mar tobszor megszoltak (jogosan), hogy semmi ertelme a 16/32/64 vagy epp 128 karakteres mezoknek (SQL)
En nem tekintem hibanak, tehat tovabbra is hasznalom.

Én nem guglizok ebben a témában. közel ötven éves tapasztalat/gyakorlat alapján szólok hozzá. Arra szerettem volna rámutatni, hogy annak ellenére, hogy egy algoritmus leprogramozása magas szintű nyelven egyszerűbb, a gépi kód ismerete alap.

Jól teszed, neked van igazad.
A "bináris gondolkodás" végét a merevlemezek méretének meghatározása indította el. A markecing, és a hétköznapi emberek dilemmája, mekkora is az a vincseszter, mennyi RAM van abban a gépben. Ennek eredménye kiB, miB, satöbbi szörnyűségek.

Ez csak akkor játszik normálisan, ha a puffer kezdetét is "olyan" címre teszed, különben tök mindegy, semmit nem spórol sehol.

Szervusztok,
Látom ti rendesen értitek a dolgokat, ezért gondoltam jelzem nektek, hogy porosodik a szekrényemben egy MPLAB PM3 minden tartozékával. Érdekel valakit?

Ez ugyan se nem PIC. se nem ASM, de teljesül a feltételed.

Helo.
Kikészít egy érdekes hiba. 16F1615 ösön akarom használni az UART tx részét megszakítással, de valamiért nem igazán sikerül. Biztos én rontok el valamit, ez az első assemblyben írt valamim amit már toldozgatok egy ideje. A gond az FSR0 regiszterrel van. Nem piszkálom sehol máshol, csak a megszakításban szeretném növelni hogy végigmenjen a bufferemen, de valami mindig visszarakja egy fix értékre, az első két bájt kimegy utána csak a másodikat ismételgeti. 1,2,3,4,5 helyett 1,2,2,2,2. Mit rontok el? Ez a main végén van:
Ez pedig a megszakításban:

Az incf utasítás két paraméteres. A második paraméterben mondod meg, hogy a megnövelt érték W regiszterbe vagy a memóriába íródjon vissza, és a W az alapértelmezett. Próbáld ki így:

Sajnos ugyanaz van így is, az fsr0 beragad 0x34 en, illetve a kezdőcímet és plusz egyet küld ki, utána csak a kettes ismétlődik háromszor. Valamiért sem a külön incf sem a moviw fsr0++ nem azt csinálja amit szeretnék. Hamarabb futna le az újabb main loop minthogy kiküldené az első byteot aztán újra lefut aminek nem kéne csak ha a buffer végére ért? De már az első alkalommal nullától különböző a txcount... Most ilyesmire gyanakszom bár lehet tévúton járok, megnézem mit tudok tenni...

A DECF TXCOUNT esetén is ugyanaz a helyzet, oda is kellene a " ,f" kiegészítés. Amúgy meg nézd meg szimulátorban mit csinál rosszul.

Kipróbálom, de debug módban a txcount szépen csökken, csak az fsr0 nem akarja amit szeretnék. Sőt, bocs most nézem azt is átírtam de mindhiába.

A MOVIW utasításnak vannak olyan változatai, amik automatikusan csökkentik (vagy növelik) az FSR regiszter értékét. Miért nem azt használod?

Azt szerettem volna alapból, a moviw fsr0++. Csak nem működik valamiért. Mintahogy a külön incf sem.

Mekkora a TX_BUFFER_SIZE értéke?
Az indexnek -32 és +31 között kell lennie.

5. A buffer a bank0 ban van.

Próbáld így: ADDFSR FSR0, 1. A cím betöltésnél a LOW/HIGH nem biztos hogy jó, az inkább a program memória betöltésre való.
Inkább:
MOVLW 0X33
MOVWF FSR0L
CLRF FSR0H

Így sem működik. Egyszerűen nem tudom növelni az fsr0 regisztert a megszakításban, semelyik módszerrel sem. Próbából csináltam külön flaget, azt beállítom, a főprogram pedig hozzáad egyet az fsr0 hoz. Ellenőrzöm hogy a txcount nulla e, ha nem nulla ellenőrzöm hogy a megszakítás állította e a flaget. Ha igen akkor törlöm és növelem fsr0 regisztert. Így meg az elsőt kétszer küldte. 1,1,3,4,5. Érdekes hogy nem 1,1,2,3,4. Az átvitel indításából kivettem az fsr növelést, csak akkor növel a főprogram ha a txif megszakítás lefutott. De a txif megszakítás már rakja a következő bájtot a tx regiszterbe, ha nem növelek az első után, akkor hogy a francba működhet mégis? Valami nagyon nem jó Szerk.: Erre elvileg megvan a válasz, az uart megszakításhoz nem szükséges semmit elsőként a tx regiszterbe írni, csak engedélyezni kell és ha üres a tx fut is le. De így sem tudok fsr t növelni megszakításból.

A teljes megszakítást kellene látni, ellenőrizni. (Regiszterek mentése/visszaállítása).

Ez lesz a baj! Ennél már nem kell elvileg menteni, megcsinálja magának. És persze hogy az fsr t is menti, most láttam az adatlapon. A shadow regisztert kell növelnem. Köszönöm mindenkinek a segítséget, elvileg jó lesz.

Sziasztok!
Elvi vagy módszer megoldást keresek. Két különböző eszközről soros porton kell fogadnom adatokat és ezeket továbbítani ugyancsak soros porton. (kicsit átalakítva) Problémám a következő: A két eszköz bármikor küldhet adatokat, (Adatvesztést szeretném elkerülni!) Amikor én (PIC) küld adatokat akkor is jöhet bármikor új adat.
Ezeknek a feldolgozási metódusa érdekelne, hogy ne legyenek ütközések. Minden ötletet szívesen fogadok.

Ehhez ugye három hardver soros portod van?

Igen 2 input, 1 output

Akkor sima megszakításban lekezelt vétel, és adás: FIFO a megoldás.