Som jag tänker så är det klockan som driver alla perifiraler. Så man börjar där igenom att aktivera klockan eller delar av klockan som driver GPIO, SPI, TIM, I2C med mera.
Är det samma metodik att programmera olika processorer?
Re: Är det samma metodik att programmera olika processorer?
Väldigt mycket olika, beroende på processor, bara att läsa datablad.
Re: Är det samma metodik att programmera olika processorer?
Du menar att det finns inge likheter ?
Re: Är det samma metodik att programmera olika processorer?
Nej. PIC 8 och PIC18 är lika resten är väsensskild
Re: Är det samma metodik att programmera olika processorer?
Jag menar i grunden. Du aktiverar alltid klockan på alla processorer? Du kopplar alltid klockan till perifiralerna?
Det är detta jag menar som är likheterna.
Det är detta jag menar som är likheterna.
Re: Är det samma metodik att programmera olika processorer?
Nej, det beror helt och hållet på processor.
Re: Är det samma metodik att programmera olika processorer?
Men då är det absolut ingen anledning att lära sig programmera register eller ens en möjlighet att lära dig hur processorer fungerar med tanke på att dom alla fungerar olika och verkar (enligt dig) skilja som natt och dag.
Re: Är det samma metodik att programmera olika processorer?
Så är det, man specialiserar sig på en processor och håller sig till den, typ.
Dock alla processorer fungerar på samma sätt, register programmeras på samma sätt osv.
Dock alla processorer fungerar på samma sätt, register programmeras på samma sätt osv.
Re: Är det samma metodik att programmera olika processorer?
Ja. Här kom det. Dom programmeras på samma sätt. Alltså är det ingen skillnad hur processorerna programmeras om dom programmeras på samma sätt?
Eller tog du i som vanligt?
Jag håller inte med att man förhåller sig bara till en processortyp. Jag menar, man får sällan välja vad för processor man ska jobba med. Alltså måste man kunna många, dvs grunden hjälper bra.
Eller tog du i som vanligt?
Jag håller inte med att man förhåller sig bara till en processortyp. Jag menar, man får sällan välja vad för processor man ska jobba med. Alltså måste man kunna många, dvs grunden hjälper bra.
Re: Är det samma metodik att programmera olika processorer?
Det är lärorikt, men jag tycker att ST borde faktiskt ge ut utbildningsmaterial hur man programmerar med register endast.
Man får lusläsa referensmanualen som den vore en riktig manual för lärdom.
Gissa vad denna kod gör.
Man får lusläsa referensmanualen som den vore en riktig manual för lärdom.
Gissa vad denna kod gör.
Kod: Markera allt
#include <main.h>
int main(){
/* Start the HSE clock */
RCC->CR |= (1 << 16);
/* Check if the HSE clock is ready */
while(!(RCC->CR & (1 << 17)));
/* Now is the HSE clock ready - Time to select it as system clock */
RCC->CFGR |= 0b01;
/* Check if the HSE clock is selected */
while(!(RCC->CFGR & 0b0100));
/* Prescaler AHB from 8 MHz to 4 MHz */
RCC->CFGR |= (0b1000 << 4);
/* Prescaler APB1 from 4 MHz to 500 kHz (16 division) times 2 if prescaler is > 1 */
RCC->CFGR |= (0b111 << 10);
/* Enable for GPIOA */
RCC->AHB1ENR |= 1;
/* Enable TIM2 */
RCC->APB1ENR |= 1;
/* Declare PA5 as alternate function mode */
GPIOA->MODER |= (1 << 11);
/* Set PA5 as alternative function AF1 */
GPIOA->AFR[0] |= (0b0001 << 20);
/* Declare the digital output PA5 as push-pull */
GPIOA->OTYPER &= ~(0 << 5);
/* Enable counter and set it as internal clock */
TIM2->CR1 |= 1;
/* Set prescaler for TIM2 - 10000 updates per second */
TIM2->PSC = 49;
/* Set auto-reload for TIM2 */
TIM2->ARR = 100;
/* Set PWM mode 1 */
TIM2->CCMR1 |= (0b110 << 4);
/* Enable the PWM mode */
TIM2->CCER |= 1;
int i = 0;
while(1){
TIM2->CCR1 = i;
i++;
for(int j = 0; j < 10000; j++){}
if(i > 100){
i = 0;
}
}
}
Re: Är det samma metodik att programmera olika processorer?
En joker i dessa sammanhang är 6502. Det finns mig veterligen ingen publik information om var den används och vad det kostar att använda den, men enligt Western Design så säljs den som "fil" man klämmer in när man designar chip, och den lär vara priseffektiv och energieffektiv.
Vill man lära sig den så är det väl enklast att ge sig på att programmera vintagedatorer såsom C64. Dock extremt svårt att veta vilken eventuell marknad det finns för kunskaperna. Jag gissar att ett försäljningsargument från WD är att det finns många entusiaster med kunskap att programmera den i assembler, säkerligen många gånger fler än för alla andra konkurrenter (per styck iaf, men kanske även sammanlagt).
Skulle vilja säga att en av de största orsakerna till framgångarna för Microchip/PIC var att de var mycket lättare att använda dels för hobbyister och dels för anställda på företag med tröga processer för inköp av utvecklingsmiljöer osv. Hobbyisten kunde köpa ett par kretsar och göra en enkel adapter för att programmera kretsarna från en vanlig PC, medan den anställde på trögt företag kunde beställa provex och i övrigt göra samma sak.
Jämför med t.ex. Motorola 68705 som visserligen kunde programmera sig själv, men då enbart genom att hämta innehållet från en minneskrets, så hobbyister behövde antingen en epromemulator eller epromprogrammerare och dessutom behövde både 68705 och eprom:en UV-raderare. Otroligt trög process att först bränna ett eprom och sen bränna 68705 från detta eprom.
Eller jämför Intels mikrokontrollers där det mig veterligen inte fanns några enkla programmerare med schema publicerade, så antingen fick man köpa deras miljöer eller en av de dyrare universalprogrammerare (som t.ex en Unisite). De hade visserligen möjlighet att köra externt eprom, men då tappade man ett gäng I/O-pinnar jämfört med inbyggt minne och dessutom behövde man flytta minneskretsar och ifall man inte var gjord av pengar så behövde man dessutom UV-radera.
Z80 har en fördel här i form av att den går att köra med 0Hz klocka, d.v.s. klocka som står helt still. (Tror iofs det går även med 65C02, alltså nyare variant av 6502). Praktiskt ifall man vill enkelstega för att se vad som händer.
OBS dock att han har en elak race condition i sin klockkrets som han inte verkar sugen på att uppdatera (eller ens ta till sig bristen i). Specifikt så väntar den inte på att en flank är "färdig" på oscillatorn innan växling mellan enkelsteg och oscillator, med resultatet att man kan få en flank som är för kort, med slumpmässig längd, med risk att processorn spårar ur. Vet inte hur en 6502 reagerar på en för kort flank, men det verkar vara en dålig idé.janno skrev: ↑20 februari 2024, 07:05:11Jag kan rekommendera Ben Eaters video serie
https://www.youtube.com/watch?v=HyznrdD ... 5dvjafglHU
https://www.youtube.com/watch?v=LnzuMJL ... z1mu7dp7eH
Lycka till med detta! Det går inte att göra enbart genom att läsa RFC:erna eftersom de säger att man ska ha en "checksumma" utan att förklara hur den beräknas. Det är som om den som skrev RFC:n inte förstod den delen av koden, och sen har alla bara kopierat hur alla andra stackar gör. Jag blir gärna motbevisad här, men då ska det vara faktiskt beskrivet hur checksumman beräknas och inte bara "du fattar väl att såhär räknar man alltid ut en checksumma ifall inget annat anges".
Re: Är det samma metodik att programmera olika processorer?
Finns en RFC från -94 som beskriver checksumman i detalj.
Re: Är det samma metodik att programmera olika processorer?
Det är så man gör, finns inga andra sätt att lära sig.Man får lusläsa referensmanualen som den vore en riktig manual för lärdom.
Re: Är det samma metodik att programmera olika processorer?
Vad tycker du om STM då?MiaM skrev: ↑25 februari 2024, 18:01:04En joker i dessa sammanhang är 6502. Det finns mig veterligen ingen publik information om var den används och vad det kostar att använda den, men enligt Western Design så säljs den som "fil" man klämmer in när man designar chip, och den lär vara priseffektiv och energieffektiv.
Vill man lära sig den så är det väl enklast att ge sig på att programmera vintagedatorer såsom C64. Dock extremt svårt att veta vilken eventuell marknad det finns för kunskaperna. Jag gissar att ett försäljningsargument från WD är att det finns många entusiaster med kunskap att programmera den i assembler, säkerligen många gånger fler än för alla andra konkurrenter (per styck iaf, men kanske även sammanlagt).
Skulle vilja säga att en av de största orsakerna till framgångarna för Microchip/PIC var att de var mycket lättare att använda dels för hobbyister och dels för anställda på företag med tröga processer för inköp av utvecklingsmiljöer osv. Hobbyisten kunde köpa ett par kretsar och göra en enkel adapter för att programmera kretsarna från en vanlig PC, medan den anställde på trögt företag kunde beställa provex och i övrigt göra samma sak.
Jämför med t.ex. Motorola 68705 som visserligen kunde programmera sig själv, men då enbart genom att hämta innehållet från en minneskrets, så hobbyister behövde antingen en epromemulator eller epromprogrammerare och dessutom behövde både 68705 och eprom:en UV-raderare. Otroligt trög process att först bränna ett eprom och sen bränna 68705 från detta eprom.
Eller jämför Intels mikrokontrollers där det mig veterligen inte fanns några enkla programmerare med schema publicerade, så antingen fick man köpa deras miljöer eller en av de dyrare universalprogrammerare (som t.ex en Unisite). De hade visserligen möjlighet att köra externt eprom, men då tappade man ett gäng I/O-pinnar jämfört med inbyggt minne och dessutom behövde man flytta minneskretsar och ifall man inte var gjord av pengar så behövde man dessutom UV-radera.
Z80 har en fördel här i form av att den går att köra med 0Hz klocka, d.v.s. klocka som står helt still. (Tror iofs det går även med 65C02, alltså nyare variant av 6502). Praktiskt ifall man vill enkelstega för att se vad som händer.
OBS dock att han har en elak race condition i sin klockkrets som han inte verkar sugen på att uppdatera (eller ens ta till sig bristen i). Specifikt så väntar den inte på att en flank är "färdig" på oscillatorn innan växling mellan enkelsteg och oscillator, med resultatet att man kan få en flank som är för kort, med slumpmässig längd, med risk att processorn spårar ur. Vet inte hur en 6502 reagerar på en för kort flank, men det verkar vara en dålig idé.janno skrev: ↑20 februari 2024, 07:05:11Jag kan rekommendera Ben Eaters video serie
https://www.youtube.com/watch?v=HyznrdD ... 5dvjafglHU
https://www.youtube.com/watch?v=LnzuMJL ... z1mu7dp7eH
Lycka till med detta! Det går inte att göra enbart genom att läsa RFC:erna eftersom de säger att man ska ha en "checksumma" utan att förklara hur den beräknas. Det är som om den som skrev RFC:n inte förstod den delen av koden, och sen har alla bara kopierat hur alla andra stackar gör. Jag blir gärna motbevisad här, men då ska det vara faktiskt beskrivet hur checksumman beräknas och inte bara "du fattar väl att såhär räknar man alltid ut en checksumma ifall inget annat anges".
Dom har STM8 och STM32 och massa annat. Men deras processorer verkar ha verkligen gjort en enorm framsteg då man kan inprincip få dessa chip nästan gratis, superbillig programmerare som har en debugger inkluderat. Jag menar, jämför man en AVR och en STM32 så framstår ju 32-bittare som alla dagar mer värd än en gammal AVR 8-bit. Detta gäller även PIC.
Däremot verkar det vara hyffsat svårt att programmera register med STM32. Men jag antar bara att detta är en inlärningskurva bara. Det är inte en omöjlighet i allafall.
Re: Är det samma metodik att programmera olika processorer?
Men STM borde faktiskt ge ut en manual. Nu sitter jag bara och försöker använda referensmanualen som den vore en utbildningsmanual. I normala fall så brukar det alltid finnas ett exempel på hur man använder registrerna. Microchip är tydliga med detta.
Men STM ger inte några exempel i sina dokument.