CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

EX_RS485.c CCS C [Solved]
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Jun 17, 2020 1:26 pm     Reply with quote

nice...

another 'trick' I've learned over the years...
when editing a program ..
1st. copy it,naming new one 'programnameVxxx.C'
where x is the version number
2nd edit the new copy
3rd compile/run/see what happens.....
4th, keep doing 1-2-3 until it really works !

By doing this you'll ALWAYS have a few previous versions to go back to a KNOWN program.

It's way to easy to make 3,4 or more 'minor' changes to a program and then NOTHING works properly and you can't SEE where the problem is.
Yes, this system takes up a lot of harddrive space but HDs are cheap and HUGE,so really space is not an issue.
When the project is done, you can always go and delete all but say the last 3 versions.

I also have a 'fuses file' that has EVERY fuse, 1 per line, with comment. I use #include '46k22fuses.c' to insert it into the program. Doing this keeps the program 'cleaner' and easier to read. If a program needs different fuse settings from the basic, simply copy the base version, name after the project, and include that version. Generally though , if you stick to one PIC, the fuses don't really change....
diode_blade



Joined: 18 Aug 2014
Posts: 52
Location: Sheffield, South Yorkshire

View user's profile Send private message Send e-mail

Solved
PostPosted: Thu Jun 18, 2020 3:26 am     Reply with quote

Quote:

I also have a 'fuses file' that has EVERY fuse, 1 per line, with comment. I use #include '46k22fuses.c' to insert it into the program. Doing this keeps the program 'cleaner' and easier to read. If a program needs different fuse settings from the basic, simply copy the base version, name after the project, and include that version. Generally though , if you stick to one PIC, the fuses don't really change....


I do the version thing temtronic but the fuses file great tip thanks for that.
Thanks Folks.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Jun 18, 2020 3:57 am     Reply with quote

That 'style' helps a lot, especially when running multiple versions.
I tend to do a 'config' file, that contains the fuses, clock settings, PPS, &
the UART/I2C/SPI setups. I usually include in this a 'description', which
says which pins do what. So a typical one would be:
Code:

//Peripherals I2C C5/C4 SCL/SDA
//Feeds 24FC512, DS1338-C, * MCP23008
//relays on top two bits of this, then six solenoid drivers.
//PWM on B4/C0 for 4-20mA
//Opto coupled logic inputs B10, B12, B14 ,A10
//Analog in B0, A1, VREF B1
//CO2 C7 TX, C8 RX
//Vinculum C1 TXD, C2 RXD
//Display RX B5, TX B6
//Square wave interrupt from clock = input on RA8
//Servo controller now separate board
//Using A7(TX) & B11 for it's serial interface.
//B15 control switch (pullup). 
//A0, A4, A9, B8, B9, C3, C6 unused.

That way I can check at any point 'what pin does what', and all the stuff
that configures the chip is in one place.
I then usually have a file containing the #DEFINES, and data type
configurations (structures etc.).

'Standardising' on how you store this stuff, makes it vastly easier to
go back to a project in months or years time. As an example, I just did
an update on some code I first wrote about 14 years ago, currently on
version 39!. Yet I was able to write the changes needed in only a few
minutes, and send them back for test. Most versions of this are just
small modifications for specific customers, but if you didn't have an
'archive' of versions, and a standard format. catch back up with this
would be much harder....[/code]
diode_blade



Joined: 18 Aug 2014
Posts: 52
Location: Sheffield, South Yorkshire

View user's profile Send private message Send e-mail

PostPosted: Thu Jul 23, 2020 9:42 am     Reply with quote

SOLVED: 23-7-20
Thank you guys for the help, after a few other teething troubles including some HW, laptop and SW problems, I have now got things working the way I want and can expand on from there.
Again thank you very much for the help.
Dave
Cenatronics



Joined: 27 Nov 2006
Posts: 13

View user's profile Send private message

PostPosted: Tue Jul 28, 2020 9:24 am     Reply with quote

Ttelmah wrote:
That 'style' helps a lot, especially when running multiple versions.
I tend to do a 'config' file, that contains the fuses, clock settings, PPS, &
the UART/I2C/SPI setups. I usually include in this a 'description', which
says which pins do what. So a typical one would be:
Code:

//Peripherals I2C C5/C4 SCL/SDA
//Feeds 24FC512, DS1338-C, * MCP23008
//relays on top two bits of this, then six solenoid drivers.
//PWM on B4/C0 for 4-20mA
//Opto coupled logic inputs B10, B12, B14 ,A10
//Analog in B0, A1, VREF B1
//CO2 C7 TX, C8 RX
//Vinculum C1 TXD, C2 RXD
//Display RX B5, TX B6
//Square wave interrupt from clock = input on RA8
//Servo controller now separate board
//Using A7(TX) & B11 for it's serial interface.
//B15 control switch (pullup). 
//A0, A4, A9, B8, B9, C3, C6 unused.

That way I can check at any point 'what pin does what', and all the stuff
that configures the chip is in one place.
I then usually have a file containing the #DEFINES, and data type
configurations (structures etc.).

'Standardising' on how you store this stuff, makes it vastly easier to
go back to a project in months or years time. As an example, I just did
an update on some code I first wrote about 14 years ago, currently on
version 39!. Yet I was able to write the changes needed in only a few
minutes, and send them back for test. Most versions of this are just
small modifications for specific customers, but if you didn't have an
'archive' of versions, and a standard format. catch back up with this
would be much harder....[/code]



Wouldn't it be a good education for beginners if you could make these tips and file structures into a template and publish them?
Very Happy Very Happy

Namik
dluu13



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Tue Jul 28, 2020 11:17 am     Reply with quote

Good candidate for the "best of" forum?
Cenatronics



Joined: 27 Nov 2006
Posts: 13

View user's profile Send private message

PostPosted: Tue Jul 28, 2020 3:17 pm     Reply with quote

dluu13 wrote:
Good candidate for the "best of" forum?


Absolutely!
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Jul 29, 2020 1:04 am     Reply with quote

Hmm. Perhaps privately, some of the posters would like to send me some
suggested 'layouts', then I can have a little 'assemble, and build something.

Very Happy
diode_blade



Joined: 18 Aug 2014
Posts: 52
Location: Sheffield, South Yorkshire

View user's profile Send private message Send e-mail

PostPosted: Wed Jul 29, 2020 2:20 am     Reply with quote

Cenatronics wrote:
Ttelmah wrote:
That 'style' helps a lot, especially when running multiple versions.
I tend to do a 'config' file, that contains the fuses, clock settings, PPS, &
the UART/I2C/SPI setups. I usually include in this a 'description', which
says which pins do what. So a typical one would be:
Code:

//Peripherals I2C C5/C4 SCL/SDA
//Feeds 24FC512, DS1338-C, * MCP23008
//relays on top two bits of this, then six solenoid drivers.
//PWM on B4/C0 for 4-20mA
//Opto coupled logic inputs B10, B12, B14 ,A10
//Analog in B0, A1, VREF B1
//CO2 C7 TX, C8 RX
//Vinculum C1 TXD, C2 RXD
//Display RX B5, TX B6
//Square wave interrupt from clock = input on RA8
//Servo controller now separate board
//Using A7(TX) & B11 for it's serial interface.
//B15 control switch (pullup). 
//A0, A4, A9, B8, B9, C3, C6 unused.

That way I can check at any point 'what pin does what', and all the stuff
that configures the chip is in one place.
I then usually have a file containing the #DEFINES, and data type
configurations (structures etc.).

'Standardising' on how you store this stuff, makes it vastly easier to
go back to a project in months or years time. As an example, I just did
an update on some code I first wrote about 14 years ago, currently on
version 39!. Yet I was able to write the changes needed in only a few
minutes, and send them back for test. Most versions of this are just
small modifications for specific customers, but if you didn't have an
'archive' of versions, and a standard format. catch back up with this
would be much harder....[/code]



Wouldn't it be a good education for beginners if you could make these tips and file structures into a template and publish them?
Very Happy Very Happy

Namik


Excellent Idea. Again thanks for the help.
Dave
Cenatronics



Joined: 27 Nov 2006
Posts: 13

View user's profile Send private message

PostPosted: Wed Jul 29, 2020 5:56 pm     Reply with quote

I am using Altium for my designs. While planning the folder structure for the customer projects I developed, I found the folder structure designed and published by Robert FERANEC for his own use. It has a very useful and organized structure. This is the address https://welldoneblog.fedevel.com/2013/10/14/hardware-design-directory-template/
This video also explains in detail: https://www.youtube.com/watch?v=q-4F9zoZ7fs

Not for Embedded Software, but hopefully it will help your business.


Namik
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group