Är det samma metodik att programmera olika processorer?
- Repaterion
- Inlägg: 551
- Blev medlem: 4 februari 2011, 00:57:32
- Ort: Gustavsfors (Lite till vänster om världens utkant)
Re: Är det samma metodik att programmera olika processorer?
Vet inte om det är så fortfarande, men för ca 10-15 år sedan kunde man får prov kretsar från Microchip gratis.
Jag har några PIC16F877A från dem på detta vis, inga monster på något vis men "gott om pinnar", ADC och lite annat myspys.
Har bara meckat Atmega328P och 2560 och PIC12F eller C509 och 16F877A,88, 682 tror jag och en PIC184550, men gav upp lite på den pga config bits, mitt problem är att jag inte fattar hur man skall tolka dessa datablad och register i bland.
Config bits är lite luriga på PIC om man sätter dessa fel, kan skapa en del små intressanta beteenden.
Jag har några PIC16F877A från dem på detta vis, inga monster på något vis men "gott om pinnar", ADC och lite annat myspys.
Har bara meckat Atmega328P och 2560 och PIC12F eller C509 och 16F877A,88, 682 tror jag och en PIC184550, men gav upp lite på den pga config bits, mitt problem är att jag inte fattar hur man skall tolka dessa datablad och register i bland.
Config bits är lite luriga på PIC om man sätter dessa fel, kan skapa en del små intressanta beteenden.
Re: Är det samma metodik att programmera olika processorer?
Det kan vara luddigt med vissa datablad. Jag finner att datablad från Atmel är väldigt snälla mot användaren, till skillnad från STM. Men det är inte en omöjlighet från STM att koda med register, trots att det inte rekommenderas.Repaterion skrev: ↑26 februari 2024, 20:31:52 Vet inte om det är så fortfarande, men för ca 10-15 år sedan kunde man får prov kretsar från Microchip gratis.
Jag har några PIC16F877A från dem på detta vis, inga monster på något vis men "gott om pinnar", ADC och lite annat myspys.
Har bara meckat Atmega328P och 2560 och PIC12F eller C509 och 16F877A,88, 682 tror jag och en PIC184550, men gav upp lite på den pga config bits, mitt problem är att jag inte fattar hur man skall tolka dessa datablad och register i bland.
Config bits är lite luriga på PIC om man sätter dessa fel, kan skapa en del små intressanta beteenden.
TomasL:
Okej. Men då vet jag att det är bara nöta på. Tänkte bara att RCC-diagrammet från STM följde registerna riktigt bra. Då tänkte jag att TIM-diagrammen borde göra likadant.
Re: Är det samma metodik att programmera olika processorer?
Om man tittar på PIC18F8722, så har den 7 st 16-bitars configregister, personligen tycker jag inte de är så obegripliga:
Första registret till exempel
Första registret till exempel
Kod: Markera allt
bit 7 IESO: Internal/External Oscillator Switchover bit
1 = Two-Speed Start-up enabled
0 = Two-Speed Start-up disabled
bit 6 FCMEN: Fail-Safe Clock Monitor Enable bit
1 = Fail-Safe Clock Monitor enabled
0 = Fail-Safe Clock Monitor disabled
bit 5-4 Unimplemented: Read as ‘0’
bit 3-0 FOSC<3:0>: Oscillator Selection bits
11xx = External RC oscillator, CLKO function on RA6
101x = External RC oscillator, CLKO function on RA6
1001 = Internal oscillator block, CLKO function on RA6, port function on RA7
1000 = Internal oscillator block, port function on RA6 and RA7
0111 = External RC oscillator, port function on RA6
0110 = HS oscillator, PLL enabled (Clock Frequency = 4 x FOSC1)
0101 = EC oscillator, port function on RA6
0100 = EC oscillator, CLKO function on RA6
0011 = External RC oscillator, CLKO function on RA6
0010 = HS oscillator
0001 = XT oscillator
0000 = LP oscillator
Re: Är det samma metodik att programmera olika processorer?
PIC är betydligt enklare än STM.
Detta krävs för att aktivera klockan på en STM32:a
Skillnaden är att här så måste vi vänta för att läsa om klockan blev aktiverad.
Detta krävs för att aktivera klockan på en STM32:a
Kod: Markera allt
/* 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));
- Repaterion
- Inlägg: 551
- Blev medlem: 4 februari 2011, 00:57:32
- Ort: Gustavsfors (Lite till vänster om världens utkant)
Re: Är det samma metodik att programmera olika processorer?
Ja det kan jag hålla med om att tex Atmels är snällare, i alla fall de jag blädrat i vilka är 328P och 2560 i skolan.DanielM skrev: ↑26 februari 2024, 20:32:59Det kan vara luddigt med vissa datablad. Jag finner att datablad från Atmel är väldigt snälla mot användaren, till skillnad från STM. Men det är inte en omöjlighet från STM att koda med register, trots att det inte rekommenderas.Repaterion skrev: ↑26 februari 2024, 20:31:52 Vet inte om det är så fortfarande, men för ca 10-15 år sedan kunde man får prov kretsar från Microchip gratis.
Jag har några PIC16F877A från dem på detta vis, inga monster på något vis men "gott om pinnar", ADC och lite annat myspys.
Har bara meckat Atmega328P och 2560 och PIC12F eller C509 och 16F877A,88, 682 tror jag och en PIC184550, men gav upp lite på den pga config bits, mitt problem är att jag inte fattar hur man skall tolka dessa datablad och register i bland.
Config bits är lite luriga på PIC om man sätter dessa fel, kan skapa en del små intressanta beteenden.
Re: Är det samma metodik att programmera olika processorer?
Det är ju som AndLi säger.
STM har väl knappast något intresse av att göra utbildningar kring hur en processor funkar.
Jag fattar inte varför du återkommer till vad dom "borde göra" för att du har ett utbildningsbehov.
Sen undrar jag om du har koll på att det finns datablad och programmerings manualer när det kommer till STM. Dom innehåller olika saker.
Jag får känslan av att du bara kikar i databladet.
För övrigt anser jag det helt ointressant vilka register som gör vad i en modern processor.
Det ger ingenting i praktiken. Det är däremot avgörande att veta hur man konfigurerar periferienheter och funktioner, samt att förstå vilka beroenden som finns.
Att en inställningarna för en prescaler för en specifik timer på en viss processor typ ligger på adress 0x4592 är helt ointressant i synnerhet om du tror att du lär dig hur en processor fungerar med hjälp av den kunskapen.
På nästa modell (till och med i samma familj) är adressen en helt annan.
Följden blir att det du tror skall leda till en djupare kunskap, egentligen bara leder till att du börjar skapa kod som inte fungerar på andra processorer.
Den enda gången du kan ha nytta av kunskapen är vid debugging, för att verifiera att register är rätt satta, men då kan man djupdyka i det speciella fallet som jag ser det.
Re: Är det samma metodik att programmera olika processorer?
Det var bara en åsikt.
Jag kollar lite överallt. För att veta deras register så ska man titta i referensmanualen.Sen undrar jag om du har koll på att det finns datablad och programmerings manualer när det kommer till STM. Dom innehåller olika saker.
Jag får känslan av att du bara kikar i databladet.
Jag har märkt att STM förväntar sig INTE att deras användare ska sitta och plöja register.För övrigt anser jag det helt ointressant vilka register som gör vad i en modern processor.
Det ger ingenting i praktiken. Det är däremot avgörande att veta hur man konfigurerar periferienheter och funktioner, samt att förstå vilka beroenden som finns.
STM väljer att deras användare ska minst använda HAL-biblioteket, och i bästa fall använda deras utvecklingsverktyg CubeMX.
Dom vill att folk ska använda utgå från färdiga exempel också.
Nu har jag plöjt register fram och tillbaka. Jag känner mig inte något direkt smartare, snarare uthålligare på läsa datablad.
Re: Är det samma metodik att programmera olika processorer?
ST vill att man ska använda deras HAL bibliotek och gärna också cubeMX för att det ska vara svårt att byta mcu till en annan, men som egentligen mycket väl skylle kunna köra samma (men omkompilerad) kod om man istället använder cmsis eller std peripheral library.
Re: Är det samma metodik att programmera olika processorer?
ST vill väll att man ska använda deras HAL för att spara tid, snarare.
Alla uC tillverkare har väll något HAL antar jag? Microchip Studio har ju Atmel Start, vilket är exakt som CubeMX.
Skulle knappast tro att det är ekonomiskt försvarbart att plöja register hela tiden. Men det är dock kul att sätta register. Blir liksom väldigt lite kod.
Alla uC tillverkare har väll något HAL antar jag? Microchip Studio har ju Atmel Start, vilket är exakt som CubeMX.
Skulle knappast tro att det är ekonomiskt försvarbart att plöja register hela tiden. Men det är dock kul att sätta register. Blir liksom väldigt lite kod.
Re: Är det samma metodik att programmera olika processorer?
Visst, det är en sida av myntet, men cubemx hade lika gärna kunnat genenera cmsis eller std peripheral lib kod istället för STs egna HAL.
Re: Är det samma metodik att programmera olika processorer?
Att använda färdiga bibliotek sparar möjligen lite tid vid utvecklingen, men som pfyra är inne på så ger det en inlåsning som tenderar att göra att det blir svårare att lämna den tillverkaren.
De flesta företag är ju såna att de gärna vill låsa in kunderna, det är oftast ett billigare sätt för företag att behålla kunderna än att hela tiden behöva se till att man är ett bättre val än konkurrenterna.
De flesta företag är ju såna att de gärna vill låsa in kunderna, det är oftast ett billigare sätt för företag att behålla kunderna än att hela tiden behöva se till att man är ett bättre val än konkurrenterna.
Re: Är det samma metodik att programmera olika processorer?
Om ni undrar vad jag sysslar med nu så håller jag på bygga egen linux-dator.
Hittade utvecklingskittet STM32MP157 som man kan installera OpenSTLinux på.
Då tänkte jag att jag bygger egen dator från grunden. Metodiken verkar vara väldigt lik oavsett vilken processor det är.
Det jag gör är att jag tittar på befintligt exempel som ST erbjuder. Sedan gör jag likadant, med lite modifikationer. Jag antar att det är så här som ett vanligt arbetssätt ser ut när man konstruerar saker?
Hittade utvecklingskittet STM32MP157 som man kan installera OpenSTLinux på.
Då tänkte jag att jag bygger egen dator från grunden. Metodiken verkar vara väldigt lik oavsett vilken processor det är.
Det jag gör är att jag tittar på befintligt exempel som ST erbjuder. Sedan gör jag likadant, med lite modifikationer. Jag antar att det är så här som ett vanligt arbetssätt ser ut när man konstruerar saker?