maximum gosubs on 28x1

[ercotronic]

Hi All,
I only seem to be able to get 238 gosubs to work on a 40x1 A.0 chip. Basically the compiler will let me download 255 but the chip resets at the 239th gosub and starts running the code over again. The gosub is writing the value of b0 to incrimental locations on an I2c eeprom.
eg:
let b0 = 123 'location 0
gosub ee_wr
let b0 = 123 'location 1
gosub ee_wr
.
.
.
let b0 = 4
gosub ee_wr ' location 238
end

ee_wr:
hi2cout w2,(b0)
let w2 = w2 +1
debug w2
return

regards Eric

 

[hippy]

It looks like the END statement isn't ending the program.

1) Replace "END" with "DO:LOOP" and see if that stops the restart.

2) Make sure you have the latest 5.1.3 Programming Editor installed. If not, upgrade, Replace "DO:LOOP" with "END", and test again.

3) If it keeps resetting with "END" using 5.1.3, file it as a bug in the Software Feedback forum. Don't forget to include your PICAXE's Firmware Version number

 

[Tom2000]

Uh, oh.

Am I reading this thread correctly? Is the 255 limit the number of subroutines or the number of gosub calls allowed in a program?

If you're only allowed to call subs 255 times, I'm in big trouble.

Tom

 

[hippy]

It's the limit on the number of GOSUB commands. It's actually a 255 maximum on the 28X1 because there's an 'invisible GOSUB' which handles interrupts.

Any subroutine can be called any number of times.

There's another limitation of subroutines calling other subroutines; these can only be four deep or eight deep on the 28X1/40X1. Interrupt require one of those levels, so subroutine calls can only be three or seven deep when an interrupts are enabled.

 

[Technical]

It's the number of gosub commands. If you have lots of different sub-procedures to call a good workaround is

on b1 gosub sub1,sub2,sub3,sub4 etc.

This enables you to choose between many different sub-procedures but only 'use up' one of the 255 gosub commands.

5.1.3 should resolve the 'end' issue, or you could always just use 'stop' instead.

 

[Tom2000]

Thanks, folks. Something to keep in mind. I guess I didn't get the nuance of that spec I read.

I'm not in as much trouble as I thought, though. I loaded my program into a word processor, then replaced gosub with gosub to get a count. "Only" 137. So far.

Tom

 

[Jeremy Leach]

I've done exactly the same Tom using a Word Processor ...would be 'nice to have' the Editor report the number of used Gosubs in the syntax check results.

 

[premelec]

In the good old days I had a program called
'crossref' which showed all variables and subs and where they were called - I guess someone [Hippy as a relaxing excercise] could write one that would do this... and give the counts if you wanted them too...

 

[Tom2000]

<i>There's another limitation of subroutines calling other subroutines; these can only be four deep or eight deep on the 28X1/40X1. Interrupt require one of those levels, so subroutine calls can only be three or seven deep when an interrupts are enabled. </i>

I've gotta hit those books again. I could have sworn that the stack limit for the 28X1 was eight. I know it's four on the 18X. (I learned that by hitting the limit.)

I'm beginning to think that writing a comprehensive Picaxe application is an exceedingly difficult process, and a comprehensive, maintainable application an impossible process. It is *much* easier to write C for a PIC than it is to write BASIC for a Picaxe.

I think I'm going to abandon the idea of building a portable project, knock the working code out in a few days on an 18F2431, and let folks buy a PIC programmer if they want to build a remote. This process is going nowhere fast.

Tom

 

[hippy]

<i>I could have sworn that the stack limit for the 28X1 was eight. </i>

I could have sworn that's what I wrote <img src="smile.gif" width=15 height=15 align=middle>

<i>I'm beginning to think that writing a comprehensive Picaxe application is an exceedingly difficult process, and a comprehensive, maintainable application an impossible process. </i>

PICAXE Basic doesn't have everything I'd like for a commercial, production quality programming language, but then, that's not what it was designed as. Recent additions, block-structured programming and so on, have really added to its abilities.

I don't agree that comprehensive applications cannot be written, but I'll accept that programs have to be written within a PICAXE framework that may not always be the best for a particular application.

Being able to write good PICAXE programs requires as much knowledge about the programming language as using anything else does.

<i>It is *much* easier to write C for a PIC than it is to write BASIC for a Picaxe. </i>

I believe that's really a matter of experience, prior knowledge and access to tools and pre-written libraries, coupled with what the application actually is.

If we strip away the high level commands of the PICAXE and libraries and in-built functions of C and other languages there's not a lot in it. The main difference is the limited number of variables, and a lack of arrays and structures, and no ability to use subroutine parameters and function returns.

<i>I think I'm going to abandon the idea of building a portable project, knock the working code out in a few days on an 18F2431, and let folks buy a PIC programmer if they want to build a remote. This process is going nowhere fast. </i>

It's always reasonable to question why one is using this, that or the other, and to decide what the goal is and the best platform to use to get there.

At the proverbial end of the day no one is forcing anyone to use any particular architecture. In support of the PICAXE, like anything else, the more one uses it, the more familiar it becomes, and the easier it is to use.

 

[Tom2000]

Yes, agreed.

My original objective was to implement my little gizmo in a portable format that anyone could duplicate without having to buy or build development hardware. It looked like the Picaxe fit that bill, but it's not up to the task.

However, before I give up on my prime goal, portability, I think I might try something else that I've been thinking about. Not quite as transparently portable as a Picaxe, but it doesn't require specialized hardware. At least I don't think so.

Well, folks, take care. It's been a slice.

Tom, out.

 

[hippy]

If you've described your gizmo I'm afraid I've forgotten personally what it is, but it can always be an idea to throw the idea open to the forum masses and see what they can turn up.

The ease of having others duplicate a project using a PICAXE is something which doesn't always crop up in discussions of PICAXE versus The Rest and it is appealing when trying to produce something for others to also use. That doesn't mean it will always work out though.

Good luck with your project whichever way you go.

 

[Tom2000]

<i>If you've described your gizmo I'm afraid I've forgotten personally what it is... </i>

Hippy, it's a very simple little box to control a digicam. It combines an intervalometer, wireless remote, external trigger, and a camera power supply. As embedded control apps go, this one is very simple. RTC, LCD, a few buttons, and a couple of logic signals from the external trigger circuit and the RF receiver. No fancy timing, no complicated peripheral interfaces. Just a very basic, clean design.

I have it pretty well documented on my page: <A href='http://www.mindspring.com/~tom2000/picaxe/picaxe.html' Target=_Blank>External Web Link</a>

If you have any questions, my email link is right at the bottom of the page, below the block diagram.

Hippy, many thanks for everything you've done, and everything you do, to help the rest of us. I really appreciate it, and know how much work you devote to helping others. You're definitely on my good guy list.

All the best,

Tom

 

[Jeremy Leach]

Just fyi on &quot;no ability to use subroutine parameters and function returns.&quot;

I've been working with my variable stack idea (Push and Pop variables to/from the scratchpad) and passing parameters to/from subroutines via 'PARAM' RAM locations. It's made coding of my large program a whole lot easier, and modular, and the modules should be portable to other programs.

 

[Technical]

v5.1.4 now has a simple 'count word' feature (Edit menu) so you can count the occurrance of any word (e.g. gosub as requested above)