Jump to content

mod_skel - fix defines


Recommended Posts

I found this in the mod_skel.asm, but I can't figure out what's the use of it. I also can't find a similar thing in existing modules:

; ==========================================================================
; Fix defines
; ==========================================================================
;; grrrr! "#if defined(mod_skel_def) && mod_skel_def == 0" not supported by GPASM
;; therefore we create a helper #define
;; this 'copies' the define to the module
;; thanks to TK for figuring this out!
#ifdef mod_skel_def
#define _mod_skel_def mod_skel_def
#else
#define _mod_skel_def 1
#endif

Link to comment
Share on other sites

Gday mate. You can find another example in the BLM module.

The trick is that GPASM provides '#ifdef YOURDEFINE', and '#if YOURDEFINE == something', but no '#if defined YOURDEFINE'. So, if you want to have a conditional compile, where you test firstly to see if the define exists, and secondly to what value it is set, then you have to use TK's trick.

Link to comment
Share on other sites

hm... but why use the underscore? why not just write

#ifndef mod_skel_def
#define mod_skel_def 1
#endif
wouldn't this come out to the same, and avoid to use the _ ? in the mod_skel.inc excactly this is done then:
#ifndef _mod_skel_def	; if it's not already defined in the makefile (see readme.txt)
#define _mod_skel_def 1	; default to 1
#endif					; (see also mod_skel.asm for GPASM fix!)
I really don't see the point. If the define is not given by the makefile, just create it with a default value. Or did I miss something  ??? The 'define does not exists' would then just end in a certain value assigned to this define. The condition can then just check for this value to decide wheter to assemble or not? exactly what is done in the condition-example then:
#if _mod_skel_def==1	; note this is using the define from the fix in the asm file!
	incf _mod_skel_var, F, BANKED
#endif
so as a short summary, my vision of all this:
#ifndef mod_skel_def
#define mod_skel_def 1
#endif

#if mod_skel_def==1
//do this and taht
#endif

if you give the define in the makefile, the given value will rule, if not, the default will rule.. what I dont see?

Link to comment
Share on other sites

hm... but why use the underscore? why not just write

#ifndef mod_skel_def
#define mod_skel_def 1
#endif
wouldn't this come out to the same, and avoid to use the _ ?
Nah, that's not the same thing.... That code #defines the value, if it is not already defined; the 'trick' above is ifdef (if defined), not ifndef (if not defined)....
in the mod_skel.inc excactly this is done then:
#ifndef _mod_skel_def	; if it's not already defined in the makefile (see readme.txt)
#define _mod_skel_def 1	; default to 1
#endif					; (see also mod_skel.asm for GPASM fix!)

I really don't see the point.

Again, that's not the same thing you were originally discussing - That is there in order to set a default. If the user wants to override the default of '1' for this value, then they can set it in their app, or in the makefile using a -D switch in the compiler parameters variable. In the modules (and in apps too), it's good style to write the #defines wrapped in ifndefs like this, because it ensures that the value is always going to be defined - either to the default, if it has not been previously set, or to the user-specified value (via the makefile, or maybe the application)

For another example, check out the AOUT module's pin definitions. The default pins are set in the module, wrapped in #ifndef, which means that the default pins will be used - unless the same values are already #defined in your app.

If the define is not given by the makefile, just create it with a default value. Or did I miss something  ???

Nope, that's exactly it.

if you give the define in the makefile, the given value will rule, if not, the default will rule.. what I dont see?

I think the only thing you didn't see, is that this is different to the 'trick' we were discussing earlier :)

Link to comment
Share on other sites

I still dont get the point....

Why to 'copy' the define if it is defined? You will use only the copied _mod_skel_def anyway, so why not just use the 'original' ? And is the else-section not basically the same as 'ifndef' ?

#ifdef mod_skel_def
#define _mod_skel_def mod_skel_def
#else
#define _mod_skel_def 1
#endif
I don't want to argue, but please explain me the difference / advantage of the code above to this one:
#ifndef mod_skel_def
#define mod_skel_def 1
#endif

it does exactly the same: if the stuff is defined, let it be like it is, if not, define it with a default value. The only difference is, that your code copies the define to the _mod_skel_def, whatever it is for ? And in the .inc then, you check *again* for the existence of the define, and assign a default value if it's not there, exactly the same you do in the code above. So what about this ****ing _score thing?

I think the only thing you didn't see, is that this is different to the 'trick' we were discussing earlier

I still don't see the trick. Make me see it..

Link to comment
Share on other sites

I guess that you mean the "trick" in the blm module, which I used for BLM_NO_DEBOUNCING in blm.asm

It isn't really required, and as you can see in blm.inc, a common "#ifndef/#define" combination works as well. I was only so annoyed by this GPASM limitation, that I documented a possible workaround for the case I ever need it ;)

Best Regards, Thorsten.

Link to comment
Share on other sites

So I suggest to remove the 'trick' from the mod_skel, sorry stryd, but for my eyes it causes more confusion than any advantage for 'mod_skel newbies'. You will have to spend a lot of time to explain what it is like in my case  ;)

I would rather replace it with

#ifndef mod_skel_def

#define mod_skel_def 1

#endif

for example in my code, I need the define for a condition in the .asm as well as in the .inc, so I do the check in both, somebody can include just the .inc then and the define is guaranteed to be set (the same as in the blm module).

Link to comment
Share on other sites

Yes, it should be removed from the skeleton.

I remember again, why I didn't removed it by myself: the .asm file is a wrapper, which shouldn't touch the original definitions in .inc to ensure, that I'm able to use the module in assembly only applications with the same behaviour.

It was the only way to ensure, that the original default value defined in .inc still will be taken w/o overruling in .asm

It's like an advanced consistency check.

If somebody changes the default value directly in the .inc code (for whatever reason, normaly the source code shouldn't be touched), the compiler will fail due to the missing _blm_button_debounce_delay variable

So, he needs to search for the error, and will find out, that the same definition is used in .asm as well.

for example in my code, I need the define for a condition in the .asm as well as in the .inc, so I do the check in both, somebody can include just the .inc then and the define is guaranteed to be set (the same as in the blm module).

no, it isn't, since you cannot include the file before variables are declared

However, no need to discuss the sense and nonsense about this trick here. I found it useful for a particular issue, but if you don't see the need - don't use it!

Best Regards, Thorsten.

Link to comment
Share on other sites

I remember again, why I didn't removed it by myself: the .asm file is a wrapper, which shouldn't touch the original definitions in .inc to ensure, that I'm able to use the module in assembly only applications with the same behaviour.

It was the only way to ensure, that the original default value defined in .inc still will be taken w/o overruling in .asm

ok, this makes it a bit clearer to me.. anyway, I will remove the workaround from the mod_skelleton and remove the _score.

Link to comment
Share on other sites

I documented a possible workaround for the case I ever need it

....

However, no need to discuss the sense and nonsense about this trick here. I found it useful for a particular issue, but if you don't see the need - don't use it!

That's pretty much why it's in the skeleton.... of course, it's not required there, but it is placed there so that if someone needs that workaround, they won't have to go searching for it.

This, you said that having it there means having to explain it to newbies,.... well not really, in most cases I would have just said "you won't need it, don't use it'... I know you're the inquisitive type who would like to know what it is for, even though he won't use it (like me), so I explained ;)

Link to comment
Share on other sites

ok, I already removed it, if you feel bad about it, revert it  :)

I think most people won't use the workaround, so it's time saving to explain the workaround for those who need it, than to explain the stuff to those who dont need it. Because it was in the template, I thought it's something that is absolutely needed, maybe it would help to explicitely note that this is not a "must" for having defines that can be overloaded.

by the way, I fixed the c function templates (movwf -> movff) in the mod_skel

Link to comment
Share on other sites

ok, I already removed it, if you feel bad about it, revert it  :)

LOL nah it's not like that. I have no attachment to it :)

I think most people won't use the workaround, so it's time saving to explain the workaround for those who need it, than to explain the stuff to those who dont need it.

That's why I said I wouldn't normally explain it.

Because it was in the template, I thought it's something that is absolutely needed, maybe it would help to explicitely note that this is not a "must" for having defines that can be overloaded.

Ahhh right! Well the intention of that skeleton is actually the complete opposite of that. LOL. The idea is, that it has *everything* in it which is used in any of the other modules (that's why it 'inherited' this 'trick' from the BLM code) so that if someone needs to know "how do I do blah in a module?" then they can see how it's done in the skeleton, by searching for "mod_skel". They can remove anything else they don't need. This came about because when I had to write modules I found it a bit tedious to browse through all of the code in existing apps to see if/how something similar had been done, so I thought I'd throw it all in the skeleton.

Really, that's far from skeletal, so feel free to dice it up as you see fit. It's no big deal whatever you want to do with it, I needed a module skeleton for myself, so I souped it up a little and threw it on SVN - it's not my baby :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...