From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Best representation for spares Date: Sun, 16 Feb 2014 18:33:35 +0200 Organization: Tidorum Ltd Message-ID: References: <215f6df2-a7ec-42f4-ac82-656d5b12bf61@googlegroups.com> <8383f5d6-3f66-415b-ab3f-8801fa377a6b@googlegroups.com> <8200939f-9bbd-44dd-848c-00c663f37121@googlegroups.com> <1e41e2d6-7ff8-445d-9c14-14c49b244bcf@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: individual.net 7M7OfTjxmR1lCpzHJGpgXgPyhCBnBYK/a2NoBsFuLLocNo4JHg Cancel-Lock: sha1:0G62JwDyxnM4TBU4W7yPiQuACmU= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 In-Reply-To: Xref: news.eternal-september.org comp.lang.ada:18621 Date: 2014-02-16T18:33:35+02:00 List-Id: On 14-02-16 15:40 , Rego, P. wrote: > On Sunday, February 16, 2014 7:02:41 AM UTC-3, Niklas Holsti wrote: >> Here you are "overlaying" a record object on a specific storage >> location, presumably a memory-mapped I/O control register. This is OK, >> but it has consequences... > But is there a diffferent way to memory-map the registers? You can use System.Address_To_Access_Conversions to create a reference (pointer, access) to the memory address, and then use that pointer: package Conversions is new System.Address_To_Access_Conversions ( Object => Mem_Mapped_Reg_T); Ptr : Conversions.Object_Pointer := Conversions.To_Pointer (System'To_Address (16#.....#)); Reg : Mem_Mapped_Reg_T; Reg := Ptr.all; ... Ptr.all := Reg; >> If the Spare bits are documented as "reserved", there should >> not be any need to initialize just them... > > There are some points in datasheet which are a little confusing, > it says the spare is "reserved", but also says "write zero" in > some cases (not all). The bits are typically "reserved" because some later version of the HW may define some meaning for them, for example to activate some advanced HW functions that are not available now. Usually, in order to write anything to a MMIO register, the program has to write the *entire* register at once, using a word-sized memory-store instruction. Writing only one bit, or only some other part of the register, is not usually supported by the HW (except on some small microcontrollers with bit-addressed memory). This means that you cannot avoid writing the reserved bits too. The datasheet is saying that you should write zeroes to the reserved bits, and then nothing bad will happen even in the future -- no new surprising effects will happen even if the program is executed in some new version of the HW where the reserved bits have been given some new functions. It does not mean (usually) that you *must* initialize these bits to zero; it means that writing zero is safe, while writing something else may not be. > I did not get. Is is better to use > Auxiliary_Peripherals_Register_Map: > Auxiliary_Peripherals_Register_Map_Type > := (others => <>); > or just initialize in system initialization? I would initialize only in the system init, using an assignment statement. Using either an overlay, or a pointer from Address_To_Access_Conversions. The pointer method has the advantage that you can then default-initialize Spares, and it will work: Reg_Init : Memory_Mapped_Reg_T; ... Reg_Init.X := ...; Reg_Init.Y := ...; Ptr.all := Reg_Init; Reg_Init.Spares can be default initialized (e.g. to zero), and those zeroes will be written to Ptr.all. But I would probably write use an aggregate expression, and not a variable: Ptr.all := (X => ..., Y => ..., Spares => ...); and not bother with default initializations. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .