Bra design av SW FIFO
Re: Bra design av SW FIFO
Jag kör FreeRTOS. Jag vet dock inte om det finns något inbyggt, ska kolla i dokumentationen.
Re: Bra design av SW FIFO
Då kan du titta på queues, det finns funktioner anpassade för att köras i ISR vilket borde passa utmärkt.
Re: Bra design av SW FIFO
http://www.freertos.org/Embedded-RTOS-Queues.htmlFreeRTOS Queues
Queues are the primary form of intertask communications. They can be used to send
messages between tasks, and between interrupts and tasks. In most cases they are
used as thread safe FIFO (First In First Out) buffers with new data being sent to the
back of the queue, although data can also be sent to the front.
Re: Bra design av SW FIFO
Haha, nu vart det för enkelt ju! 
Bra att jag har läst dokumentationen noga.
Bra att jag har läst dokumentationen noga.
Re: Bra design av SW FIFO
Woho! Det fungerar perfekt med Queue i FreeRTOS!
Tackar för hjälpen!
En lite fråga bara, när jag vill allokera minne för OSet så vill jag använda CCM-minnet i processorn så de inte behöver kriga med pherial-minnet.
Kan jag använda __attribute__((section(".rtos_heap"))) unsigned char ucHeap[ configTOTAL_HEAP_SIZE ]; för att tvinga kompilatorn att lägga ucHeap vid adressen jag har specificerat i länk-filen (i detta fall .rtos_heap)?
För det syns inte disassembyn om det fungerat eller ej.
Tackar för hjälpen!
En lite fråga bara, när jag vill allokera minne för OSet så vill jag använda CCM-minnet i processorn så de inte behöver kriga med pherial-minnet.
Kan jag använda __attribute__((section(".rtos_heap"))) unsigned char ucHeap[ configTOTAL_HEAP_SIZE ]; för att tvinga kompilatorn att lägga ucHeap vid adressen jag har specificerat i länk-filen (i detta fall .rtos_heap)?
För det syns inte disassembyn om det fungerat eller ej.
Re: Bra design av SW FIFO
Så vitt jag kan se så har du inte sagt ett smack om vilken processor du använder.
Hur tror du att vi ska kunna tycka något om processorspecifika saker
så länge som du hemlighåller det ??
Hur tror du att vi ska kunna tycka något om processorspecifika saker
så länge som du hemlighåller det ??
Re: Bra design av SW FIFO
sojdan: Ah, det är en STM32F4. CCM minne är en vanlig typ av minne som bara CPU Core kommer åt. Det ska dock inte spela någon roll för länkaren vilken MCU det är.
Detta är perfekt för FreeRTOS när det är processorn som gör all som har med minnet att göra och då får OSet (i detta fall) 64kB för sig själv.
Frågan är ganska generell, hur kan jag specificera på vilken adress som min array hamnar?
Kan jag göra det med attribute kommandot? För med den kan man iaf dirigera vart flash hamnar.
Just i mitt fall vill jag ha den på address 0x10000000.
bearing: Jag har tvärr ingen .map-fil. GCC kanske inte genererar en sådan? Eller menar du länk-filen?
Detta är perfekt för FreeRTOS när det är processorn som gör all som har med minnet att göra och då får OSet (i detta fall) 64kB för sig själv.
Frågan är ganska generell, hur kan jag specificera på vilken adress som min array hamnar?
Kan jag göra det med attribute kommandot? För med den kan man iaf dirigera vart flash hamnar.
Just i mitt fall vill jag ha den på address 0x10000000.
bearing: Jag har tvärr ingen .map-fil. GCC kanske inte genererar en sådan? Eller menar du länk-filen?
Re: Bra design av SW FIFO
Länkaren borde kunna generera en map-fil baserat på länk-filen samt källkoden. Kompilatorn har inte en aning om var variablerna kommer läggas, utan den generar symboler (t.ex. @1, @2, osv), som länkaren sedan byter ut till adresser.
Angående attribute-kommandot så beror det på vilken miljö du programmerar i. Ifall du läst det i dokumentationen, så stämmer det säkert. I några miljöerna jag programmerar i används olika "#pragma" för detta, i en annan används något som heter "__declspec" har jag för mig.
Angående attribute-kommandot så beror det på vilken miljö du programmerar i. Ifall du läst det i dokumentationen, så stämmer det säkert. I några miljöerna jag programmerar i används olika "#pragma" för detta, i en annan används något som heter "__declspec" har jag för mig.
Re: Bra design av SW FIFO
Förrutom processor så vet vi inte heller vilka verktyg du har.
Vi har inte heller några länkar till dokumentationen. För att svara
så har man nog behov av dokumentionen samt din "länkfil" och
ett exempel på map-filen. Det vore väldigt märkligt om du inte
kan få fram en map-fil...
> GCC kanske inte genererar en sådan?
Det är alltid *länkaren* som skapar map-filen. Så om länkningen sker
integrerat i GCC så kanske den skapas där. Eller så körs länkningen
som ett separat verktyg och i så fall är det en option/flagga till
den och inte till GCC. Sen så kan du ju ha en övergripande miljö/IDE
där du sätter options för din "build" och, ja, då är det där det görs.
Men vi vet ju i princip ingenting om vad du använder, ja förrutom
vilken processor det är nu.
Vi har inte heller några länkar till dokumentationen. För att svara
så har man nog behov av dokumentionen samt din "länkfil" och
ett exempel på map-filen. Det vore väldigt märkligt om du inte
kan få fram en map-fil...
> GCC kanske inte genererar en sådan?
Det är alltid *länkaren* som skapar map-filen. Så om länkningen sker
integrerat i GCC så kanske den skapas där. Eller så körs länkningen
som ett separat verktyg och i så fall är det en option/flagga till
den och inte till GCC. Sen så kan du ju ha en övergripande miljö/IDE
där du sätter options för din "build" och, ja, då är det där det görs.
Men vi vet ju i princip ingenting om vad du använder, ja förrutom
vilken processor det är nu.
Re: Bra design av SW FIFO
Eller så svarar någon annan som redan vet vad Korken kör för CPU och utvecklingsplattform Sodjan.
Korken, du skall använda "-Xlinker -Map=output.map" som option till gcc så spottar länkaren ut map-filen. Kör "man gcc" så ser du detta.
Korken, du skall använda "-Xlinker -Map=output.map" som option till gcc så spottar länkaren ut map-filen. Kör "man gcc" så ser du detta.
Re: Bra design av SW FIFO
Ah, nu hänger jag med på vad du menar!
Jag kör som toolchain arm-none-eabi (CodeSourcery). Som du säger så är det en extern länkare. Men jag lyckades få den att spotta ur sig .map filen.
Tackar bearing för tipset! Jag hade ingen aning om att man kunde göra på de viset för att se vart sakerna landar!
Och för de som är nyfikna så kan man köra med attribute i arm-none-eabi toolchainen.
Mapdump på den delen:
Jag kör som toolchain arm-none-eabi (CodeSourcery). Som du säger så är det en extern länkare. Men jag lyckades få den att spotta ur sig .map filen.
Tackar bearing för tipset! Jag hade ingen aning om att man kunde göra på de viset för att se vart sakerna landar!
Och för de som är nyfikna så kan man köra med attribute i arm-none-eabi toolchainen.
Mapdump på den delen:
Kod: Markera allt
.rtos_heap 0x10000000 0x6400
0x10000000 . = ALIGN (0x4)
*(.rtos_heap)
.rtos_heap 0x10000000 0x6400 ./FreeRTOS/portable/MemMang/heap_1.o
0x10006400 . = ALIGN (0x4)Re: Bra design av SW FIFO
Är det alltså "-Xlinker -Map=output.map" enligt :
http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
eller kör du en annan länkare än den som är standard i GCC ?
Besvarade MAP filen dina frågor om allokering?
http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html
eller kör du en annan länkare än den som är standard i GCC ?
Besvarade MAP filen dina frågor om allokering?
Re: Bra design av SW FIFO
Vill man veta var en variabel hamnar så kan man även köra t.ex
'nm prog.elf | grep variabelnamn' ( med gnutools)
Vill man specificera var den skall hamna så är det väl bäst att göra det
i länkskriptet 'linker.ld' eller vad det kan heta.
Något man helst vill undvika!
'nm prog.elf | grep variabelnamn' ( med gnutools)
Vill man specificera var den skall hamna så är det väl bäst att göra det
i länkskriptet 'linker.ld' eller vad det kan heta.
Något man helst vill undvika!
