abhi29091996 wrote on Saturday, August 26, 2017:
I want to port Freertos on custom ip core so i want help for full understanding of port.c and portmacro.h files
abhi29091996 wrote on Saturday, August 26, 2017:
Ip core is 32 bit risc with 512kB flash 64kB sram microcontroller.Its basic microcontroller ip core develop by me.
rtel wrote on Sunday, August 27, 2017:
That is not something that can be easily described generically as it is
very dependent on the characteristics of the hardware. Here is just a
starting point: http://www.freertos.org/FreeRTOS-porting-guide.html
abhi29091996 wrote on Sunday, August 27, 2017:
Thank you very much for your quick answer.I have learned all the basics and code flow of porting but still there are some points of code which is confusing me.like on some 32bit platform portByteAlignment is defined to 8byte why its so shouldn’t be 4byte.Can you please describe reason for this in detail.Now onwards i will post my que only.
richard_damon wrote on Sunday, August 27, 2017:
Some processors even though is may be a ‘32 bit’ processor, may still require some 64 bit objects be aligned on 64 bit boundries. The Arm ABI for instance has this rule as I remember.
abhi29091996 wrote on Sunday, August 27, 2017:
Thanks for answer @Richard Damon.What is ABI of arm i dont know can you please elaborate.I want to port rtos on customised IP core which require indepth knowledge of every thing in port.c and portmacro.h file.
richard_damon wrote on Sunday, August 27, 2017:
The Arm Corporation piublishes a document defining the Arm Archetecture Application Binary Interface (one link to it would be
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/index.html )
It documents what they consider the standard rules for an implementation to generate working code for Arm processors (A guess that the port you are looking at was for one of the Arm chips). Most procrssores have a similar document, generally made public if they want others to write tools from them, maybe kept internal if they don’t. If the chip manufacture doesn’t publish such a document, then the tool creator will need to generate something like this and publish it if they wish to be able to interact with other tools so they can follow a compatible method.
You say you are using ‘custom IP’, the creator of that IP (maybe you) needs to document how to do basic operations like save and restore the full state of the procesor. If you read through port.c and portmacro.h, there are a number of macros and functions to do operations. The effects of these operations are fairly well documented in the various ports. The person creating the port (likely YOU), needs to look at the documentation for the processor and figure out how you acheive those goals. You don’t necessarily need to know all the whys someother port made its decision (though they might help point out some gotchas that might exist in your processor, like the fact that some Arm Architectures, even though they are ‘32 bit’ architectures, needs some thing aligned to 64 bit boundies). What you really need is the indepth knowledge of the processor you are porting to.
rtel wrote on Sunday, August 27, 2017:
like on some 32bit platform portByteAlignment is defined to 8byte
Did you say you designed the custom IP? If so, then you will know if it needs 8-byte alignment or not. We cannot tell you as we don’t know what the IP you have designed does. If it has instructions or registers that require 8-byte alignment then you need to set the port layer to use 8-bytes. If your IP has a floating point unit, wide registers, instructions that are optimized for 8-byte alignment (like multi-byte push or pop instructions), then it will be likely 8-byte alignment is required.
What is ABI of arm i dont know can you please elaborate
I just Googled “ARM ABI” and it was the top link.
abhi29091996 wrote on Monday, August 28, 2017:
Thanks.I got it.Another que is in documentation of memory there are two memory address spaces virtual and physical and they have written that cpu use virtual address space for their instruction operation and physical address space is available for dma ports.For portinitializestack and for other mem func implementation which address space should i consider.
richard_damon wrote on Monday, August 28, 2017:
Since the stack is used for instructions, I would suspect that it would be use the virtual address space.
This sounds like the processor has an MMU, so you may want to look at examples that use an MMU. If I remember right, I think these tend to work by setting Virtual Address == Physical Addresss and use the MMU as access protection for selected tasks. The Core of FreeRTOS isn’t built to handle address translation between tasks, so the whole application uses the same address mapping, restricted tasks just being limited in what parts they can access/write to.
abhi29091996 wrote on Tuesday, August 29, 2017:
I dont know how to write portInitializeStack function for any controller.FreeRTOS porting guide is saying that this function must be implemented first.Any detailed procedure for this?.please help me to understand this.
richard_damon wrote on Tuesday, August 29, 2017:
First, you need to decide/figure out how a stack frame that saves the whole state of a task will look. This will be very dependent on the target processor, as this will be controlled by its way of handling entry/exits into interrupts. I suppose that even before you do this, you need to decide what methods/interrupts will be used to perform the basic task switch. In some processors, like the Arm, there is a very low priority, software triggered interrupt that is used to run the scheduler and change tasks. This allows interrupts at several levels to trigger this interrupt, and when all other interrupts are done, the scheduler can run and switch to the highest priority task. Other processors, which might not have such a feature, may have the ISRs call the scheduler which might change what stack the ISR returns to. This may give issues with nesting interrupts.
Once you have a stack frame designed, you need to create a portInitializeStack that sets up such a frame in a manner that it acts like a call to the specified task function.
abhi29091996 wrote on Tuesday, August 29, 2017:
Thanks @Richard Damon.Right now i am exploring about stack frame design.I will be back if stuck at any point.
abhi29091996 wrote on Wednesday, August 30, 2017:
Why sei(Set Interrupt) is not there is portExitCritical() macro of …/…/source/Portable/GCC/aTmega323/portmacro.h line 121.I want detailed explaination for this.
richard_damon wrote on Wednesday, August 30, 2017:
Critical Sections are supposed to nest, so the sequence
portENTER_CRITICAL();
portENTER_CRITICAL();
portEXIT_CRITICAL();
portEXIT_CRITICAL()
should not re-enable the interrupts until the SECOND portEXIT_CRITICAL() call. I am not familiar with this port, but it looks like these macros are saving the state of the SREG (which I presume includes the interrupt enable bit) and restoring it,
rtel wrote on Wednesday, August 30, 2017:
I am confused by this thread. Have you really developed your own MCU
core? That is an advanced thing to do, but you are asking some basic
questions - basic questions are fine there just seems to be a
contradiction to how the thread started.
As regards to your last question, why critical sections must be
nest-able. Apply some logical thinking to real world function call
scenarios, where application code calls middlewhere code that calls
driver code that calls library code for the case where critical sections
are nestable, and the case where critical sections are not nestable,
then perhaps you can tell us your own conclusion as to whether they need
to be nestable or not. [hint: I’ve basically given you the answer here]
abhi29091996 wrote on Thursday, August 31, 2017:
Yes its developed but,not by me.Its developed by one of my senior and i just want to port RTOS so, i can develop skill of porting.I am totally new to RTOS so, thats why some times basic que is thrown by my side.