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

[Jarielle Catbagan]

Ed,

Once the coding conventions have been officially established, if you
need help formatting the code I would be more than happy to help.

On Thu, Jun 18, 2015 at 9:47 AM, Jarielle Catbagan
<jcatbagan93 at gmail.com> wrote:
> 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