Svenska ElektronikForumet

Det är aldrig för sent att lära om. Gjorde samma misstag som Du när jag var ugn och fastnade i Pascalträsket. Är nu 64 och var nog 58 när jag började med C utan ++. Var inga större svårigheter att ställa om.

Är van vid programmering, först handassemblerad 1802, sedan AIM-65, CP/M och PC där jag dessvärre valde Pascal och Delphi. Nu Linux och gcc. Linux är definitivt det bästa för att själv skriva program till riktig PC.
Till microkontrollers tycker jag inte alls om Arduino o.dyl. Blir klumpigt, stort och slött. Bättre att ta tag i hårdvaran direkt och skriva assembler för de små 8-bit och C för RPi o.dyl.

Fungerar jättefint att skriva källkod i vanlig editor och felsöka med små tillägg för utskrift. De där integrerade miljöerna är atarkt övervärderade. För realtidsprogram helt värdelösa.

ARM assembler är något mycket speciellt med villkorlig exekvering av instruktioner. Ett instruktionsset som definitivt sticker ut. Gamla 8086 tycker jag själv är det oöverträffat bästa för att skriva i assembler. Den har 8-/16-bit i ett välbalanserat, lättanvänt och greppbart instruktionsset, men är ju lite ute idag...

Marta, känner igen det du skriver om. Är några år äldre än dig men tror att du har mera programmeringsvana än mig. Har mest hållit på med assembler på mcu och väldigt lite på PC.
88-89 höll jag på med Siemens PLC med deras PG675 en dyr koloss som gick på CP/M. För att förbilliga körde vi CP/M på PC för att kunna programmera PLC på ett billigare sätt. Hade ständigt problem med HDD på den tiden. Kom i kontakt med ett helt fantastiskt program (Spinrite) som kollade statusen på hårddiskarna. https://www.grc.com/srhistory.htm
Fungerade bara på DOS men det löste vi, när spinrite varnade visste vi alltid att den var eol, byt ut den här disken.

Steve Gibson på GRC var också en hejare på assembler och gjorde en hel del fantastiska saker. Bl.a skrev han en brandvägg i assembler under en natt hans hemsida var utsatt för en DDOS attack. https://web.stanford.edu/class/msande91 ... grcdos.pdf
Det är väldigt länge sedan nu men intressant hackerhistoria som dessutom visar vad som är/var möjligt att åstadkomma med assembler bara man var nog nördig. Idag har jag insett att ska man åstadkomma något är jag mera i linje med ts.
Hoppas inte Micke_71 tycker att det blir för mycket OT isåfall kan vi göra en ny tråd av detta och hålla den ren till det som ts skapade den för.

Micke_71 skrev: ↑27 januari 2022, 20:29:12 Sitter hemma med covid och har mestadels letat info istället för att aktivt programmera. Upptäckte att jag har lite dåligt med pryttlar o koppla in till den.
.
.
Hur som helst så ligger det 3böcker på väg hem för typ 1500kr
RP2040 assembler (Först o främst PIO o state machines)
RPi Pico C programmering
RPi Pico Micropython

Och så lite pryttlar från elektrokit ska beställas.

Hoppas att coviden inte tagit all kraft från dig!
Hoppas också att du kan göra en snabb resume av Assemblerboken och C-boken när du hunnit titta på dom.
State machine i assembler låter som något jag skulle ha användning för. Har gjort några försök tidigare men det har tillslut mest blivit ganska ostrukturerad kod. Har några Pico som ligger och skulle passa bra.

Mindmapper skrev: ↑31 januari 2022, 20:14:32 Steve Gibson på GRC var också en hejare på assembler och gjorde en hel del fantastiska saker. Bl.a skrev han en brandvägg i assembler under en natt hans hemsida var utsatt för en DDOS attack. https://web.stanford.edu/class/msande91 ... grcdos.pdf
Det är väldigt länge sedan nu men intressant hackerhistoria som dessutom visar vad som är/var möjligt att åstadkomma med assembler bara man var nog nördig. Idag har jag insett att ska man åstadkomma något är jag mera i linje med ts.
Hoppas inte Micke_71 tycker att det blir för mycket OT isåfall kan vi göra en ny tråd av detta och hålla den ren till det som ts skapade den för.

Hoppas att coviden inte tagit all kraft från dig!
Hoppas också att du kan göra en snabb resume av Assemblerboken och C-boken när du hunnit titta på dom.
State machine i assembler låter som något jag skulle ha användning för. Har gjort några försök tidigare men det har tillslut mest blivit ganska ostrukturerad kod. Har några Pico som ligger och skulle passa bra.

Var inne o postade något på ett annat forum i frågan..... Det handlade lite om hur man gör saker så onödigt komplicerat, om det var någon hemlig klubb eller tävling i vem som kan visa mest kunskap genom att skriva så komplicerat så ingen förstår. Den tråden började bra, sedan vart det en tävling i vilka som programmerat det mesta i assembler på 80-talet, AI, självkörande bilar och just nu så handlar det om covid vaccination. Så de här små sidospåren kan jag leva med och till och med uppskatta.

Blev orkeslös men i övrigt väldigt mild variant och jag är tillbaka på jobbet dag nr1 nu på kvällen.

Jag har inte fått några böcker än men har försökt klura lite på PIO assembler och läst dokumentationen som finns. Allt som jag kan hitta blir så kryptiskt o jag är väldigt vilse just nu. Jag har en tanke och funderat hur jag typish skulle vilja testa något men det är lite som en neandertalare som försöker läsa en doktorsavhandling i kvantfysik just nu.

Expressions ska kunna användas fritt står det men det finns inte ett enda bra exempel någonstans. Jag har inte riktigt blivit klok på isr, osr, push osv. Inbillar mig att jag kanske har en aning. Hur som helst så tänker jag något typ så här.

Vänta på Pin1 =1
start loop
öka register x med 1 för varje loop
hoppa till label end: om pinne 2 =1
slut loop
label end:
flytta x till isr
push isr till fifo

wait 1 pin1
wrap
mov x, (x+1)
jmp pin2 , end
.wrap
end :
out x, isr
push isr

Om jag mot alla odds tänker rätt (högst osannolikt) nu så bör pin1 starta en loop som går i 100MHz (om jag klockar i 200Mhz) och räknar upp X med 10ns upplösning. X har 32bit längd dvs max 42,94sek . Pin2 hoppar ur loopen och flyttar värdet i register x så huvudprogrammet kan läsa det. Huvudprogrammet kollar 3st fifo register var 0.1 sek och om 2 av 3 är högre än noll så gör det sin grej.

Edit: Tydligen ska inte mov kunna räkna på detta sätt utan man får leka lite med att jump kan räkna ner X registret som en loop räknare istället. Då tar varje loop motsvarande 40ns. Att räkna ner från 1 miljon räcker gott....

mov x, 1 000 000
wait 1 pin1
loop:
jmp pin2 , end
jmp x-- loop
end :
out x, isr
push isr

Hade inte tänkt gå in och gräva i Pico än men blev lite nyfiken av det du skrev.
Trodde "assembler state machine"-boken var en bok om generella state machine's, fast det verkar det inte vara. Utan Pico's PIO verkar styras internt av 4 state machine där de tydligen styr vilken status på ingångar och utgångar ska vara via isr "input shift register" och osr "output shift register".

Sedan blir det lite kaos uppe i den delen av huvudet man ska tänka med. Detta liknar ingen PIO jag programmerat tidigare, endera för att man inte trängt nog långt in i dom eller för att det är helt nytt. Man behöver nog lite tid för att sätta sig in i detta.

Manipulering av enskilda I/O-pinnar har ju aldrig varit snabb. Därför har man manipulerat de olika bitarna i register med AND/OR och på detta sätt snabbat upp I/O hanteringen. Blir det för krångligt får man nog låta bli att blanda in assembler och lösa det med logik hantering av I/O registren i C. Verkar lättare att göra så än att blanda in assemblern, i varje fall om det blir nog snabbt med bara C.

Var en stund sedan jag gjorde det i pascal men principen för logikhantering av I/O är den samma, återstår övergången till C. Som pensionär känner jag att jag har gott om tid på mig.

State machines med PIO som Pico har är något relativt unikt. De själva påstår att de är ensamma och helt nytt. Har läst lite påståenden om att liknande funktioner har förekommit/förekommer på andra mcu.

Vad som stämmer vet jag inte o ser ingen vits att rota för mycket i.

Tycker funktionen i sig själv är mer intressant med 8st ”pico” stora processorer trots att de är begränsade till väldigt lite minne och fåtal instruktioner.

De har ju trixat in lite andra finurligheter.

Side load där man kan lägga in mer funktionalitet i varje instruktion. Inbyggd delay i instruktionerna. Man kan dela ner klockfrekvensen i själva konfigurationen. Wrap funktion som skapar en loop utan att äta instruktionsminne eller klockcykel

De lyckas ju göra en hel del med ett fåtal instruktioner som jag inte trodde var möjligt.

Om jag klockar upp till 250MHz vilket de klarar lätt och kör en

wrap
set pins, 1
set pins, 0
.wrap

Så togglar jag en pinne i 125MHz och använder 2instruktioner.

wrap
set pins, 1 [9]
set pins, 0 [9]
.wrap

Så har jag lagt in delay så frekvensen blir 12.5MHz fortfarande 2 instruktioner.

De går även o synkronisera med gemensam start och kan kommunicera med varandra genom irq och pin states.

Även om micropython är långsammare än C så kan man köra blixtsnabba rutiner i nanosekunds området med exakt timing in på varje klockpuls. Låter visst som en försäljare…. Blir lite uppspelt i möjligheter. Det största bekymret är att mina kunskaper är på tok för små i dagsläget.

Första boken kom idag. Den från USA kom snabbare än de från Sverige….

Sitter på jobbet vid maskinen så jag har bara bläddrat i 1minut men än så länge verkar den vara riktigt bra. En hel del förklaringar och exempel i state machine från micropython med exempel utan att göra det för kryptiskt. Mycket programexempel med diverse applikationer förklarat och verifierat med tider i logikanalysator. Den passar nog bäst från relativt nybörjare till medel.

Det tar sig sa pyromanen..... Lyckades krångla till en state machine på 7 instruktioner för att mäta tid med 10ns upplösning i micropython.

Det vart lite krångligt eftersom den inte vill nolla X registret eller få in värden i det. Hur jag än gjorde så gick det inte. det löste sig med att jag fick skicka 0xFFFFFFFF via FIFO och in i OSR för att sedan kunna flytta det till X och använda JMP räknaren. Python koden kollar bara 10ggr sekunden och den är inte väsentlig. Det var bara för att kunna se om det funkar.

Låt skiten brinna. (Lsb)
Riktigt bra med en öppen låga som rensar bort det gamla.
Skall bli spännande att se det fullkomliga när det gamla är borta.
Det är inte värdet, det är förändringen som vi vill åt.

Jag lovade återkomma med lite omdöme kring litteraturen jag köpt.

En exakt likadan som i bilden ovanför fast programspråket C istället. Boken är i identiskt med den om micropython i allt förutom att programspråket är C istället.

Boken går från relativt enkel till lite mer avancerad, ett kapitel o state machines. Lite elektronik på relativt enkel nivå.

Är man redan på avancerad nivå så är det kanske inte rätt litteratur.

RP2040 Assembly. Beskriver mestadels assembler som huvudprogramsråk och verkar ligga på medel nivå. Likaså här finns det ett kapitel dedikerat till state machines. Detta beskriver inte i huvudsak något mer eller mindre som finns i de andra böckerna. Dock så var någon funktion beskriver med lite andra ord vilket klargjorde vissa oklarheter.

Det är jättesvårt på ett sätt. Vem/Vilka skulle ha nytta av litteraturen i fråga?

Jag kan läsa databladen och förstå det jag läser till viss del men behöver ett antal mer exempel som hjälper mig att förstå det jag gör. 100timmar på Google gjorde mig bara utmattad.

Vi alla vet principen KISS (keep it simple stupid) men där har det varit en copy paste tävling på orelevanta svar och krångla till det så mycket som möjligt.

Men litteraturen i fråga håller det enkelt. I vissa frågor så enkelt så jag bläddrar förbi för det är löjligt enkelt. Men andra kapitel är ju långt över min nivå….

Jag vill nog påstå att de inte lider av ”30 million rows of code” problem. De håller det tydligt och enkelt även om nivån är lagom så man relativt lätt kan förstå.

Micke_71 skrev: ↑1 februari 2022, 02:59:11 State machines med PIO som Pico har är något relativt unikt. De själva påstår att de är ensamma och helt nytt. Har läst lite påståenden om att liknande funktioner har förekommit/förekommer på andra mcu.

Same shit, different name... PRU, programmable real-time unit, kallas det på andra uC.

En väldigt nyttig sak för industriella tillämpningar, ex. enkodrar, och Raspberry Pi hade varit en mycket mer
industriellt användbar plattform om den hade haft det.

Och jag som trodde att PRU betydde "Port Replacement Unit".

Jag är 40+ och vi har läst oss C i skolan nu för MCU'er och visst det är knöligt det är det, men å andra sidan är det inte så illa som det verkar.
Det jag känner som besvärligast är detta med pekare och structar, men det är bara att hålla på.
Text hantering i C är ingen höjdare heller då man måste tala om allt för det, det fattar inte självt om det är helttal, decimaltal eller ren text osv.
Finns säkert bibliotek som kan sköta detta för dig om så är.

Fast vi har jobbat mest med register och bitar kors och tvärs, för allt från knappar till UART.
Jag gillar C men har en låååååååååååååååång väg kvar i det.

I början gjorde vi ett program för en LED som skulle tändas vid knapptryckning. Ena i C andra i Arduinos IDE (C++?)
C koden var 1/3 av Ardu. och kändes snabbare.

Sedan om jag fattat det hela rätt så har Python flera bibliotek som är baserade kring C/C++ vilket kan göra koden nästan lika snabb,
men om det är så men MicroPython vet jag inte. Rätta mig om jag har fel.

Som Ice cap sa, använd det som fungerar för dig och ditt projekt. =D