|
|
FreeRTOS Interactive
|
Hi All,
I am providing this build as an updated MicroBlaze port with an included Firmware Design for the Xilinx Spartan-3A DSP 1800A Starter Kit/Board. I plan to update it in the near future with LwIP support on the EthernetLite MAC.
Please see the included readme.
All feed back welcome.
William,
I just now saw this post (I don't check this forum often enough apparently). Is your port related at all to the one I posted, which is in this Xilinx forum under the "up-to-date GCC/MicroBlaze port" thread?
Regards,
Tyrel
Hi Tyrel,
No, the port isn't related.
I had to do the work as part of my professional commitments. I used the official but out-of-date FreeRTOS port and updated the port layer to support the 12.1 XDK, enabled and tested instruction and data caching and wrote drivers for various peripherals including different Ethernet MACs. After the project was delivered, I fed the updates back here. As part of the testing I added LwIP support which I am still yet to release.
However, I believe that Richard will be delivering an updated Microblaze port into the main line soon (if he hasn't done so already).
Regards,
William
William,
Sounds like a similar story to myself, though it sounds like you had more time to polish it further than I did. That said, the version that I did post is quite out of date from my perspective. I haven't had a chance to look over what you posted so I don't know how it compares to my port. The one thing I have done a lot lately with my port is integrating it into the SDK toolchain flow so that FreeRTOS can be selected as a BSP (i.e. instead of standalone or xilkernal). This makes it significantly easier to bring the port into new projects but requires the necessary library definition files (MLDs) and TCL scripts to process the user's requested settings via the libgen instantiation. Does your port include this, or is it layered on top of the standalone BSP (similar to the way xilkernal is)? Similarly, I also encapsulated the latest lwIP code (version 1.4 at least) along with my version of the FreeRTOS port layer into an SDK-compatible library.
Overall, creating a useable BSP for FreeRTOS that works with the various drivers provided by Xilinx was a real pain (but worth the effort in the end) because of the various #include requirements of the different drivers. If you did not layer your port on top of the standalone BSP, I'm also curious how you handled exceptions since you will want to have created an exception handler that does something useful in the FreeRTOS context of operation. This is something I have only half-done at the moment.
Basically, I'm looking to see if there is anything I can contribute to your port so that we can have one go-to MicroBlaze port rather than multiple options out there.
Also, I assume you had to write a new driver for either the emaclite or temac peripherals (or both)? I don't have a license for the temac, so I only wrote a fresh driver for the emaclite. This was quite challenging to get right while maintaining high emaclite throughput. The Xilinx provided driver for the emaclite is not exactly efficient and the emaclite peripheral itself doesn't help things with its memory alignment requirements.
Regards,
Tyrel
Hi Tyrel,
I would tend to agree. It makes a lot of sense to have a single go-to project.
You are right, there seems to be quite a large amount of interest in integrating into the BSP. Indeed, our then customer had done their own integration, writing the various TCL scripts and I received feedback from them on how to expose the various definitions that change from project to project. However, I didn't investigate this myself as it wasn't really part of the project work.
I don't recall doing anything with the exception handlers, at the most stubbing them, which may not even be in this public release. Quite often, the action to take when an exception is thrown is very application specific. Should the task be deleted? What needs to be notified? Does the whole system need to be reset? Most exception causes should really be found during development and removed. In this respect, exceptions and other non-maskable interrupts tend only to have stub definitions at the RTOS port level.
I wrote a driver for the EmacLite and the TEMAC in both LLDMA and LLFIFO modes. These were all written with the InterNiche TCP/IP NicheStack as the target. For my initial LwIP implementation, I reused the TEMAC LLDMA driver which is reasonably flexible and quite fast. I plan to rework my EmacLite drivers as well, given the license requirement for the TEMAC core.
There is going to be an update to the official FreeRTOS MicroBlaze port in the very near future that includes the various features like the BSP integration and drivers for the Ethernet with LwIP.
Given the imminent arrival of said port, it may be worthwhile holding fire. What do you reckon?
Regards,
William
Just for the record, post 4 in this thread: http://sourceforge.net/projects/freertos/forums/forum/382005/topic/4600288 provides a link to the documentation page and source code for the new, soon to be official, FreeRTOS port. Please read the caveats in the thread. There is also some TCL, etc, code for BSP integration too, but that is not released yet. I'm not sure the code is as sophisticated as Tyrel's. The code will be incorporated into the next FreeRTOS release, which will be when I have had time to integrate the Ethernet bits.
Regards.
Richard,
Are you doing the port for the Spartan-6 dev board, or is somebody else?
I looked over the page and the source code. You technically have not supplied a BSP-version of FreeRTOS. The definition of this is certainly NOT made clear by Xilinx however and it took me quite awhile to figure what their conventions are. The way you packaged it is the way I initially did it as well and is probably the easiest, but perhaps not the best for the end-user. You are supplying FreeRTOS as (what I call) "application code" and are basing it on top of the "standalone" BSP which is built as a library that is ultimately linked into the application project. I prefer to take the term BSP to literally mean "operating system with additional libraries and drivers as necessary". What I have done (but not publicly released), is packaged up FreeRTOS as a BSP that is completely independent of the "standalone" BSP. This means that when you create a new "Board Support Package" project in the SDK, you can select FreeRTOS as the operating system and base platform (instead of "standalone" or "xilkernal")--something that I believe to be quite useful when starting a new project. Additionally, I believe some of the "standalone" BSP code will always conflict with the low-level "porting code" that is required to make FreeRTOS actually work, or at best the "standalone" BSP code will always get in the way of truly integrating FreeRTOS with the MicroBlaze.
There are a number of caveats associated with packaging FreeRTOS as a true BSP. I won't go into all of them now (but will certainly help out if you decide to pursue this), however I'll mention two important ones: 1) to be compatible with the BSP library format, the FreeRTOS source tree has to be wrapped up in a couple more directory layers and 2) the concept of configuring FreeRTOS via #defines in the config file has to be hidden from the user and ultimately done automatically by the aforementioned TCL scripts. For #1, your concept with the CreateProjectDirectoryStructure.bat file could be re-purposed to do this re-packaging after the user has installed the source distribution.
The whole reason I looked into FreeRTOS on the MicroBlaze in the first place was that I was less than impressed with the EDK code supplied by Xilinx. I initially had a terrible time with the xilkernal/lwIP combination and since, I've had a hard time trusting the code supplied with the EDK. To be clear, I think the peripheral-specific drivers Xilinx supplies are generally OK, but the BSP and library code (xilkernal, lwIP integration, etc.) is lacking compared to the code supplied by other platform vendors. This is why I think having a true FreeRTOS BSP that you can use in place of the stuff supplied by Xilinx would be useful.
If you want to pursue this sort of packaging, let me know how I can help. I know it would definitely benefit our projects from a risk-reduction perspective to use an "officially-sanctioned" FreeRTOS distribution, even if I helped create said distribution. At this point, I have pretty much everything that you need for this, except for perhaps a documented and distributable emaclite driver for lwIP. I should have some time to work on this over the next month or so, especially as I am about to migrate from 12.2 to 13.1 of the ISE/EDK.
Regards,
Tyrel
Hi Tyrel,
The code you have seen is indeed a 'standard' FreeRTOS demo. That is, the FreeRTOS code is included in the project, built as part of the project, and statically linked. The BSP project, which is not mentioned on the page I gave a link to, does what you say. FreeRTOS is automatically generated as a library, and FreeRTOSConfig.h created automatically. I don't want to go into more details here until it is ready and released, but am happy to have an offline discussion until that time. You can get my contact email address here: http://www.freertos.org/RTOS-contact-and-support.html
Regards.