Bug : Picaxe-18x

hippy

Technical Support
Staff member
Doesn't honour "#gosubs 16" directive plus always generates code as if "#gosubs 256" had been specified regardless of how many GOSUB's are actually used.

Cannot download into 18X versions 8.0 or 8.1 - "Incorrect hardware connected".

Ideally should count GOSUB's used then generate appropriate code and set minimum version required as necessary without requiring a "#gosubs" directive.

Runs okay on Windows 98SE.
 

evanh

Senior Member
When did directives get implemented? It seems like they are still being sorted out. I've just tried to use #ifdef 18x and #ifndef 18x and found it doesn't come true either way unless the directive is explicitly defined in the source even though this 18x is meant to preexist.

And another one is #com, the moment the tokeniser strikes this one it core dumps. :(


Evan
 

evanh

Senior Member
Speaking of which, there looks to be a conflict with the # used for ascii coding of integers. I guess this one has been hammered out in another thread already.
 

Technical

Technical Support
Staff member
Cannot download into 18X versions 8.0 or 8.1 - "Incorrect hardware connected".
Runs okay on Windows 98SE.
#gosubs is a programming editor only directive - see part 2 of the manual.

The beta only supports 256 gosubs, therefore the (very old) firmware 8.0 or 8.1 (16 gosubs) cannot be used.
Another compiler will be available upon release for these very old devices.

#com and #ifdef should work in the command line compiler, we'll look into them. #com COM7 does work in the Windows version, we'll look at the linux again.
 
Last edited:

evanh

Senior Member
Just tested the #com with the v0.2 18x tokeniser and it's working. And the #ifndef is also working. Thanks.

The predefined #18x is not there yet though, unless I've got the spelling wrong. So I can't have conditional includes for specific Picaxe models yet.


Evan
 
Last edited:

Technical

Technical Support
Staff member
#18x is incorrect.

After you have used
#picaxe 18x

in a program you can use, for example,

#ifdef 18x
...this text is compiled
#endif
#ifdef 20m
...this text is not compiled
#endif
 

evanh

Senior Member
Yep, sorry, I should have been more verbose. I did mean #ifdef 18x coming true. Without me having to predefine it. The idea is that I should be able to detect what target tokeniser is currently parsing the source code.

Checking the relevant manual details (Page 7 of Manual 2):

#picaxe 08/08m/14m/20m/18/18a/18x/28/28a/28x/28x1/28x2/40x/40x1/40x2
Set the compiler mode. This directive also automatically defines a label of the
PICAXE type e.g. #picaxe 08m is also the equivalent of #define 08m. If no
#picaxe directive is used the system defaults to the currently selected PICAXE
mode (View>Options>Mode menu within Programming Editor).
Example: #picaxe 08m
That seems to be saying what I want - that the tokeniser will predefine what target it is tokenising for. This doesn't happen.


Evan
 

Technical

Technical Support
Staff member
We understand what you are saying, but the text in the manual was written before the release of the compilers. It should probably read 'the Programing Editor defaults to...' rather than 'system'.

You are saying, I'm using the picaxe18x.exe file, so it should already have '18x' predefined without the need for a #picaxe statement.

But we can see situations where people writing their own IDE may accidentally call the wrong compiler file, and a #picaxe directive error reports this mistake. Without the #picaxe line, the program may, for instance, pass a syntax check on the wrong compiler by mistake!

That is why we chose to make the #picaxe line compulsary if you want to have conditional sections of code for different chips. It's probably also encouraging best practise, which would be to always have the #picaxe line there regardless.

But if everyone complains, we'll naturally look at changing it!
 

evanh

Senior Member
If there is a way to pass it from the command line that'll do just fine. :)

EDIT: Umm, are you saying that when putting, say, #picaxe 18x in the source would cause an error when a, say, 28x tokeniser is parsing it. I was under the impression that such a directive wouldn't cause an error but hide it instead.
 
Last edited:

amdunn

New Member
I know you're going to shudder at this (it's a bit inelegant) but how about allowing

#picaxe 18X,20M

and if you attempt to compile it with a compiler that's not one of those two, it squawks?

Then have the compiler define the 18X or 20M variable implicitly like the PE does, as long as the compiler used matched ONE OF the chip types on the #picaxe directive.

The benefit is that you can still write code that will work on more than one PICAXE chip type, and write the conditional code appropriately, yet still catch compile errors when a completely wrong compiler is called:

#ifdef 18X
... do something appropriate to the 18X
#endif
#ifdef 20M
... do something appropriate to the 20M instead
#endif


The way it is now, you cannot write code that accounts for multiple PICAXE chip types and compile it with the command-line compiler, because the need to define #picaxe eliminates the ability to do target-conditional coding.
 

Technical

Technical Support
Staff member
Can't you use the following?...

#ifdef 18x
#define is_ok
#endif

#ifdef 20m
#define is_ok
#endif

#ifndef is_ok
#error Wrong PICAXE type supported (only use 18X or 20M)
#endif
 
Top