2011-08-30 01:07:39     Using icc lib to share ressources from core A to core B on bf561

Document created by Aaronwu Employee on Aug 27, 2013Last modified by Aaronwu Employee on Aug 27, 2013
Version 2Show Document
  • View in full screen mode

2011-08-30 01:07:39     Using icc lib to share ressources from core A to core B on bf561

william pagnon (AUSTRALIA)

Message: 103181   

 

Hi Guys,

 

 

 

I'm making an application type Core A uclinux and Core B DSP with bare metal and FreeRTOS.

 

 

 

I'm trying to use icc library to request ressources (like AD1836 codec from the EZkit board). I do not find any example on the net and the blackfin documentation is out of date : icc protocol do not use the same variables as describe in

 

  docs.blackfin.uclinux.org/doku.php?id=protocols:icc&s[]=icc

 

Unfortunatly I just have that link and few examples more about packet sending and scalar to make my code. I do have test the examples and they work fine but they are not focused on I/O ressources sharing like SPI SPORT etc ...

 

Thus I have to learn it the hard way and spend a lot of time figuring out how to put together this system.

 

 

 

Is there any of you who could help me with some code examples from the uclinux application side as well as the bare metal side?

 

This library is really usefull, and it will be great to see some tutorials around it for all its different use.

 

 

 

Best Regards,

 

 

 

William

QuoteReplyEditDelete

 

 

2011-08-30 01:57:13     Re: Using icc lib to share ressources from core A to core B on bf561

steven miao (CHINA)

Message: 103184   

 

Hi Willian,

 

the resource management implementation in icc has not finished yet. currently you have to assign the resource staticlly at the compiling time. We also plan to implement libmcapi for user space application or bare metal application to communication.

 

There is a bare metal stub program for test icc under uclinux-dist/user/blkfin-apps/icc_utils, you can reference the icc test doc on wiki:

 

https://docs.blackfin.uclinux.org/doku.php?id=test_icc_on_bf561

 

-steven

QuoteReplyEditDelete

 

 

2011-08-30 03:20:41     Re: Using icc lib to share ressources from core A to core B on bf561

william pagnon (AUSTRALIA)

Message: 103197   

 

Hi Steven,

 

 

 

 

Thank you for your quick reply. And thank you for creating this library  (obviously you are the developer of it) which is from my point of view an essential tool for the bf561.  

 

 

 

 

The fact that it is not finish will explain why I have trouble compiling the mcapi examples. So I just stick with icc and make my own simple wrapper for the moment.

 

I'm using indeed the references you gave me to guide me in the development of an application mainly (packet_test, task1) but the interaction for resources seem different and is not explained in those examples.

 

I'm starting with the GPIO LED first to validate the principle of resource sharing, I will then add the push button to check the data streaming in both ways, then my ultimate goal is to stream microphone data via the ad1836 codec to the core B where I will do Audio DSP treatment and output them back to the ad1836 codec toward the speaker.

 

In the old wiki document on the protocol, you speak in the example at the end of include files #include "dsp_bridge.h" (in linux app), #include "dsp_sys.h" (in bare metal app)

 

is this just an example of structure where you will put all the icc warping and dsp function in? Are they actual files I can find somewhere so I can use them as guidance?

 

You speak as well of "blackfin DSP framework" where can I find this framework?

 

could you give me an example of code on both side (Core A uclinux, CoreB baremetal) using the resource sharing system for the GPIO (to keep it simple), this will make it clearer for me and I should then be able to manage the SPI connection.

 

My aim is to have the core B (DSP) directly connected to the ad1836 codec so the data streaming do not take on the processing of Core A that will be used as user interface using TFT and touch screen.

 

Do I understand well that icc allow this by making a bridge to this resource memory allocation that will be then directly accessible and controlled by core B without any processing consumption of core A (once core A do the icc bridge of its resources to core B)?

 

 

 

best regards,

 

 

 

William

 

QuoteReplyEditDelete

 

 

2011-08-30 05:03:04     Re: Using icc lib to share ressources from core A to core B on bf561

steven miao (CHINA)

Message: 103200   

 

Hi Willian,

 

dsp_bridge is obsolete, current developing framework called icc. sorry for not cleanup the wiki and confusing you. the resource management is not ready not, so there is not example can run just a design document on wiki, if you have any comments or requests about the resource management protocol, pls let us know.

 

your aim about connect the ad1836 codec to coreb to offload core A is a good idea, you can try to implement it without resource sharing system at first, just assign thi gpio pins and reserver the memory staticlly, and make sure these resource will not be used by core A anymore to avoid conflicts.  you can use icc packet protocol to tranfer buffers and scalar protocol to transfer commands between core A and core B.

 

-steven

QuoteReplyEditDelete

 

 

2011-09-01 02:16:36     Re: Using icc lib to share ressources from core A to core B on bf561

william pagnon (AUSTRALIA)

Message: 103206   

 

Hi Steven,

 

ok thanks for the precision about the wiki doc. Couldn't reply earlier due to the blackfin uclinux server unavailable but I managed to develop the resource access the way you suggested excepted that I didn't allocate statically the memory is I'm not sure which memory and the best way to do so.

 

 

 

 

Could you give me an example of "reserver the memory staticlly" applied to resource sharing so I can understand it and apply it properly. Should I use malloc function for that?

 

 

 

 

For the moment it works fine without, I can control the LED from the ezkit board using Core B and trigger interrupt to core B when pressing a button. I'm now going to addapt the VisualDSP SPI, SPORT and AD1836 drivers to bare metal and try to make it work.

 

I'm adding the code I used to test the LED and push button resource code to this message so if someone struggle this will help as a starting point for bare metal I/O control and Interupt management. It is inspired from the example LED code

 

https://docs.blackfin.uclinux.org/doku.php?id=toolchain:bare_metal:hardware

 

which do not work and has mistakes by the way (at least for the BF561 processor)

 

That I have mix in the icc_task_init() function from the icc library example task1. I removed the packet transfer to avoid being in the icc_wait() function while testing but I confirm that it can be added back and that the packet transfer using icc lib between the two cores works fine.

 

for the comments or requests about the resource management I have a lot to say as from my point of view the total icc library should be an hight priority development to allow the use of the BF561 as the all purpose using dual core with linux is either spread the load on both processor or use one processor under linux and one compiled with bare metal. Thus the need of an OSI protocol such as icc is essential to make the bf561 useful otherwise, why bother with a dual core.

 

For the resource management itself, it will be great if all the ezkit 561 board CODEC and other peripheries are supported to simplify sharing of resources between processor. maybe in icc directly or in the mcapi. Thus it gives a full development platform as well as example to develop similar "connector" to control complex resources in your final custom board.

 

Thanks for the follow up.

 

Best Regards,

 

 

 

 

William

 

 

gpio_led_example.c

QuoteReplyEditDelete

 

 

2011-09-01 04:40:59     Re: Using icc lib to share ressources from core A to core B on bf561

steven miao (CHINA)

Message: 103250   

 

Hi William,

 

Thanks for your suggestions. We will continue to improve the inter-core communication tools.

 

You can use boot args to separate the core A linux and core B bare metal address space by:

 

set ramargs set bootargs root=/dev/mtdblock0 rw clkin_hz=30000000 earlyprintk=serial,uart0,57600 console=ttyBF0,57600 mem=60M max_mem=64M

 

then linux will not use last 4M and leave it to core B bare metal.

 

In your bare metal test case, it seems you just use the coreb_msg() as a debug tool now

 

-steven

Attachments

Outcomes