• AVR Freaks

Hot!Suggestions for a Good Folder Structure and Files Arrangement

Author
luizsalomon
Starting Member
  • Total Posts : 83
  • Reward points : 0
  • Joined: 2007/02/26 05:32:52
  • Location: 0
  • Status: offline
2016/06/20 05:08:10 (permalink)
0

Suggestions for a Good Folder Structure and Files Arrangement

Hello. 
My programming background is (was) assembly. Just love it.
It's good to go to the movies and watch "The Matrix" and be the only one to laugh when those green letters are falling, since you are the only that understands that thing.
Well, but I have to move on and use C and this is the reason of the post (512KB of program memory available on todays PIC is also another good reason).
 
I want to make the project that someone will look at it and say, 'Wow, this is nice. Makes me remember when I used to program in Cobol'.
 
The available books out there are for C, but not for a hardware based C. Keep reading and you'll understand what I mean.
 
Besides de main.c and main.h, how should I arrange the other hardware specific files? For example, the initialization? Should I create a init.c?
PPS? Should I create a PPS.c or should the PPS unlock+lock stuff be inside the init.c?
Timer? Timers?
Interrupts?? Should a interrupt c. be used?
I2C.c? SPI.c?
If think you have the idea of what kind of suggestion I am looking for ;)
 
Any suggestions will be great and humbly accepted.
 
Thanks in advance.
 
 
#1

8 Replies Related Threads

    DarioG
    Allmächtig.
    • Total Posts : 54081
    • Reward points : 0
    • Joined: 2006/02/25 08:58:22
    • Location: Oesterreich
    • Status: offline
    Re: Suggestions for a Good Folder Structure and Files Arrangement 2016/06/20 06:22:15 (permalink)
    +1 (1)
    luizsalomon
     
    Besides de main.c and main.h, how should I arrange the other hardware specific files? For example, the initialization? Should I create a init.c?

     
    yes or no, I usually don't - I just have an "init()" function
     

    PPS? Should I create a PPS.c or should the PPS unlock+lock stuff be inside the init.c?

     
    inside, IMO it's too little stuff to bother
     

    Timer? Timers?

     
    As needed, init, main...
     
    Interrupts?? Should a interrupt c. be used?

     
    yeah!
     

    I2C.c? SPI.c?

     
    It depends, if you have libraries (such as bit-banged code) then place it into separate files; otherwise, it's not needed...
     

    GENOVA :D :D ! GODO
    #2
    du00000001
    Just Some Member
    • Total Posts : 3175
    • Reward points : 0
    • Joined: 2016/05/03 13:52:42
    • Location: Germany
    • Status: offline
    Re: Suggestions for a Good Folder Structure and Files Arrangement 2016/06/20 08:12:05 (permalink)
    +2 (2)
    Depends. For me, a file structure reflecting the project setup always worked well.
    But you are free to 'invent' another scheme. Best if it fits you (and your co-workers
    - if you have such).
     
    If you do not have excessive initialization, why not put all into "hardware.c" or "init.c".
    Could be one function, could be one function for each device. It is not that important.
     
    Whether you want to have all ISRs in a single file or have all ADC code (eg. init + ISR)
    in a single file - that's philosophy, not necessity.
     
    Regards
    #3
    DarioG
    Allmächtig.
    • Total Posts : 54081
    • Reward points : 0
    • Joined: 2006/02/25 08:58:22
    • Location: Oesterreich
    • Status: offline
    Re: Suggestions for a Good Folder Structure and Files Arrangement 2016/06/20 09:09:04 (permalink)
    +2 (2)
    It's *all* philosophy, as long it compiles Smile

    GENOVA :D :D ! GODO
    #4
    NorthGuy
    Super Member
    • Total Posts : 5754
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: offline
    Re: Suggestions for a Good Folder Structure and Files Arrangement 2016/06/20 10:23:11 (permalink)
    +3 (3)
    My rule of thumb: if you think that the part of the code has a chance to be re-used with other projects, move it to its own file. Such re-usable file must include everything that you're going to need when you move it to the next project.
     
    Otherwise, creating a maze of small files doesn't look like a good idea to me.
     
    #5
    DarioG
    Allmächtig.
    • Total Posts : 54081
    • Reward points : 0
    • Joined: 2006/02/25 08:58:22
    • Location: Oesterreich
    • Status: offline
    Re: Suggestions for a Good Folder Structure and Files Arrangement 2016/06/20 11:11:06 (permalink)
    +1 (1)
    NorthGuy
     
    Otherwise, creating a maze of small files doesn't look like a good idea to me.
     




    Yep, I usually agree

    GENOVA :D :D ! GODO
    #6
    luizsalomon
    Starting Member
    • Total Posts : 83
    • Reward points : 0
    • Joined: 2007/02/26 05:32:52
    • Location: 0
    • Status: offline
    Re: Suggestions for a Good Folder Structure and Files Arrangement 2016/06/21 13:25:01 (permalink)
    +1 (1)
    Thanks guys!!
     
    DarioG
    It's *all* philosophy, as long it compiles Smile

    Still laughing here, Dario. Smile Smile Smile
     
    NorthGuy
    Otherwise, creating a maze of small files doesn't look like a good idea to me.

    Maze... good, excellent point! Smile
    #7
    DarioG
    Allmächtig.
    • Total Posts : 54081
    • Reward points : 0
    • Joined: 2006/02/25 08:58:22
    • Location: Oesterreich
    • Status: offline
    Re: Suggestions for a Good Folder Structure and Files Arrangement 2016/06/22 01:18:45 (permalink)
    0
    grin
    "as long AS it compiles" (stupid forum won't allow edit...)

    GENOVA :D :D ! GODO
    #8
    cobusve
    Super Member
    • Total Posts : 495
    • Reward points : 0
    • Joined: 2012/04/02 16:15:40
    • Location: Chandler
    • Status: offline
    Re: Suggestions for a Good Folder Structure and Files Arrangement 2019/10/21 17:47:00 (permalink)

    Also take a look at https://www.microforum.cc/ - a great resource for information on PIC and AVR microcontrollers and embedded programming in general. You can also post questions to the experts there.
    #9
    Jump to:
    © 2019 APG vNext Commercial Version 4.5