MMIO classes

[Aditya Kousik]

Hello Martin,

Truth be told, I didn't want to probe the use of an object myself. But, if
I want to create an array of registers that can be iteratively called, it
saves a lot of effort as opposed to manually writing register by register.
Since write <..> involves explicit 'register_name' here. I'm not sure (or I
may not know how) if I can create an array of Mmio::Register's since
declaration to Register necessitates an offset and access width.

Normally, my initial attempt was to create an array of addresses that
pointed to the starting address of the registers. This gives us random
access and ability to put R/W accesses in a loop. But it is very primitive
and does not use the access_t concept.

But then, as you've said I looked into Register_array a bit deeper. Here is
an approach I've thought of.
Define all registers with offset values. Then, define a Register_array, say
R_array that has an offset to the first defined register, number of items =
number of registers. This works given the registers in between are all of
the same size (obviously). If there are N registers defined, then
write<R_array>(value, idx) should write to the ith register defined, right?
Not necessarily.

Consider this.

class Foo : Mmio
{
    struct reg1 : Register<0x0, 32> { };
    struct reg2:  Register<0x4, 32> { };
    struct reg3:  Register<0x10, 32> { };
    struct reg4:  Register<0x4c, 32> { };
    struct reg_array : Register_array<0x0, 32,32,4> { };

   public:
    void write_to_regs()
    {
       write<reg1>(0);
       write<reg4>(0xff);
    }
};

Will I achieve random access to the registers with the use of the register
array?  No. Unless, I am fundamentally wrong her, in which case, I'd be
glad to know where I'm going wrong.

Thanks and regards
Aditya.



On Tue, Apr 8, 2014 at 4:23 PM, Martin Stein
<martin.stein at ...1...>wrote:

>  Hi Aditya,
>
> Nice to hear that you like the MMIO framework :-) Personally, I can't see
> a benefit in constructing an object of a class that does nothing else than
> inheriting from an Mmio::Register. When trying to compile your example, my
> compiler complains that I can't use 'ob' in the constant expression
> 'write<...>', which sounds reasonable to me. Why do you think that
> 'Register_array' isn't what you're looking for? It may be helpful if you
> could explain your use case more precisely.
>
> Cheers,
> Martin
>
>
> On 08.04.2014 11:29, Aditya Kousik wrote:
>
>     Hello,
>
>  This doubt is more C++ than Genode. The MMIO framework is brilliant for
> R/W access. The way it goes is that, I create structures and successively
> inherit Register and Bitfield structures. But would it be wrong if I create
> an object of the structures and call 'write' and 'read' methods?
>
>  Say, struct Register_New : Register<0x4a, 32> { };
>
>  and struct Register_New ob;
>        write<ob>(0x5);
>
>  The above is just an example. What is normally done is
> write<Register_New>(0x5).
>  The template in the Mmio class if of Register::Register_base type. But an
> object to this struct is also Register. So, is there any negative aspect to
> this?
>
>  What I am currently trying out is trying to hold an array of Registers
> that has such objects for some level of automation. And I don't think
> Register_array is what I'd look for.
>
> Thanks for your patient replies
>  Aditya
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.http://p.sf.net/sfu/13600_Cloudbees
>
>
>
> _______________________________________________
> Genode-main mailing listGenode-main at ...220...://lists.sourceforge.net/lists/listinfo/genode-main
>
>
>
>
> ------------------------------------------------------------------------------
> Put Bad Developers to Shame
> Dominate Development with Jenkins Continuous Integration
> Continuously Automate Build, Test & Deployment
> Start a new project now. Try Jenkins in the cloud.
> http://p.sf.net/sfu/13600_Cloudbees
> _______________________________________________
> Genode-main mailing list
> Genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20140408/79798f0b/attachment.html>