Hi Cyril, PRU is basically a micro-controller embedded inside of da8xx processors. To emulate any protocol on it, we need to implement the protocol and download the firmware into the instruction RAM. Hence, if the firmware is implemented in such a was that its able to run different protocols simultaneously, then it can. But, still its only a single execution unit. On the other hand, we have two functionally identical PRUs inside da850, hence resulting in two execution units.
We have implemented 4 different full duplex uarts utilizing both PRUs and also a single CAN controller utilizing both PRUs. But, its either UART or CAN, and not CAN and UART together, this decision being fixed init time. Again, as with any other micro controller, we can always stop the PRU and download another firmware to run another protocol/peripheral. Best Regards, Subhasish Ghosh On Tue, Jan 18, 2011 at 8:52 PM, Cyril Chemparathy <[email protected]> wrote: > On 01/18/2011 08:22 AM, Subhasish Ghosh wrote: > > > > Hi Cyril, > > > > I am referring the SSP driver to implement the PRU MFD driver. > > I had a few concerns regarding this. > > > > First of all, does the SSP support multiple execution units, in a sense > that > > its able to run multiple serial devices at once, like multiple channels. > > If so, then its definitely a MFD. > > Yes, the SSP IP has two execution units (aka ports/cells) which can be > programmed to run distinct protocols simultaneously. > > > But, on the other hand, the PRU is only a single execution unit i.e it > can > > execute only a single firmware/protocol at a time. > > > > Secondly, since even PRU is multi-driver or so to say "multi functional", > > will that be a reason good enough to categorize it as a MFD, even if > there > > is only one execution unit. > > Could you elaborate on the PRU usage scenario? Is the "function" fixed > at init time, or will your drivers allow functions to be accessed in an > interleaved fashion? > > In my opinion, if the function is fixed at init, MFD may be > inappropriate. Sam and Dave (copied) may have better inputs on this. > You can also dig up background discussions on the same topic from the ML > archives. > > Regards > - Cyril. >
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
