Compile a .BAS file as an .HEX file and upload to PICAXE... Possible?

DamonHD said:

More code memory and better power management together (ie >4kB in one segment + nap + wake-from-nap interrupts maybe): I've currently filled an 18M2+ to bursting even with all my code ticks of nearly 30 years and I'm having to start on AVRs at least for a parallel stack.

Maybe even better build tools (libraries and linking): I've had to sort of re-invent the concept to get my stuff done.

Rgds

Damon

Click to expand...

I agree, especially about >4 kB program space, with my PICAXE laptop using 3.5 kB of the program space and hesitant to add more features, risking running out of memory. I would say at least 16 kB would be ideal although 8 would work
(Maybe have an option to choose if program space is divided or not.
~Patrick

pleiser said:

with my PICAXE laptop using 3.5 kB of the program space and hesitant to add more features, risking running out of memory

Click to expand...

So why don't you mitigate that risk and use a 28X2 or 40X2, heaps more space ?

I would like it if the 4 slots could be (a) combined into one long slot, and (b) selectively divided into code or data space.

srnet: it is better for me to run fast and then nap as long as possible; slowing the clock below 4MHz is no help to me here I think.

Rgds

Damon

DamonHD said:

srnet: it is better for me to run fast and then nap as long as possible; slowing the clock below 4MHz is no help to me here I think.

Click to expand...

It might be.

Slow the processor down to K31, the current consumption is real low, and although the clock speed is very low it will still respond to interrupts, you can poll pins etc.

But it will introduce too much timing jitter for the precise sync I need to maintain with the FHT8V valve I talk too, for which the receiver is on << 1% duty cycle and for which all interactions involve a lot of tedious bit-banging.

My experience in the past with various power-saving schemes is that "run faster / sleep longer" is a good strategy (saves most energy), but I agree that that will not always be true.

I'm itching to have a good excuse to run both the PICAXE and AVR at a few kHz since very few of the CPUs in the past that I've used have been statically stable, ie able to run at an arbitrarily-low clock rate!

Rgds

Damon

PS. My dalliance with the AVR dark side probably starts tomorrow...

DamonHD said:

But it will introduce too much timing jitter for the precise sync I need to maintain with the FHT8V valve I talk too

Click to expand...

Then why use sleep\nap at all, the times are approximate only ...................

Because I can sleep for a reasonably-well defined time interval with minimal power consumption (all clocks off, etc) and then quickly poll (takes many CPU cycles) for a change in state. The result seems reliable and reasonably power efficient, though I hope to improve it, eg by using an I2C RTC for much quicker external polling of external state so I can spend fewer cycles awake.

"Race to sleep" seems to be a good general policy, but I shall be testing alternatives.

Rgds

Damon

srnet:

I am starting to toy with AVR stuff, and as an experiment I have tried dynamically scaling the clock (down to ~31kHz) rather than having the CPU sleep, and the saving there on my trivial example is about 50%, so useful, though not in the same league as 'nap' yet. (The AVR is drawing several mA still, rather than uA.)

https://sourceforge.net/p/opentrv/code-0/HEAD/tree/trunk/Arduino/test/BlinkPower/BlinkPower.ino

So my vote remains with more program space + nap or similar for new PICAXE hardware!

Rgds

Damon

DamonHD said:

I am starting to toy with AVR stuff, and as an experiment I have tried dynamically scaling the clock (down to ~31kHz) rather than having the CPU sleep, and the saving there on my trivial example is about 50%, so useful, though not in the same league as 'nap' yet. (The AVR is drawing several mA still, rather than uA.)

Click to expand...

Yes, but that's an AVR. A PICAXE is a PIC

One of my 28X2 lost model alarm circuits consumes circa 20uA in sleep, and 150uA when clocked at an (accurate and stable) k31.

Sleep\nap is fine, when it works, but as the manual says;

"The sleep command is not regulated and so due to tolerances in the microcontrollers internal timers, this time is subject to -50 to +100% tolerance. The external temperature affects these tolerances and so no design that requires an accurate time base should use this command"

So it might be suitable and accurate enough with one example of a PICAXE, but clearly not suitable for use in a repeatable design, unless of course the wide tolerance is acceptable.

srnet said:

"The sleep command is not regulated and so due to tolerances in the microcontrollers internal timers, this time is subject to -50 to +100% tolerance. The external temperature affects these tolerances and so no design that requires an accurate time base should use this command.

Click to expand...

Hi,

Yes, I thought the same, but it appears that the manual is now very out-of-date (and pessimistic for the latest chips) on that aspect. It seems that the "sleep" and "31kHz" modes might actually use the same oscillator, but it's confusing because the PIC has two "31 kHz" oscillators. One is the "Watchdog timer" (used for sleep) and the other is part of the normal on-chip phased-locked loop / frequency divider master clock subsystem (and I believe a raw PIC can use either for program control). So I don't think the difference between "sleep" and "31kHz operation" is very great (certainly not up to mA, nor 50% frequency difference).

To me, 150uA sounds quite high for "optimum" 31/32 kHz operation (I thought nearer to 20uA) but of course the external circuit must be designed appropriately. Then there are all the "optional" parts of the on-chip hardware such as the Brown-Out-Detector, Comparators, D/A converter, etc., which may be automatically disabled by sleep/nap, that may need to be disabled "manually".

Cheers, Alan.

AllyCat said:

It seems that the "sleep" and "31kHz" modes might actually use the same oscillator, but it's confusing because the PIC has two "31 kHz" oscillators. One is the "Watchdog timer" (used for sleep) and the other is part of the normal on-chip phased-locked loop / frequency divider master clock subsystem (and I believe a raw PIC can use either for program control).

Click to expand...

Thats possible, but would indeed be perverse and not what people would expect. If the LFINTOSC were being used for K31, I would expect to see a warning in the manual, indicating that clock accuracy at that setfreq, was potentially highly inaccurate.

As for Sleep doing stuff in the background, all the manual mentions is shutting down the timers ...............

As for the external circuit affecting things, of course this is true, so of course the example I gave merely replaced (on the same cirsuit) the sleep command with a setfreq k31 and a pause.

What I do is nap for a while and then poll the RTC to decide whether to start the next control loop.

Thus the shortness of nap is valuable, and potential variance in timing within the given bounds has been determined to be empirically unimportant for empirically chosen nap sizes, across a reasonable (10+?) number of 18M2+ PDIP and SMD parts and the remote devices that they are talking to.

Incidentally, I just combined your 31k clock idea in a short (1ms) pause on the AVR that would not have been worth attempting to sleep for with deep sleep the rest of the time and got my core control loop down to ~20uA, so both "race to sleep" and slow clock have merits and can be combined!

Rgds

Damon

I'm now using this new PE6 and try to program to PIC12F683 PIC-chip, not picaxe. How this can be programmed with this? Technical say this could do with this but I can't find to way to do it.

This is a future capability which is not supported by the current version of PE6.

Ok. When it is added, can I use Pickit 3?

I understand that is the intention, that standard Microchip programmers will be usable to program PICmicro chips.

Interesting thread...would be cool to eventually write a little windows program that would allow end users to modify a few basic parameters, then that program would make the changes to the variables in the Picaxe program and flash automatically via an AXE027.

Obviously not encrypted, but at the same time would NOT look like "simple English" BASIC if opened in notepad by the casual curious layperson.

Ben

I would bear in mind that the this 'feature' was first mooted nearly 3 years ago, so I would not hold your breath.

http://www.picaxeforum.co.uk/showthread.php?23670-Compile-a-BAS-file-as-an-HEX-file-and-upload-to-PICAXE-Possible&p=235601&viewfull=1#post235601

dmaxben said:

Obviously not encrypted, but at the same time would NOT look like "simple English" BASIC if opened in notepad by the casual curious layperson.

Click to expand...

You can already do 'customer updates' via an AXE027 like this, simply use PE6 File>export>Binary Image and then the customer uses the Chrome programmer app:

http://www.picaxe.com/Software/Drivers/PICAXE-Programmer-App/

Thanks for the tip!