Är det samma metodik att programmera olika processorer?

[TomasL]

Skriv din egen TCPIP-stack från grunden, utan en massa bibliotekskod, komplettera sedan med en Webserver, också den utan en massa bibliotekskod.
Det blir garanterat mycket lärorikt och nyttigt, samt en jäkla massa läsande av dokument mm.
Använd helst en av de första generationerna av Ethernet-kretsar typ RTL 8019 eller liknande, som inte innehåller en massa funktioner för checksumma mm.

[DanielM]

Får ju en STM32G030 för runt 15-20kr, så skall du inte göra många finns det ingen större vits med AVR längre.

Fast en AVR kan man få under 5 kr från Mouser. Visst...STM32 är alltid bättre än en ATtiny eller ATmega.

Skriv din egen TCPIP-stack från grunden, utan en massa bibliotekskod, komplettera sedan med en Webserver, också den utan en massa bibliotekskod.
Det blir garanterat mycket lärorikt och nyttigt, samt en jäkla massa läsande av dokument mm.
Använd helst en av de första generationerna av Ethernet-kretsar typ RTL 8019 eller liknande, som inte innehåller en massa funktioner för checksumma mm.

Jag har tittat på något som heter WizFi360. Det är alltså en WiFi-modul där man använder AT-kommandon via UART för att ansluta och liknande. Jag vet inte hur bra den är. Men det verkar lovande med WiFi.

[Nerre]

Jag tvivlar lite på detta med tanke på att metodiken att sätta registerna skiljer sig enormt.

Det beror på vad du menar med "metodiken".

Det handlar i princip alltid om att skriva till olika register för att ställa in hur de olika portarna ska fungera.

Som TomasL beskriver så kan t.ex. pinnarna i en specifik port gå att använda både som ingång och utgång. (Normalt står de som ingång vid boot för att man inte ska råka skicka ut spänning på en port som ska vara ingång.) Porten har ett "kontrollregister" som i enklaste fallet består i en ensam bit per port för att bestämma om den ska vara ingång eller utgång.

Det man då behöver veta är ju adressen till detta kontrollregister och vilken bit som ställer om vilken port. Från det räknar man ut vilket (binärt) värde som ska skickas till kontrollregistret.

Om vi säger att vi har en port med 4 pinnar. Porten har adressen 0x100 och kontrollporten 0x101.

Om du inte programmerar den och läser från 0x100 så får du data som motsvarar var pinnarna har för insignal. Skriver du till 0x100 händer ingenting, eftersom alla pinnar är satta som ingång.

Vill du ändra pinne 1 (eller bit 1 snarare, den kan vara pinne 18 på kapseln, det får man läsa sig till i databladet) till utgång så skriver du binärt 0001 till port 0x101.

Om du sen läser från 0x100 så får du de tre högsta bitarna information om vad som ligger för insignal på de bitarna, men bit 1 är ju utgång så där får du normalt bara tillbaka vad du har skrivit till den.

Skriver du till 0x100 så ignoreras de högsta bitarna (för de är ju ingångar, de kan du inte skicka ut nåt på), men den lägsta biten styr vad du skickar ut på den pinnen.

Så oavsett om du skriver 0001, 0101, 1111 eller vad så är det bara den biten längst till höger som inverkar.

Sen kan då som sagt var portarna vara mer avancerade så man inte bara kan välja ingång eller utgång, vissa portar kanske kan programmera som PWM eller timer. Då har man flera kontrollregister till porten där man t.ex. kan ställa in ett värde (så i porten sitter en räknare som räknar upp och när den når inställt värde slår den om porten från 0 till 1 eller vice versa).

För att kunna använda grejerna måste man förstå vilka portar som kan användas till vad. En port som bara går att köra som ingång eller utgång kan du inte ställa om till PWM, för den har helt enkelt inte hårdvaran till det.

[AndLi]

Kan det ha att göra med realtid och determinism att göra kanske snarare än säkerhet? Men inte heller där spelar antalet cykler så stor roll, bara det är lika många hela tiden, eller åtminstone förutsägbart.

Det finns helt klart säkertsasspekter på det, går olika instruktioner olika fort kan det avslöja vad processorn gör och kan läcka information om nycklar osv... kanske görs 2 instruktioner för en 0 och 4 för en etta osv osv..

[TomasL]

Om man tittar på PIC16 instruktionsset, så tar alla instruktioner 1 klockcykel, såvida det inte innebär att man måste hoppa någonstans.

[ASEA]

Lite OT kanske, men när i historien(eller vilken generation) började SPI stödjas native i hårdvaran av mikrokontrollers?

[TomasL]

Motorola 68000, troligen -83 är tydligen den första gången SPI dyker upp, Det var Motorola som hittade på bussen.
I2C dök upp -82

[DanielM]

Något som jag märkte nu när jag kör Microchip Studio är att ST verkar ha kopierat Atmel Start till ungefär 99%.

Om man tittar på PIC16 instruktionsset, så tar alla instruktioner 1 klockcykel, såvida det inte innebär att man måste hoppa någonstans.

Fast AVR har väll 1 instruktionsset per cykel som standard?
Jag tittar och jämför även STM med AVR. AVR ska tydligen vara vinnare i alla längder så fort det kommer till strömsnålhet.
Men jag ser att STM32 verkar vara billigare än de flesta ATTiny från JLCPCB, vilket är inte alls lika kul att höra.

Hur som helst så har jag en idé!
Detta kort ska få en ATtiny1616 eller liknande. En enkel liten processor. Sedan så ska den kunna styra mosfet, transistorer med mera för att kunna styra motorer eller liknande. Kanske implementerar en stegmotordrivare. Något sådant. Men det viktigaste är att den ska ha WizFi360 WiFi från WizNet. Då kan jag koppla upp den på min Home Automation System. När jag kommer hem, så öppnas garaget automatiskt av min GPS som talar med Home Automation System, som i sin tur, talar med detta kretskort som jag har gjort i Altium CircuitMakerk.

Ja. Jag har börjat testa Altium CircuitMaker istället för KiCAD. Jag är fortfarande ovan med CircuitMaker. Men en bra fördel med CircuitMaker är att man kan dela projekt med varandra och jobba i grupp. Detta går inte i KiCAD.

Skärmbild 2024-02-21 221234.png

[AndLi]

>Men jag ser att STM32 verkar vara billigare än de flesta ATTiny från JLCPCB, vilket är inte alls lika kul att höra.

Jag gissar att det beror på att STM32 har en hyffsat standard ARM kärna i sig, som det går 14 på dussinet på val av leverantörer.. ATTiny finns bara från en... Det är helt enkelt mer konkurrens för STM32an..

Fortsätter ATTiny fortfarande att utvecklas? Rekommenderas den för nya designer? Eller finns det bara kvar för att den har lovats att finnas i x år? Spontant förknippar jag namnet (ATTiny) med gammal teknik, men det kan ju vara helt fel..

[ToPNoTCH]

Om pris är i fokus skulle jag nog kolla lite på RISC-V.
Exempel https://hackaday.com/2023/04/19/risc-v- ... -low-cost/

[Swech]

Det var inte länge sedan det kom nya ATtiny

Swech

[DanielM]

>Men jag ser att STM32 verkar vara billigare än de flesta ATTiny från JLCPCB, vilket är inte alls lika kul att höra.

Jag gissar att det beror på att STM32 har en hyffsat standard ARM kärna i sig, som det går 14 på dussinet på val av leverantörer.. ATTiny finns bara från en... Det är helt enkelt mer konkurrens för STM32an..

Fortsätter ATTiny fortfarande att utvecklas? Rekommenderas den för nya designer? Eller finns det bara kvar för att den har lovats att finnas i x år? Spontant förknippar jag namnet (ATTiny) med gammal teknik, men det kan ju vara helt fel..

Jag ber inte hur det ser ut med utvecklingen för AVR. Microchip köpte upp Atmel. Men jag vet inte hur AVR har utvecklats efter detta.

Jag vet att Microchip Studio har inte uppdaterats sedan 2022.

Jag vet inte heller vart AVR brukar användas. Som jag uppfattar det som så verkar PIC mera populärt bland företag och AVR är mer populärt bland hobbyfolk.

[Wihelm]

Microchip Studio hette Atmel Studio innan de bara döpte om det. Så det är många år sedan det fick några större uppdateringar.

[DanielM]

Nu har jag inte kommit så långt med AVR. Men när jag börjar titta på hur många nya AVR som Microchip släpper, så är det bara....1
https://www.microchip.com/en-us/paramet ... 1DVSJdfQ==

För PIC är det betydligt fler. Det känns som Microchip kanske inte investerar i AVR längre?

[ojz0r]

Microchip kommer troligtvis att prioritera sin egna arkitektur med PIC över AVR.
Spekulationen är om inte Microchip köpte Atmel enbart pga ATSAM serien för att snabbt kunna komplettera sitt utbud med ARM. Mips har ju annonserat att de kommer att gå över till RISC-V istället.

Men jag förstår inte riktigt ditt fokus på lansering av nya AVR chip. Om de känner att de har ett heltäckande utbud i AVR serien så kommer de inte att släppa nya bara för att, det finns inget självändamål i det.