[PATCH 4/16] Renamed BBB platform file to am335x.h, initial version of am335x.h

[Jarielle Catbagan]

Yes, coding conventions will definitely help me and future Umon
developers by improving readability and will provide us an idea on how
to create consistent code.

Right now, I am just looking at the format of the code around the Umon
source tree and then trying to format the code that I implement to
match it.



On Thu, Jun 18, 2015 at 7:15 AM, Ed Sutter <ed.sutter at alcatel-lucent.com> wrote:
> On 6/18/2015 10:14 AM, Gedare Bloom wrote:
>>
>> On Thu, Jun 18, 2015 at 9:49 AM, Ed Sutter <ed.sutter at alcatel-lucent.com>
>> wrote:
>>>
>>> On 6/18/2015 9:36 AM, Gedare Bloom wrote:
>>>>
>>>> On Wed, Jun 17, 2015 at 1:52 PM, Jarielle Catbagan
>>>> <jcatbagan93 at gmail.com> wrote:
>>>>>
>>>>> Renamed beagleboneblack.h -> am335x.h
>>>>>
>>>>> Initial version of am335x.h includes a subset of the regsiter base
>>>>> addresses and offsets specific to the AM335x architecture.
>>>>>
>>>>> ---
>>>>>    main/common/warmstart.h                 |   2 +-
>>>>>    main/make/common.make                   |   0
>>>>>    ports/beagleboneblack/am335x.h          | 788
>>>>> ++++++++++++++++++++++++++++++++
>>>>>    ports/beagleboneblack/beagleboneblack.h | 498 --------------------
>>>>>    4 files changed, 789 insertions(+), 499 deletions(-)
>>>>>    mode change 100755 => 100644 main/make/common.make
>>>>>    create mode 100644 ports/beagleboneblack/am335x.h
>>>>>    delete mode 100644 ports/beagleboneblack/beagleboneblack.h
>>>>>
>>>>> diff --git a/main/common/warmstart.h b/main/common/warmstart.h
>>>>> index 50300eb..a3037ad 100644
>>>>> --- a/main/common/warmstart.h
>>>>> +++ b/main/common/warmstart.h
>>>>> @@ -31,4 +31,4 @@
>>>>>    #define APPLICATION (5<<4)
>>>>>    #define APP_EXIT (9<<4)
>>>>>
>>>>> -#endif
>>>>> +#endif /* _WARMSTART_H_ */
>>>>> diff --git a/main/make/common.make b/main/make/common.make
>>>>> old mode 100755
>>>>> new mode 100644
>>>>> diff --git a/ports/beagleboneblack/am335x.h
>>>>> b/ports/beagleboneblack/am335x.h
>>>>> new file mode 100644
>>>>> index 0000000..ed96dfe
>>>>> --- /dev/null
>>>>> +++ b/ports/beagleboneblack/am335x.h
>>>>> @@ -0,0 +1,788 @@
>>>>>
>>>>>
>>>>> +//==========================================================================
>>>>> +//
>>>>> +// am335x.h
>>>>> +//
>>>>> +// Author(s):    Luis Torrico, Cogent Computer Systems, Inc.
>>>>> +// Contributors: Jarielle Catbagan
>>>>> +// Date:         05/02/2008
>>>>
>>>> You should probably list yourself as the author, and I'd get rid of
>>>> these Date entries, the git log contains sufficient information.
>>>>
>>>> Is there a documented umon coding style?
>>>>
>>>> Would it be of interest to generate doxygen for umon (headers)?
>>>>
>>>> Gedare
>>>
>>> No there isn't.  :-(
>>> I generally just use 4-space tabs and comment with...
>>> /*
>>>    * comment here
>>>    */
>>> but I know I'm not real consistent through the code.
>>> At various points I started attempting a doxygen format, but never got it
>>> rolling.  I'm certainly up for converting it though (over time of
>>> course).
>>
>> No time to start like the present. I'd suggest defining the style with
>> something close to what you have got, that you want a consistent
>> look-and-feel, and if you find particular rules are desired as you
>> move forward that you add to them. A simple text document in the repo
>> will be sufficient to document the style rules for now, since they're
>> pretty simple.
>>
>> RTEMS has a fairly comprehensive set of coding conventions that have
>> grown over years that includes style and doxygen use.
>> https://devel.rtems.org/wiki/Developer/Coding/Conventions
>>
>> You don't need so much now, but it really helps to make code review
>> easier if all the code looks the same.
>>
>>
> Ok, I'm up to my neck today, so I'll look at this tonight.
> Tx
>
>
> --
> Ed Sutter
> Alcatel-Lucent Technologies -- Bell Laboratories
> Phone: 908-582-2351
> Email: ed.sutter at alcatel-lucent.com
>
> _______________________________________________
> umon-devel mailing list
> umon-devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/umon-devel