apal blogja

Érdekes megállapítás: gcc-12 esetén RISC-V processzorokra a -march= kapcsoló már elkezd különbözni fordítás és linkelés esetén. Amennyiben speciálisabb Zxxx kiterjesztést használunk (azaz bármi CSR-t, azaz ilyen-olyan megszakításokkal dolgozunk!), akkor azt immáron már "kéri" a fordító, ellenben a linker meg meghülyül ha ottmarad ez.

Onnan is lehet látni hogy az Unicode karakterkészletet Ámerikában találják ki hogy a "mosógép" még mindig nincs a karakterek között, de "egy zászlópóznán, a szélben lengedező két darab döglött hal" (🎏) az van!

Egy kicsit intenzívebb fejlesztési szakasz és néhány korábban felmerült kérdés után kijött a korábban bemutatott, saját fejlesztésű AVR proci és/vagy SoC következő verziója. Javítva vagyon benne pár CPU core és perifériákat érintő bug, ami a tesztek során ugyan előjött, de jelenlegi felhasználásnál (azaz konkrét programok futtatásánál) nem jött elő, sem égen, sem földön.

Noha az "digitális elektronika" mint olyan arról lehet nevezetes hogy egyik állapotot egyértelműen kell kövesse a következő állapot, a hardver-leíró nyelvek közül is a Verilog szereti használni a sztenderd "0" es "1" (és "z") állapotokon felül az "x"-et. Ami... ami úgy van definiálva mint: nem tudjuk, nem érdekel, nem érint, vagy ennek valamiféle kombinációja. Szeretjük is használni az "x"-et már "beugró szinten is", már a legegyszerűbb igazságtábláknál is megjelenhetnek.
 

Kis hasznos az /etc/udev/rules.d/ konyvtarba, ha valaki sok FTDI USB UART-tal dolgozik:

SUBSYSTEM=="tty", ACTION=="add", RUN+="/bin/bash -c 'f=/sys/bus/usb-serial/devices/%k/latency_timer; test -f $f && echo 1 > $f'"

Kicsit gyanus volt hogy 921k6 baudon az oda-vissza tranzakciok ~12kB/sec-cel mentek... :)

struct __attribute__((__packed__)) whatever
 {      unsigned int  f1: 2;
        unsigned int  f2: 5;
        unsigned int  f3: 5;
        unsigned int  f4: 6;
        unsigned int  f5: 6;
        unsigned int  f6: 8;
 };

[...]

sizeof(struct whatever) = ?

$ top
[...]
 2983 apal      20   0  1.103t 277496 118228 R 176.2  1.7   0:08.10 chrome                                                             
 2502 apal      20   0 32.807g 320464 208048 S  21.8  2.0   0:16.80 chrome                                                             
 2939 apal      20   0  1.103t 188632 108684 S  21.8  1.2   0:02.02 chrome                                                             

Not bad... 

Márcsak szűk két óra: https://www.nasa.gov/nasalive

... tavaly sikerult beleplnem. Iden mar nem. Gondoltam megirom hosszabban is a tapasztalatokat, de aztan a gondolat tovaszallt - mondvan hogy valojaban sok ujat nem tudok mondani eme szoftverceg minosegerol. Mondjuk mar tavaly osszel is volt annyi sutnivalojuk a bizottsagoknak hogy a doktori vedesek es/vagy szigorlatok egyreszet attettek zoom-ra. Azaz van feny az alagut vegen, de a holnaputani esemenybol vsz igy meg es/vagy mar sokan kimaradunk.

ARMv6-M alatt nem csinalunk ilyet hogy uint32_t x = ntohl(*(uint32_t *)buff) ...

ARMv6-M alatt nem csinalunk ilyet hogy uint32_t x = ntohl(*(uint32_t *)buff) ...

ARMv6-M alatt nem csinalunk ilyet hogy uint32_t x = ntohl(*(uint32_t *)buff) ...

... 

Márcsak kevesebb mint 11 óra! https://www.youtube.com/watch?v=J1nfIV-4_e8

Két kicsi magyar műhold, reméljük minden is rendben lesz :) A videó moszkvai időt mutat, magyar idő szerint szombat reggel 07:07-kor indulunk. (Node a mi visszaszámlálónk az csak-csak jó... bár a javascript sosem tartozott a kedvenc nyelvek közé, odafent azért nem azt kell használni)

Szerk: egy nap halasztás, start vasárnap reggel! két nap halasztás, lesz ez hétfő reggeli start is.

2020 vege, vegytiszta szuz android, chrome-mal, webes email attachment: ~2 megas jpeg. 

Elso sajat opencores-projekt: https://opencores.org/projects/softavrcore. Ha valakit erdekel full stack FPGA + AVR kombinacio. 

Kovetkezo feladat: hogyan is lehet svn-ben(!) ilyen dolgokat feltolteni a barhova is...

# ls -l /dev/md
lrwxrwxrwx 1 root root 8 Jun 15 17:22 md0 -> ../md127
 

... es mekkora orom amikor kiderul hogy a javascript a style.zIndex-eket stringkent hasonlitja ossze!

... es akkor ott bassza meg a pötterix onmagat ahol van!

Van egy USB3-Ethernet adapter, amit ha egyik USB-A 2-es csatlakozoba dugok akkor minden oke, de ha a masikba (ami konkretan egy USB2-es hub egyik vagy masik csatlakozoja) akkor nem mukodik csak ugy. A dmesg szerint az enumeration elejen mar elekad (de konkret hibat nem irt ki). Ellenben ha csak ugy felig dugom be hogy eppenhogy legyen kontakt, akkor szepen megy - ellentetben mechanikailag annyira nem tartos a dugvany.

Akkor ezekszerint ez az USB3 vs. USB1/2 hardveres szintu csatlakozo-kompatibilitas az igy sikerult? Eszi, nem eszi, nem kap mast? :)

... hogy az is egy kellemes erzes mikor kiderul ~fel nap debuggolas utan hogy a gray code -> binaris konverzio elott nem lehet csak ugy ad hoc negalni az osszes bitet :) Avagy: legkozelebb ne doljunk be az "ah, open collectoros a gray-enkoder kimenete, tokmindegy hogy hogy vesszuk le azokat a biteket" dolognak!

Na, most 10 e'v... + pa'r o'ra...

a minap, va'lta's polokent random mod egy emitten nyert hup-os volt nalam a mont blanc tetejen. szep kis kirandulas, keves levego, nagy hegy, nagyokat lehet pottyanni :]

Nemregiben ezt a pexec programot bevette'k a gnu projektbe. Mielott oda is teljesen felmenne, emitten egy lokalisan veglegesnek szant verzio (1.0rc7), itten. Sok aprobb fejlesztes: autoconf, mutexek, atomi parancsok, dinamikus terhelesmegosztas es -szabalyozas, doku; ha valakit erdekelne egy kis shell-szintu "data parallelization". Mindenfele hibajelentest, o"tletet, megjegyzest, egyebet addig is szivesen varok!

Ujabb pexec riliz, kiegeszitve egy kis osszefoglaloval. Ez a valgrind nagyon kiraly dolog, kar hogy eddig nem ismertem.

Egy kis karacsony elotti pexec frissites, miutan x nap elteltevel sikerult elerni a vasat, amin a legutolso fejlesztes keszult. Biztonsagi mentesnek is betudhato, ennek oromere; es egy kvazi-kritikus bugot is sikerult kijavitani (nem biztonsagi hiba, csak neha leblokkolt, ha az input kellemetlen formatumu). Apropo, biztonsagi hibak: tud-e' valaki jo modszert hogyan lehet keresni/talalni effajta reseket egy adott programon, ami me'g belathato meretu"? Oke, ne hasznaljon az ember strcpy()-t, ezen kivul...:)?

Programocska, az elmult par nap termese: pexec (illetve itt csak a lenyeg). A szokasoktol elteroen ehhez van kis honlap, manual, peldak, es meg hasznalhato is. Kicsit bovebben: ez egy olyan valami, amivel binarisokat es/vagy szkripteket lehet parhuzamosan futtatni, ugy hogy a futtatasi parametereket (stdin/out/err, kornyezeti valtozok) adott halmazon varialja. Tud csak localhoston is mukodni, de a szegeny ember vizzel foz, remote hoston is fut egy kellemes rsh segitsegevel. Van meg hatra par dolog (signalok kulturalt kezelese, remote control, mutexek), ezeket a napokban, szabadido" fv-eben megcsinalom; de addigis lehet hasznalni, a mai sokprocis/sokmagos ge'pek idejeben neha nem is rossz, hogy ki is lehet hasznalni a teljesitmenyt...

No, nem tudom mennyire kozismert, de a unix-os y2k problema't kvazi megoldotta'k:

apal@szofi:~/progs/test$ cat sizeof.c 
#include <stdio.h>
#include <time.h>

int main(void)
{
 fprintf(stdout,"time_t: %d\n",(int)sizeof(time_t));
 return(0);
}
apal@szofi:~/progs/test$ gcc -o sizeof sizeof.c 
apal@szofi:~/progs/test$ ./sizeof 
time_t: 8
apal@szofi:~/progs/test$ arch
x86_64
apal@szofi:~/progs/test$

Apro oromok :]