I seem to be missing something in the mechanics of how to get a IDriver built and linked into the CCS project system.
I am working on a UART for the arm side of an OMAP-L138 and was able to get the xs script to run and generate files. (Seems like an older version of xdctools didn't work but the newer version runs fine.)
But now I am at a loss as to how to get them linked into our system and get SYSBIOS to recognise it. I cant add it as a package.
Do I just make a CCS project and dump the files into it? What templete should I use?
Is there something I can run to turn it into a package and then add it as a package?
Thanks,
Update:
Thought I would try building the driver off of the directory path of the Package I built for our board. I use the package/internal subdirectory.
I seem to have gotten CCS to at least find the stuff but I get the following error.
Description Resource Path Location TypeC:\CCS\platform\bh\platform\arm\expOMAPL138\package\internal\uart\package.xdc found along the package path, but no schema file was found. Ensure that the package 'bh.platform.arm.expOMAPL138.package.internal.uart' is completely built. app.cfg /SYSBIOS_ARM_configuration 38 C/C++ Problem
So close.... sigh
Mike,
I didn’t find a detailed example to point you to. In searching I found your posts about IDriver from February. Were you not building in CCS then?
Scott
Scott,
I am actually working on the same driver as back then. I have been pulled off that work to go do other things and am back on it now.
Back in February I had my own project with the attempt to get the IDriver up and running. But couldn't figure out how to get the functions registered. At that time the xs script was failing for us. Now with a new version of xdctools it seems to work, at least doesnt report an error. I also noticed that it generates far more then just a "c" file but a bunch of other files too [xdc, xs, package.xdc, package.bld].
Now that I have that stuff how do I get it built. I get the error above if I just try to use it.
Also what do I have to modify? Can I just modify the C file or do I have to keep the s and xdc too?
I have found out since Februrary that I MUST use an IDriver as the IOM interface is not supported on the ARM on the OMAP-L138.
So I am in some desperate need to get these answers.
Thanks for your help.
OK, thanks for the background.
I’m not familiar with using IDriver and am going to have to search some more for an example to send to you, or someone that can better assist.
Mike,You’ve not been forgotten. I used the driver template generator and now have a list of instructions to send to you for how to build and use the driver in your CCS project. On Monday morning I need to get confirmation for a couple of the steps I used (to see if there are better alternatives), before sending this to you. Almost there…Scott
I learned this morning that the IDriver and Stream interfaces are being deprecated, and all customers are being instructed to use the GIO and IOM interfaces going forward. These interfaces are simpler, and don’t require special packaging and build steps (those that I was going to send to you this morning).
For your particular case, for a UART driver on the ARM-side of OMAP-L138, the recommendation is to look at the DSP-side UART driver in the PSP 3.0 release (downloadable here: http://software-dl.ti.com/dsps/dsps_public_sw/psp/BIOSPSP/index.html), and port this to the ARM side. You’ll need to use SYS/BIOS 6.33 or later. There will need to be some tweaks for interrupt parameters, for example, but in the end you’ll end up with a simpler C implementation that can be integrated directly into your ARM-side project.
I think this is what you were originally planning on doing in that earlier thread, but with the earlier PSP 1.03 release.
Sorry that I didn’t know about this when you started this new thread last week.
Thanks for the info. I was out yesterday and just getting back today. We are using 6.33.0439 of SYS/BIOS.
When I include the IomAdapter (from the IPC Input/Ouput) into our kernel we get an error:
"The ti.bios package contains support for the legacy BIOS 5.x APIs. These APIs are only supported for the c6x and c28x. The ti.catalog.arm devices are not supported. app.cfg /SYSBIOS_ARM_configuration Configuration Validation XDCTools Configuration Marker"
That was the reason for us abandoning the PSP driver port.
Now I just noticed that under the SSYS/BIOS options under I/O there is a DEV and GIO. The description of the DEV is just like the IOM Adapter but I dont seem to get an error with it. I will try this and see how it goes.
Thanks for the info. Give me till the end of the day and I should be able to tell you how it goes.
I got the newer IOM running on the UART. Lot more changes then I first thought. Shame they used the same name as the old IOM.
One last question, this newer IOM doesn't seem to to support the IConvert/Transformer stuff? Or is there a way to get that to work with the newer IOM?
I am getting characters in through the UART and now I need to build them into messages and then wanted to pass them on to the task.
Thanks again,
Mike
Glad to hear your driver is working now!
IConverter and Transformer are being deprecated along with Stream, and they cannot be used with an IOM driver.
It is technically possible to have one IOM driver use another (which might be a converter in your case), but there aren’t any examples of doing this that I can point you to. It is probably best not to go down that path, and stick to doing the transformations outside of the IOM driver.
Can do! Thanks for the help...