 |
 |
| View previous topic :: View next topic |
| Author |
Message |
biozen
Joined: 08 Sep 2010
Posts: 10
|
| 'Nested' Typdefs |
 Posted: Tue Apr 03, 2012 2:06 am |
 |
|
Hello,
I'm writing code for an industrial testing instrument that cycles temperature.
Its works something like this:
Each program has up to 9 segments. Each segment can have up to 9 steps. Each step is basically a set temperature that is held for some fixed seconds.
So for example, a segment can 2 steps of 10C (for 15 sec) and 90C (for 20 sec). This segment can be repeated, say, 5 times. So the heating chamber inside the instrument maintains 10C for 15 sec and then heats up to 90C, maintains it there for 20 sec, then goes back to 10C for 15 sec, 90C for 20 sec... cycling so for a total of 5 times.
This segment could be followed by another segment that may have 3 steps of 20C (10 sec), 80C (10 sec), 50C (20sec) repeated 10 times.
I've defined the variables in the following code. Please have a look and let me know if it looks alright. Right now its for a PIC18F4680, but could change later depending on the RAM requirements.
This is the relevant part of the program:
| Code: | // SimpleDefine.c
//-----------------------------------------------------------------------------
// Define a step of the segment of the program
typedef struct
{
// Each step in a segment of the controller's program has a
// set temperature TempSet *C and this should be maintained
// for TimeSec seconds.
unsigned int16 TempSet;
unsigned int8 TimeSec;
} Program_Step;
//-----------------------------------------------------------------------------
// Define a segment of the program
typedef struct
{
// There can upto 9 steps in each segment, as defined in NoOfSteps.
// The steps can be repeated NoOfCycles times.
// Each of the step is the type defined in the typedef above.
// Although the user may require less than 9 steps, but we
// reserve RAM for 9; to make it easier to setup storage in external EEPROM.
unsigned int8 NoOfCycles;
unsigned int8 NoOfSteps;
Program_Step ProgramStep[9];
} Program_Segment;
//-----------------------------------------------------------------------------
// Define the program
typedef struct
{
// There can upto 9 segments in each program, as defined in NoOfSegments.
// Each of the segment is the type defined in the typedef above.
// There are other parameters needed, that like HeatLid which are similar to the
// type defined by Prog_TimeTemp.
// Again, though the user may require less than 9 segments, but we
// reserve RAM for 9; to make it easier to setup storage in external EEPROM.
unsigned int8 PreHeat;
unsigned int8 NoOfSegments;
Program_Segment ProgramSegment[9];
Program_Step PreHeatSpecs;
} Program_Complete;
//-----------------------------------------------------------------------------
Program_Complete FirstProgram; // Create a program for trials.
//-----------------------------------------------------------------------------*/
|
And since I'm not great with C (for PICs or even otherwise), how does one access the temperature of step number 2 in segment 3 of the program. Will it be?...
| Code: | | FirstProgram.ProgramSegment[3].ProgramStep[2].TempSet |
Thanks,
MM. |
|
 |
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Tue Apr 03, 2012 2:41 am |
|
|
Yes. That's how it works in C.
BUT some versions of CCS C have had, and may still have problems - bugs - in correctly implmenting complex structures such as this. I have personally had trouble with arrays of typedefed structures. There are also memory segmentation issues which limit the size of structures. So its wise to test very carefully that this really works as you expect.
I'm currently investigating a problem with code that access a complex structure that worked OK on 4.107 but doesn't seem to work on 4.130. I don't know that its related to structures, or typedefs yet, but experience suggests it may be as there WAS just such an issue with 4.107. that was to do with typedefed arrays of structures, not arrays of typedefed structures.
RF Developer. |
|
|
biozen
Joined: 08 Sep 2010
Posts: 10
|
|
| Posted: Tue Apr 03, 2012 3:38 am |
|
|
Thanks for your reply.
So if there's a possibility of a bug, and since I'm not a C guru, I won't be able to pin-point if any errors are due to compiler bug or code bugs.
What would other alternatives be to 'typedefed arrays of structures' and 'arrays of typedefed structures'? I don't know which one is mine, thought I suspect its the latter.
Thanks,
MM. |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Tue Apr 03, 2012 6:44 am |
|
|
| biozen wrote: |
So if there's a possibility of a bug, and since I'm not a C guru, I won't be able to pin-point if any errors are due to compiler bug or code bugs.
What would other alternatives be to 'typedefed arrays of structures' and 'arrays of typedefed structures'? I don't know which one is mine, thought I suspect its the latter.
|
Yes, you are using 'arrays of typedefed structures'.
In all code there is always a chance of bugs, both from your code and from compiler or even hardware issues. You don't have to be a "guru" to find them, though if you can get this working well people might start calling you one!  You just need to be aware and on the look out for any "odd" behaviour. Single step debugging on real hardware is about the best way of checking this sotrt of code out: making sure what you think is stored in your data structure is correct. Even relying on printfs to tell you what's there is inconclusive as if there is a problem you can't easily tell wether its your code, the writing, the reading or even the printf (and it often is!) that's causing the problem. Being able to set break points right after you data is written and checking the contents of memory are about the only reliable way of testing, and even then there are issue with debuggers correctly accessing arrays and structures. The CCS one seems to like interpreting everything as unsigned int8s for example.
This structures of arrays of structures of arrays of structures thing is quite sensible in general. Its rather the object orientated way of doing it. On most processors it should work well. PICs are limited and have addressing quirks which makes the compilers job harder than it is on other processors. Don't expect this to work with your data declared const for example!
What else could you do? One alternative would be to think of it as a database and declare the arrays seperately and store indexes into them in the Program_Complete structure. It avoids most of the complexity.
RF Developer |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
