Wishlist

hippy

Ex-Staff (retired)
My wishlist for future PICAXE developments. I know that some of these would not have backwards compatibility with existing PICAXE
firmware, but thought I'd get the whole lot off my chest in one go, as we've now been given that opportunity.

I also realise that some of these features are possibly specific only to advanced users, who should perhaps be looking at alternative devices such as native PICmicro devices. I also know that some of the things I'd like are not simple to implement and especially on a constrained device as a PICAXE. But here I go anyway ...

<b>Increasing the number of Variables </b>

More directly accessible variables would be nice, just adding 'b14', 'b15' and 'w7' would be a nice and logical start.

<b>Extend PEEK and POKE addessing </b>

PEEK and POKE are limited to accessing only $00 to $FF of SFR. It would be nice to have access to the full SFR space which some PICAXE's have.

<b>An INFRAOUT command </b>

There's no easy way to create an IR transmitter at the present.

<b>Interrupt changes </b>

Being able to interrupt a SERIN and INFRAIN while waiting to receive data or having some means of 'timing out' would be nice. Being able to detect a download hapening when waiting would also be nice.

<b>Allow constant expressions for SYMBOL </b>

This can make changes to code much easier to do, ie ..

- SYMBOL BASIC_DELAY = 10
- SYMBOL MAIN_DELAY = BASIC_DELAY/2
- SYMBOL LONG_DELAY = BASIC_DELAY+10

<b>Additional control structures </b>

Introducing IF/THEN/ELSE, WHILE/DO, REPEAT/UNTIL and SELECT CASE control structures would greatly enhance the Basic Language.

<b>Conditional Compilation </b>

Conditional compilation would allow a single piece of code to be written for a multitude of PICAXE devices which may have different memory capabilities and other facilities.

<b>Better error reporting </b>

&quot;Mistake in this line&quot; is not always the most useful message, leaving the user to try and work out what's wrong when the compiler clearly knows ;-)

<b>Allowing Assembly Language Routines </b>

The ability to import a single PICMicro .HEX file into the program code image which can then be called would allow assembly code to be used for timing sensitive and high-speed operations. A typical case would be in generating pulses for an IR transmitter.

<b>Single Stepping </b>

The ability to have the PICAXE stop after every DEBUG statement until a key is pressed, or allowing the PICAXE program to be single-stepped a statement at a time would enhance debugging.
 

Technical

Technical Support
Staff member
Symbol constant expressions are already supported for X parts, where they are most likely to be used. They will be available for all parts with the next main release.

Other requests have been noted.
 
Is it possible to add a header instruction to set up which picaxe is being used from within the program.

I use a number of different chips and am forever trying to program the wrong chip.

Perhaps this could be an optional command which override the progedit settings for more advanced users though I could see it being very usefull in a teaching environment.

Regards

James Carter
 

desulfator

Senior Member
DEBUG:
Enhance DEBUG to include text messages. For example,

DEBUG &quot;Calibration Error - Micro halted&quot;, T
DEBUG &quot;Sensor Overheat - Entering Cooldown Loop&quot;, T


Clock Speeds:
Allow the PIC to run at maximum clock speeds (X series * 5).


Additional EEPROMS:
Allow device polling for additional EEPROM connected. Allow larger programs to be loaded in the polled EEPROM.



Single stepping:
Single stepping a program would show the next command to be executed in a separate window.

All variables would display in the DEBUG screen just prior to the next command to be executed.

Single stepping on Loops would show all variables as above, upon entering the loop. The user could single step through the loop for a few times or press another function key to finish the loop and go on to the next command.


Multiple Programming Editors or modules:
Possibly could be reduced in size and be easier to download if they dealt with specific device categories.

For example,

A programming editor for the limited capability 08 and 18 series (08,08M,18,18A)

A programing editor for the X series with their enhanced commands and multiple clock speeds (18X,28X,40X).

A programing editor for BAS-800 use.

This change would allow mods to editors that only dealt with a few devices. It would allow continued use of editors for PICAXEs not being changed.

Or have device specific modules within the editor that could easily be replaced. If this were the case, Rev-Ed would only require the registration process when the whole enchilada is downloaded. Modules could be downloaded skipping registration. It can be assumed the user is already registered having already downloaded the complete package. Modules would be downloaded from folks already registered.


PULSOUT:
Refine PULSOUT to 1uSec increments or less.


Edited by - desulfator on 3/6/2004 8:12:38 PM
 

hippy

Ex-Staff (retired)
I must admit that since I got a PICAXE which does SERTXD I've found it much better than DEBUG, and allows the DEBUG &quot;Oops&quot;,b0,w1 etc type debugging to be simulated.

A note on modularisation : If you look in the &quot;picprog&quot; sub-directory, you'll see there is a separate compiler for each PICAXE variant already.
 

pmolsen

Senior Member
I hope Technical understood what I hope Hippy meant above with IF/THEN/ELSE that they need to be able to actually execute blocks of code, not just a GOTO. Makes proper structured code (no GOTO's) possible.
 

BeanieBots

Moderator
I would dearly love If/Then/Else.
The ability to interupt ALL commands especially serin or at least a timeout.
How about I2C slave mode ?
 

Wrightson

Senior Member
How about a click and drag function? I find i put a line of code in the wrong place &amp; clicking &amp; dragging is easier than copy &amp; paste. A small feature that would be appreciated by many?
 

Roy

New Member
The flow chart section should allow you to move flowchart symbols along with the conecting lines.
 

pittuck

Senior Member
you can get a usb =&gt; serial converter from tech-supplies.

install the driver for it and plug it in then it becomes a com port.

I use a PCMCIA serial port adapter, but i am not sure how much they cost.

 
 

hippy

Ex-Staff (retired)
Click-and-Drag editing is one of those things people either love or hate, and would need to be an option to turn on or off.

Elastic banding on flowcharts would be good, and Basic back to Flowchart conversion would be great too, but would only work with this elastic bandling of links.
 

andreww

Member
One feature I would like to see would be more of a programming editor thing, so would probably be backwards compatible,

I would like the ability to enclose chunks of code in some sort of brackets, similar to other languages, eg.

if b0 &gt; 128 {

'Do code here

} else {

'Otherwise do something else

}

I think this would make the programming easyer as you do not have to keep track of which label it is you're trying to return to,

Andrew Whitehead
 

mikek

Member
Enhance debug so it displays the current clock time (from Windows) each time debug is executed. I have some programs that do long &quot;sleeps&quot;, and I'd like to be able to determine how much of the sleep time remains:

&lt;misc&gt;
debug
sleep
&lt;misc&gt;
 

Dr_John

Member
can we have #include files? like C programming language.

a type of #include for flowcharts would be great. hide all your subroutines in one chart and leave a clean sheet for the main program
 

womai

Senior Member
To chip in my 2 cents:

- on top of my list would be shiftin/shiftout commands that the Basic Stamps have. There are so many SPI driven devices out and much fewer I2C capable ones, especially for high-resolution ADCs and DACs. I'm currently redesigning a whole project to use I2C instead of SPI because bit-banging SPI data is much to SLOOOOOW...

- second, at least for the -X picaxes, a true (buffered and interruptable) serial interface would be a treat, even when it were tied to specific pins.

- third, at least allow &quot;GOSUB&quot; in an if statement, not just &quot;GOTO&quot;.

Wolfgang
 

SIRA

Member
Roy's suggestion reg., USB-port PICAXE programability on laptops needs to be implemented immediately. The USB &gt;&gt; to serial cable from Rev.Ed is an overkill.
 

hippy

Ex-Staff (retired)
Having direct USB programmability requires that the PICmicro the PICAXE is built upon has USB capabilities. While there are more PICmicro devices becoming available which support USB they are more expensive and are only a limited range.

The alternative is to provide PICAXE's with a USB to PICAXE interface chip, but that is all the USB to Serial interface really is, and a lot cheaper and easier to use. The Rev-Ed USB to Serial lead is the cheapest I've seen in the UK, and reportedly one of the most reliable and functional around. It can also be used for non-PICAXE projects. Distances USB work over are a lot shorter than serial and nowhere near as flexible.

While I am sure direct USB programmable PICAXE's will be considered in the future, I don't see it as an immediate necessity.
 

Technical

Technical Support
Staff member
USB is not just a different electrical connection to RS232, it is a completely different protocol that requires a lot of microcontroller memory (or a separate custom USB chip) to use.

It is technically not possible to implement USB directly in all the PICAXE microcontrollers. USB is an intelligent, complex (plug'n'play) protocol that requires more memory space than the entry level PICAXE chips have available - you can't possibly have a PICAXE-08 or 08M chip with internal USB - there is quite simply not enough memory in the PIC chip to start with!

Whilst it is possible to add USB in some of the more expensive, high memory capacity PIC chips, the silicon cost of these higher level chips is often more expensive than the mass produced USB to serial adapters such as our part USB010 (&#163;4.99).

These adapters have a specially produced custom chip inside that includes the USB protocol. Because it is a custom chip, it is much cheaper to produce in volume than a microcontroller. Production in China means the whole adapter is lower in cost than a PICAXE chip with internal USB will ever be.

The other option is to add these USB chips (e.g. those made by FTDI) on the PCB beside the PICAXE chip. This is an option for the individual but in principle destroys the 'single chip' objective that most PICAXE users appreciate. These chips are often also only available in SM format, not ideal for the student or hobbyist.

To summarise we suggest people with a laptop without a serial port invest once in a single USB to serial adapter at &#163;4.99. This is the cheapest, and simplest, way around the issue.
 

Bloody-orc

Senior Member
but what about making a commandline that i could use to send out data over very popular RF chips/schematics. right now it takes 1,5 pages of coding and 200-300 bytes of memory loss.(plus most of the variables are gone). maybe adding this to the PICAXE chips (or at least in one of them (like 18X). i would be most happy if this is possible and is being considered.
Thank you for you time


Edited by - bloody-orc on 29/10/2006 13:11:56
 

Bloody-orc

Senior Member
so there is no hope for non Xbee module RF transmitters. so i have to throw away all my RF units and buy Xbee instead. Those are not so cheap and i have no need for 2 way transmission, plus the size is hummangos (huge). The units i have are the size of a 08M picaxe. i cant fit Xbee into my apliances.
sorry for komplaining so much...

PS you could then at least give us more variables and an opportunity to use libarys so that we dont have to add the same long text ni every soft we write...

Thank you for your time
Rain
 

andrewpro

New Member
There are literally hundreds of RF modules/devices/schematics out there. The ones you choose to use are your choice, as well as how you choose to use them To include options for all of them would be impossible, and even a fraciton of them would not be very efficient.

On top of that, what about people who dont use rf? Do they have to sacrifice program space for the limited number of people who would get a great advantage out of inbuilt RF commands?

There is a limited amount of flash in a pic chip. Every single feature that is added, above and beyond what is already there, is taking away program space. The features that are in a picaxe have to be a compromise between speed, available space, and cost. The same thing goes for variables, etc. If there's any &quot;empty space&quot; in the chip, your free to use peek and poke which are included in the interpreter. There's also read, write, and eeprom statements as well.

As far as libraries go, do you not save any of the programs you write? If you've written it once, you dont have to write it again. You can open more than one program in the editor at a time, and copy and paste to your hearts content. Code recycling is something all programmers should learn to take advantage of.


--Andy P
 

Bloody-orc

Senior Member
well i was just thinking of the comfort of programmers who then could include more programmes to makeprogramming even easyer for youngsters whu start programming. (like in C)
but ofcource the programming space in picaxes is limited so everything can not be done. i think i'll have to make a RF chip (using AVR) myself and add it to the schematic.

Thanks for your reply
 

andrewpro

New Member
I was going to suggest something like that last night, but was affraid it would come over as an attack or something.

Using BascomAVR and any AVR micro with SRAM, you can program in basic, have a larger program, and much faster execution.

I'm not saying it's a replacement for picaxes though. It's still not going to be as simple, cheap, and quick as using a picaxe.

--andy P
 

Dippy

Moderator
As someone mentioned earlier I reckon a timeout for SERIN would be extremely handy and would reduce the stuckability of many drops of code. Whilst I don't know how difficult all these things are to implement, I'm surprised its not standard issue as sometimes you cannot do without it.
 

Dr_John

Member
SYNTAX CHECK of BASIC:
One of the common mistakes my students make is to use return at the end of a piece of code, when there are no gosubs anywhere in the program.
I don't know why the y do it, but it is easily checkable - can you add it to the syntax checking?

Thanks.
 

Hitechbuzz

New Member
I was just wondering if it is possible to simulate some leds &amp; switchs on the PC program. that could indicate the flow of the program. and just rum the program on the PC without downloading it to the Picaxe. As I am new to this it may be possible to do this already but I have not seen it Thanks
 

nbw

Senior Member
How about...

1. Simple conversions to convert binary to dec, dec to hex, etc? Useful for RTCs

2. Offering chips with more program space. Eg. 18X, 28X package, but with 4K upwards instead of 2K. Or, investigate a DIP package chip that could continue from where the standard 2K memory finished, if you get waht I mean.

3. Number of variables variable up to say 32. If you use more, you have less pprogram space. If you only use say 4, you get more space than you currently get.

4. Choose your own basic commands! A feature to say, before programming the chip, which commands don't want. There could be a minimum / must have set, but not having the others could save space. E.g. you have a project that isn't using sound or infra commands, get rid of them... and reclaim the program space.

5. Not using all 128 or 256 bytes of non-volatile memory? Maybe the PAX could be configured in the options window to give back some more space!!

6. More PWM ports! How about having 3 or 4 individual ports per X-part chip - at least for the bigger chips. Or, rev-ed investigate and recommend an easy (= i2c) chip with multiple PWM ports, and sell it.

7. And yes, real if-then-elses would be nice.

thanks!!
 
Top