Är det samma metodik att programmera olika processorer?
Re: Är det samma metodik att programmera olika processorer?
Nu beror det ju på vilken PIC-processor som det handlar om, men i 8bitars processorerna körs många av instruktionerna på en klockcykel.
Det har ingenting med säkerhetskritiska system att göra.
Det är precis lika säkert eller osäkert om det tar en eller flera klockcykler att utföra instruktionen.
Det har ingenting med säkerhetskritiska system att göra.
Det är precis lika säkert eller osäkert om det tar en eller flera klockcykler att utföra instruktionen.
Re: Är det samma metodik att programmera olika processorer?
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.
Re: Är det samma metodik att programmera olika processorer?
Hur som helst! Måste komma igång lite. Blivit mycket prat nu.
Jag har ATMega328P, alltså Atmel AVR, inte Microchip AVR (antar att det är 100% det samma).
Vilka verktyg ska jag använda? Ska jag använda MPLAB X eller Microchip Studio?
Kan jag använda min Arduino Mega 2560 som har ISP, som programmerare?
Vilket utbildnigsmaterial ska jag använda:
https://developerhelp.microchip.com/xwi ... g-started/
Eller
Övriga saker så som kopplingsdäck med mera, har jag redan.
Jag har ATMega328P, alltså Atmel AVR, inte Microchip AVR (antar att det är 100% det samma).
Vilka verktyg ska jag använda? Ska jag använda MPLAB X eller Microchip Studio?
Kan jag använda min Arduino Mega 2560 som har ISP, som programmerare?
Vilket utbildnigsmaterial ska jag använda:
https://developerhelp.microchip.com/xwi ... g-started/
Eller
Övriga saker så som kopplingsdäck med mera, har jag redan.
Re: Är det samma metodik att programmera olika processorer?
Jag har börjat kunna programmera min Arduino Mega 2560 via Microchip Studio. Jag har dock inte lyckats använda denna som ISP. Försöker klura på detta varför det krånglar för mig när jag försöker använda min Arduino Mega som ISP programmerare via Microchip Studio.
Hur som helst så har jag lyckats bränna över en kod för att blinka med en LED-lampa Jag måste säga att jag är imponerad över denna minimala kod man skriver för att få något att fungera. I STM32 så hade man fått skriva betydligt mycket mer! Än fast jag kommer fortfarande använda STM32 för större projekt.
Är det någon här som vet om det går att använda Arduino Mega 2560 som ISP så jag slipper köpa in en PicKit 5 för 2000 kr?
Denna kod har jag skrivit
Jag börjar med att aktivera riktningen så det är en utgång.
Där efter så aktiverar jag utgången hög och låg.
För att det är pinne PB7 som jag måste aktivera hos min Arduino Mega
Hur som helst så har jag lyckats bränna över en kod för att blinka med en LED-lampa Jag måste säga att jag är imponerad över denna minimala kod man skriver för att få något att fungera. I STM32 så hade man fått skriva betydligt mycket mer! Än fast jag kommer fortfarande använda STM32 för större projekt.
Är det någon här som vet om det går att använda Arduino Mega 2560 som ISP så jag slipper köpa in en PicKit 5 för 2000 kr?
Denna kod har jag skrivit
Kod: Markera allt
#define F_CPU 16000000UL
#include <avr/io.h>
#include <util/delay.h>
int main(void)
{
// Aktivera direction register för utgång
DDRB |= (1 << PB7);
while (1)
{
// Aktivera port B7
PORTB |= (1 << PB7);
_delay_ms(1000);
// Avaktivera port B7
PORTB &= (0 << PB7);
_delay_ms(1000);
}
}
Du har inte behörighet att öppna de filer som bifogats till detta inlägg.
Re: Är det samma metodik att programmera olika processorer?
Nu har jag lyckats att använda en Arduino Mega som ISP för en ATmega328P med hjälp av Microchip Studio.
I många manualer på internet så ska man använda detta kommando med Microchip Studio.
Men egentligen så är det flaggan -D som ska bort.
Man kopplar bara ihop SPI-bussarna mellan Arduino Mega och ATMega328P och reset ska kopplas till pinne 10 hos Arduinon. Inga kondensatorer eller liknande komponenter krävs. Bara kablar.
Detta är utskrift i Arduino IDE:
Detta är utskriften i Microchip Studio
Bra! Det fanns lite olikheter dock, men det fungerar. Undra vad man ska göra nu??? Några förslag på häftiga projekt?
I många manualer på internet så ska man använda detta kommando med Microchip Studio.
Kod: Markera allt
-C"C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -v -patmega328p -cstk500v1 -PCOM9 -b19200 -D -Uflash:w:"$(ProjectDir)Debug\$(TargetName).hex":i
Men egentligen så är det flaggan -D som ska bort.
Kod: Markera allt
-C"C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -v -patmega328p -cstk500v1 -PCOM9 -b19200 -Uflash:w:"$(ProjectDir)Debug\$(TargetName).hex":i
Detta är utskrift i Arduino IDE:
Kod: Markera allt
Sketch uses 136 bytes (0%) of program storage space. Maximum is 32256 bytes.
Global variables use 0 bytes (0%) of dynamic memory, leaving 2048 bytes for local variables. Maximum is 2048 bytes.
C:\Users\dmn\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/bin/avrdude -CC:\Users\dmn\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf -v -patmega328p -cstk500v1 -PCOM9 -b19200 -Uflash:w:C:\Users\dmn\AppData\Local\Temp\arduino_build_959726/Blink.ino.hex:i
avrdude: Version 6.3-20190619
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:\Users\dmn\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf"
Using Port : COM9
Using Programmer : stk500v1
Overriding Baud Rate : 19200
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : STK500
Description : Atmel STK500 Version 1.x firmware
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.02s
avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "C:\Users\dmn\AppData\Local\Temp\arduino_build_959726/Blink.ino.hex"
avrdude: writing flash (136 bytes):
Writing | ################################################## | 100% 0.28s
avrdude: 136 bytes of flash written
avrdude: verifying flash memory against C:\Users\dmn\AppData\Local\Temp\arduino_build_959726/Blink.ino.hex:
avrdude: load data flash data from input file C:\Users\dmn\AppData\Local\Temp\arduino_build_959726/Blink.ino.hex:
avrdude: input file C:\Users\dmn\AppData\Local\Temp\arduino_build_959726/Blink.ino.hex contains 136 bytes
avrdude: reading on-chip flash data:
Reading | ################################################## | 100% 0.16s
avrdude: verifying ...
avrdude: 136 bytes of flash verified
avrdude done. Thank you.
Kod: Markera allt
avrdude.exe: Version 6.3-20190619
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf"
Using Port : COM9
Using Programmer : stk500v1
Overriding Baud Rate : 19200
AVR Part : ATmega328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
Programmer Type : STK500
Description : Atmel STK500 Version 1.x firmware
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.03s
avrdude.exe: Device signature = 0x1e950f (probably m328p)
avrdude.exe: safemode: lfuse reads as FF
avrdude.exe: safemode: hfuse reads as DE
avrdude.exe: safemode: efuse reads as FD
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: reading input file "C:\Users\dmn\Downloads\test\GccApplication2\GccApplication2\Debug\GccApplication2.hex"
avrdude.exe: writing flash (186 bytes):
Writing | ################################################## | 100% 0.28s
avrdude.exe: 186 bytes of flash written
avrdude.exe: verifying flash memory against C:\Users\dmn\Downloads\test\GccApplication2\GccApplication2\Debug\GccApplication2.hex:
avrdude.exe: load data flash data from input file C:\Users\dmn\Downloads\test\GccApplication2\GccApplication2\Debug\GccApplication2.hex:
avrdude.exe: input file C:\Users\dmn\Downloads\test\GccApplication2\GccApplication2\Debug\GccApplication2.hex contains 186 bytes
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100% 0.16s
avrdude.exe: verifying ...
avrdude.exe: 186 bytes of flash verified
avrdude.exe: safemode: lfuse reads as FF
avrdude.exe: safemode: hfuse reads as DE
avrdude.exe: safemode: efuse reads as FD
avrdude.exe: safemode: Fuses OK (E:FD, H:DE, L:FF)
avrdude.exe done. Thank you.
Re: Är det samma metodik att programmera olika processorer?
Blinka en LED på en GPIO först? Sen sätta upp en timer i PWM-läge och koppla den till en utgång och PWM:a en LED?
Ganska enkelt, men läs manualen. DDRB är för data direction och PORTB för att sätta hög/låg. Sätter du en pinne som ingång men ändå skriver 1 till pinnen i PORTB så slår du på intern pull-up för den pinnen.
Läs om Timer i databladet. Prova FAST PWM kanske.
Ganska enkelt, men läs manualen. DDRB är för data direction och PORTB för att sätta hög/låg. Sätter du en pinne som ingång men ändå skriver 1 till pinnen i PORTB så slår du på intern pull-up för den pinnen.
Läs om Timer i databladet. Prova FAST PWM kanske.
Re: Är det samma metodik att programmera olika processorer?
Ja, men jag måste ha ett mål. Nu när jag har fått igång verktygen för att kunna programmera dessa processorer, utan att behöva köpa in en Pickit 5 som kostar skjortan.
Jag vet inte varför man ska välja AVR, förutom priset. Det är en av dom billigaste på marknaden. Men något syfte fyller dom iallafall.
Jag vet inte varför man ska välja AVR, förutom priset. Det är en av dom billigaste på marknaden. Men något syfte fyller dom iallafall.
Re: Är det samma metodik att programmera olika processorer?
Jag har faktiskt en gång suttit och försökt skriva en text om hur man designar en enkel processor, just med avsikten att ha ett enkelt exempel att förklara med.
Det är ju ett antal fasta byggblock som man använder, sen kan vissa av dessa byggblock förekomma i flera instanser och med olika komplexitet, men grunderna är ju relativt enkla.
Ex. en ALU tar 1-2 invärden, en instruktion om vilken operation som ska utföras och ger ett utvärde och ett gäng flaggor (zero, carry, negative etc) baserat på operationens resultat.
I många processorer kan ALU bara arbeta med register, så om man ska jämföra två värden (vilken man gör genom en subtraktion) behöver man först läsa in dessa i varsit register och sen säga åt ALU att subtrahera dem. ALU ger då dels differensen (men den kan man förkasta om man vill, ofta har ALU en compare-instruktion som blockerar differensen och bara sätter flaggorna), och sen sätts flaggorna. Flaggorna indikerar om differensen blev noll (värdena var lika) eller om det ena var större än det andra (negative eller inte). Sen har man instruktioner som gör olika saker baserat på vad flaggorna säger, oftast är det ju nån form av hopp.
Hopp å sin sida kan vara direkta eller relativa, d.v.s. antingen säger instruktionen "hoppa till den adressen" eller så säger den "addera detta värde till adressen" (om värdet är negativt blir det en subtraktion).
För att läsa in värden från minne eller I/O så lägger processorn ut en adress på adressbussen (det kan finnas separata bussar för minne och I/O) och öppnar sen latchar mellan databussen och det register man ska läsa in till eller skriva från).
Jag tror detta är grundoperationerna i de flesta processorer, eller har jag glömt nåt?
Det varierar ju också huruvida programmet ligger i samma minne som data. Det kan vara olika ordlängd på programminne och dataminne. Dataminne är ju oftast multiplar av 8, men programminnet kan t.ex. vara 18 bitar brett för man tyckte det behövdes så många bitar för att få in alla instruktioner.
Det är ju ett antal fasta byggblock som man använder, sen kan vissa av dessa byggblock förekomma i flera instanser och med olika komplexitet, men grunderna är ju relativt enkla.
Ex. en ALU tar 1-2 invärden, en instruktion om vilken operation som ska utföras och ger ett utvärde och ett gäng flaggor (zero, carry, negative etc) baserat på operationens resultat.
I många processorer kan ALU bara arbeta med register, så om man ska jämföra två värden (vilken man gör genom en subtraktion) behöver man först läsa in dessa i varsit register och sen säga åt ALU att subtrahera dem. ALU ger då dels differensen (men den kan man förkasta om man vill, ofta har ALU en compare-instruktion som blockerar differensen och bara sätter flaggorna), och sen sätts flaggorna. Flaggorna indikerar om differensen blev noll (värdena var lika) eller om det ena var större än det andra (negative eller inte). Sen har man instruktioner som gör olika saker baserat på vad flaggorna säger, oftast är det ju nån form av hopp.
Hopp å sin sida kan vara direkta eller relativa, d.v.s. antingen säger instruktionen "hoppa till den adressen" eller så säger den "addera detta värde till adressen" (om värdet är negativt blir det en subtraktion).
För att läsa in värden från minne eller I/O så lägger processorn ut en adress på adressbussen (det kan finnas separata bussar för minne och I/O) och öppnar sen latchar mellan databussen och det register man ska läsa in till eller skriva från).
Jag tror detta är grundoperationerna i de flesta processorer, eller har jag glömt nåt?
Det varierar ju också huruvida programmet ligger i samma minne som data. Det kan vara olika ordlängd på programminne och dataminne. Dataminne är ju oftast multiplar av 8, men programminnet kan t.ex. vara 18 bitar brett för man tyckte det behövdes så många bitar för att få in alla instruktioner.
Re: Är det samma metodik att programmera olika processorer?
Men är det verkligen så att om man kan programmera AVR så kan man programmera ARM? Jag tvivlar lite på detta med tanke på att metodiken att sätta registerna skiljer sig enormt.
Med ARM så måste man sätta massvis med register. Med AVR så är det bara fåtal register man måste sätta. För att blinka med en LED-lampa så är det 2 registertyper man måste skriva till. För att göra exakt samma sak med ARM så är det betydligt många flera register man måste skriva till.
Jag tror för PIC är det något mindre jämfört med ARM, men det är något mer för AVR.
Med ARM så måste man sätta massvis med register. Med AVR så är det bara fåtal register man måste sätta. För att blinka med en LED-lampa så är det 2 registertyper man måste skriva till. För att göra exakt samma sak med ARM så är det betydligt många flera register man måste skriva till.
Jag tror för PIC är det något mindre jämfört med ARM, men det är något mer för AVR.
Re: Är det samma metodik att programmera olika processorer?
Det räcker garanterat med att skriva till ett register för att blinka en LED oavsett processorarkitektur.
MEN:
Portarnas funktioner måste ställa in på något sätt då de nästan alltid har flera olika funktioner överlagrade.
På din AVR och de enklare PICarna har portarna i regel bara 2 funktioner, INgång eller UTgång, då räcker det med att ställa DDR-registret.
Men om porten har en massa andra överlagrade funktioner så måste porten konfigureras på diverse olika sätt, ju mer komplicerad processor desto mer konfiguration.
Så på en ARM-Processor eller en MIPS-processor och även på de lite mer komplicerade standard PIC-processorerna så kan man behöva stänga av vissa funktioner, tala om för processorn att portXY skall användas och den finns på den fysiska pinnen N, och porten skall ha funktion Z osv.
Det blir naturligtvis en del register att konfigurera, dock gör man ju det i regel bara en gång i sitt program, i starten där man initierar hårdvaran.
Det är just denna kod som de grafiska verktygen skapar och maskerar för användaren.
MEN:
Portarnas funktioner måste ställa in på något sätt då de nästan alltid har flera olika funktioner överlagrade.
På din AVR och de enklare PICarna har portarna i regel bara 2 funktioner, INgång eller UTgång, då räcker det med att ställa DDR-registret.
Men om porten har en massa andra överlagrade funktioner så måste porten konfigureras på diverse olika sätt, ju mer komplicerad processor desto mer konfiguration.
Så på en ARM-Processor eller en MIPS-processor och även på de lite mer komplicerade standard PIC-processorerna så kan man behöva stänga av vissa funktioner, tala om för processorn att portXY skall användas och den finns på den fysiska pinnen N, och porten skall ha funktion Z osv.
Det blir naturligtvis en del register att konfigurera, dock gör man ju det i regel bara en gång i sitt program, i starten där man initierar hårdvaran.
Det är just denna kod som de grafiska verktygen skapar och maskerar för användaren.
Re: Är det samma metodik att programmera olika processorer?
För att förtydliga.
"Förr" i tiden var processorns periferienheter "Hårdkodade" till specifika fysiska pinnar.
På många moderna processorer är det inte så längre, utan periferienheterna kan flyttas till valfria fysiska pinnar.
Säg att du hdesignar ett antal produkter, för att få en enkel och bra kretskortslayout så vill du ha specifika funktioner på specifika fysiska pinnar, så:
Produkt nummer 1 vill du ha en databuss på pinnarna 1-8
Produkt nummer 2 på pinnarna 26-33
Produkt nummer 3 på pinnarna 51-58.
Av olika skäl vill du använda samma processor på alla tre produkterna.
Databussen är en specifik periferienhet, som kanske måste använda halva port G och halva port C.
Men processorn har den egenskapen att du kan mappa valfria funktioner till valfri fysisk pinne.
Då måste du skriva en massa kod som initierar denna periferienhet, stänger av normala portfunktioner, flyttar de enskilda bitarna för porten till de ben du vid varje design önskar använda.
Och ja det blir en jäkla massa initieringskod att skriva, vilket då det grafiska gränssnitten, ST-CUBEX eller Microchip Harmony gör åt dig.
"Förr" i tiden var processorns periferienheter "Hårdkodade" till specifika fysiska pinnar.
På många moderna processorer är det inte så längre, utan periferienheterna kan flyttas till valfria fysiska pinnar.
Säg att du hdesignar ett antal produkter, för att få en enkel och bra kretskortslayout så vill du ha specifika funktioner på specifika fysiska pinnar, så:
Produkt nummer 1 vill du ha en databuss på pinnarna 1-8
Produkt nummer 2 på pinnarna 26-33
Produkt nummer 3 på pinnarna 51-58.
Av olika skäl vill du använda samma processor på alla tre produkterna.
Databussen är en specifik periferienhet, som kanske måste använda halva port G och halva port C.
Men processorn har den egenskapen att du kan mappa valfria funktioner till valfri fysisk pinne.
Då måste du skriva en massa kod som initierar denna periferienhet, stänger av normala portfunktioner, flyttar de enskilda bitarna för porten till de ben du vid varje design önskar använda.
Och ja det blir en jäkla massa initieringskod att skriva, vilket då det grafiska gränssnitten, ST-CUBEX eller Microchip Harmony gör åt dig.
Re: Är det samma metodik att programmera olika processorer?
Halleluja för dom grafiska verktygen. Men man blir rätt okunnig med dom faktiskt. När jag hade en bugg i STM32CubeIDE så var det liksom....kört. Jag fick vänta tills ST hade fixat buggen, vilket kunde ta månader.
Men jag gillar verkligen deras processorer. Dom har verkligen allt, för ett billigt pris. 70-100 kr för en processor brukar jag handla för om jag ska göra något stort t.ex. radarsystem eller bilddetektion.
Men för små system som knappt får kosta något. Då passar inte STM32.
Men jag gillar verkligen deras processorer. Dom har verkligen allt, för ett billigt pris. 70-100 kr för en processor brukar jag handla för om jag ska göra något stort t.ex. radarsystem eller bilddetektion.
Men för små system som knappt får kosta något. Då passar inte STM32.
Re: Är det samma metodik att programmera olika processorer?
Som sagt alla sådana verktyg döljer en massa saker för användaren, vilket gör att användaren, om han bara använt sådana verktyg inte har en chans att kunna fixa till några fel, som verktyget har åstakommit, då användaren tyvärr oftast saknar egentlig kunskap om det han/hon gör.
Man väljer i princip alltid en processor som är optimal för den enskilda applikationen.
Man väljer i princip alltid en processor som är optimal för den enskilda applikationen.
Re: Är det samma metodik att programmera olika processorer?
Har du några förslag på projekt?
Jag är väldigt intresserad utav applikationer som kan kopplas upp på nätverket.
Jag är väldigt intresserad utav applikationer som kan kopplas upp på nätverket.
Re: Är det samma metodik att programmera olika processorer?
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.