PICAXE X2 range released.

Technical

Technical

Technical Support
Staff member
Revolution are pleased to announce the release of the new X2 range of PICAXE microcontrollers. The first 5 parts in the range are:

- PICAXE-20X2
- PICAXE-28X2
- PICAXE-28X2-3V (1.8 – 3.3V version)
- PICAXE-40X2
- PICAXE-40X2-3V (1.8 – 3.3V version)

The new PICAXE X2 range is a complete new generation of the PICAXE chip, making use of the advanced features and architecture of the 18F series of PIC microcontrollers. The entire PICAXE bootstrap core and compilers have been rewritten to make use of this enhanced architecture.

Key enhanced features include:
  • Each pin can be individually configured as input or outputs
  • Up to 12 internal ADC channels available
  • Up to 256 general purpose RAM
  • Further 1024 additional bytes in the RAM scratchpad
  • Indirect RAM access to support easier use of arrays
  • Clock speeds up to 64MHz
  • Power supply down to 1.8V
  • Up to 4 internal program slots – up to 4000 lines of code with 1000 sub-procedures!
  • Also supports up to 32 programs stored in external EEPROM chips
  • Support for UNIO brand EEPROM chips using a single i/o line
  • New hardware interrupt pins
  • New comparator functions
Further details are available in our newsletter:

http://www.rev-ed.co.uk/docs/news2009q1.pdf

and X2 product briefing datasheet

http://www.rev-ed.co.uk/docs/picaxex2.pdf

Availability

The 28X2 and 40X2 parts may be ordered online now at www.techsupplies.co.uk for delivery starting Monday 6th April 2009. We are shipping to international distributors this week.

http://194.201.138.187/epages/Store.storefront/?ObjectPath=/Shops/Store.TechSupplies/Categories/PICAXE/PICAXEChips

The 20X2 will be available once stock of the blank PICs are available from Microchip. Our development is complete, but as this is a new release PIC we cannot ship until we receive the blank PICs! We have parts on order with Microchip but do not have a confirmed delivery date as yet.

Surface mount versions will also be available soon.

Software

To use the new X2 parts you are required to update to the following versions
  • Programming Editor 5.2.3
  • AXEpad 0.1.4
  • Logicator for PICs 3.2.8
  • PICAXE VSM (X2 models under development)
The updated manuals are included in each installation, and are also available online.

Enjoy!
 
fernando_g

fernando_g

Senior Member
"Clock speeds up to 64MHz

Up to 4 internal program slots – up to 4000 lines of code with 1000 sub-procedures! "

WOW! We are talking serious computing power here.
 
S

SilentScreamer

Senior Member
Glad to see them finally arrive. Theoretical 36 program slots!!! The PICAXE laptop could get very powerful.

Is there any news as to the 28X2 module?
 
Last edited:
A

Andrew Cowan

Senior Member
In march, and with a day to spare! Well done! The 64Mhz resonator is a great feature - making POV stuff etc much more possible.

Internal voltage reference is a fantastic feature.

I've put my order in!

A
 
A

Andrew Cowan

Senior Member
Plus external program slots via EEPROM. I think I'll try the RGB LED POV display I've always wondered about.

A

EDIT: 17 outputs on a 20 pin chip, at 64MHz and 4000 lines of code for £3.50. :eek: Amazing!
 
Last edited:
hippy

hippy

Ex-Staff (retired)
Take care with rushing towards expecting 64MHz operation ... Clock speeds depend upon which X2 you are using because they all use different family devices.

The 28X2 and 40X2 internal oscillator is 8MHz max, and the chip is limited to 40MHz operation, so 16MHz with a 4MHz crystal - SETFREQ EM16, 32MHz with an 8MHz crystal - SETFREQ EM32.

The 28X2-3V and 40X2-3V internal oscillator is 16MHz max ( SETFREQ M16 ), and the chip can handle 64MHz operation with a 16MHz crystal - SETFREQ EM64.

Haven't tried 64MHz, but a 28X2-3V 'zinged along' at 32MHz using an 8MHz resonator giving 38,400 baud SERTXD :)
 
A

Andrew Cowan

Senior Member
I think the 20X2 seems to have the most 'bang for the buck'. At £3.50, it has a vast amount of features. Shame the 28X2 won't run at 64MHz at 5V though...

A
 
hippy

hippy

Ex-Staff (retired)
Yes, I was planning to update the Pin Type and Output Current posts.

On output current we're stuck with whatever Microchip dictate; 28X2/40X2 and 28X2-3V/40X2-3V are rated the same; 200mA for all ports combined, 25mA per pin.

The prelimary information in the latest datasheet shows the 20X2 should be 90mA for all ports combined, 25mA per pin
 
M

MartinM57

Moderator
<Future Product>

...it says at the bottom of that page .. and described why in post #1.

There should be a prize for the most innovative use of the "slot" feature - any entries yet?
 
M

manuka

Senior Member
Bravo Rev-Ed! AFAIK a grand total of 16 PICAXEs have been released over the past 8 years (some now obsolete of course). At this ~2 p.a. rate expect perhaps a 08M2 or the like by Xmas. So long as it SERIN times out ...

The near gob smacking 20X2 looks the real "cat amongst the pigeons"-I half expect to see on board Zigbee as well! I'll have a 6-pak thanks. Of course,given that a 20X2 fits nicely on a typical breadboard & runs off 2 x AA cells, all manner of lean & mean applications spring to mind. Watch out 18Xs... ? Stan
 

Attachments

Last edited:
N

nickpatts

Member
AXE091

Hi,

I take it the new AXE091 project board is compatiable with the x2 versions, well the normal power ones anyway?.


Nick
 
N

nbw

Senior Member
Credit where credit's due - well done! The 20x2 in particular looks like a wolf in sheep's clothing :)
 
H

hax

New Member
Can we have a 20X2 in SMD please?


Also, I noticed I can't find SMD versions of the 08M and 18X on the techsupplies website which used to be available....... or am I having a blind day?
 
M

Marcwolf

Senior Member
Very very nice.

Only one minor gripe - If one has an external program slot you loose the I2C capabilities. For people who use the SD21 ()21 Servo Controller) this can be a bit of an issue as the communications to it is via the I2C.

Otherwise - I'll have to start scheming on what I can build with these :>

Many thanks for the development..

Dave
 
M

Marcwolf

Senior Member
Question - the the 28X2 module with the built in voltage controller - is the the 28X2 stnd, or the 28X2 3V.

As both chips have significantly different features it be interesting to know.

Many thank
Dave
 
M

moxhamj

New Member
Looks great. The 20 pin one could be just the ticket. I presume X2 parts can do hserin (ie a timout)? And there is hippy's comment about 38400 baud (my favourite baud rate!). So one could imagine using a 20x2 as the core of a radio transceiver, and use cheap $2 raw RF modules. Maybe 2 20x2s, thinking about it a bit more. But there is a nice big ram buffer so it can handle xmodem and can hence transfer files. And 'programs' can be stored in eeprom. Hmm - that looks interesting. So it might be possible to transfer those programs wirelessly? And then run them? That is starting to look like an operating system. I reckon these chips could easily run xmodem. Download your POV graphics/text file wirelessly!
 
hippy

hippy

Ex-Staff (retired)
@ nickpatts : The 20X2 is drop-in compatible with the 20M, the 28X2 / 40X2 are drop-in compatible with the 28, 28A, 28X, 28X1 / 40X and 40X1 so 5V X2's will work in any board designed for earlier variants - I haven't gone through doing an ADC pin-for-pin comparison but I believe they are the same.

@ Haxby : Yes, X2's will become available in SMD versions.

@ Marcwolf : The loss of other I2C access when running from external slot memory is regrettable but there's no easy way round that. Because the firmware would have to make I2C access to continue to execute the program while any Basic program I2C command is being executed that would mess up any I2C you were hoping to achieve. The cases where someone would need to run programs from external I2C and execute I2C commands would seem to be rare and should be easy to design around, so should not be a practical limitation in the great majority of cases. I think the limitation sounds worse than it will be in practice; a bit like, you can fit a nitrous injection system to your car but you will have to accept the loss of being able to tow a caravan.

@ Marcwolf : I believe the X2 module (AXE200) use the 5V part, and 3V modules would be marked as X2-3V, but I will check that.

@ Dr_Acula: Yes, all X2's support HSERIN, high-speed serial, I2C and SPI.
 
S

SilentScreamer

Senior Member
hippy said:
@ Marcwolf : The loss of other I2C access when running from external slot memory is regrettable but there's no easy way round that. Because the firmware would have to make I2C access to continue to execute the program while any Basic program I2C command is being executed that would mess up any I2C you were hoping to achieve. The cases where someone would need to run programs from external I2C and execute I2C commands would seem to be rare and should be easy to design around, so should not be a practical limitation in the great majority of cases. I think the limitation sounds worse than it will be in practice; a bit like, you can fit a nitrous injection system to your car but you will have to accept the loss of being able to tow a caravan.
Click to expand...
I'm still relatively clueless as to the X2's operation however could you copy the program that is to be used from the I2C eeprom then run it on the chip (I saw a command somewhere which does it but didn't read too much into it)? It would be slow at starting I expect but would maintain I2C usage?
 
Technical

Technical

Technical Support
Staff member
Haxby said:
Can we have a 20X2 in SMD please?

Also, I noticed I can't find SMD versions of the 08M and 18X on the techsupplies website which used to be available....... or am I having a blind day?
Click to expand...
All X2 parts will also be available in SM format. Other parts are here (note that SM parts have a separate shop section - this is quite deliberate as when they were mixed with the DIP parts lots of people bought the wrong ones accidentally!)

http://194.201.138.187/epages/Store.storefront/?ObjectPath=/Shops/Store.TechSupplies/Categories/PICAXE/SurfaceMount
 
M

MFB

Senior Member
Well done Rev-Ed! Well worth the wait.

That 1024 byte scratchpad should allow me to use the 512 byte block write mode on the uDrive SD card interface, which I had assign to the scrap bin.
 
hippy

hippy

Ex-Staff (retired)
@ Boriz : No, there's only one PWM on-chip for the 20X2 though this can be routed to any of four output pins or used for half and full H-bridge control using the HPWM command.
 
D

Dippy

Moderator
Roll your own Boriz.

I've just done 8 separate channels of RGB , mulitplexed, serial input control and no flicker.
So, thats 8x3 independant (software 255 step) PWM channels which can read serial input commands and no flickering ever. (Unless you waggle your eyeballs really fast). 11 wires plus ground.

If a numpty like me can do it then an expert like you can do it even more easily.
Hint: 255 steps is a little OTT in practice.
 
hippy

hippy

Ex-Staff (retired)
Assuming it's not a case that the code only works today ... :)

It would be interesting to hear what techniques you used to achieve that as that can make or break the project.

The obvious FOR-NEXT loop with pins on when a channel level is lower than the incrementing index variable is the simplest approach but doesn't have the speed in my experience. Variable length PULSOUT's seem to do better. With needing to keep the refresh rate up and maximising LED control against getting data any extraneous commands can quickly cause problems.

One thing I have found is that using a PICAXE-28X1/28X2 as an I2C slave is very handy as a controller can simply drop channel levels / display data into the slave's scratchpad and they are ready to use in the LED control loop. Using an I2C slave do do the LED control and another dicating what it should be showing is, IMO so far, probably the best approach to high channel number multiplexing.

I've been focused on 7-segment display multiplexing but one day will get myself some RGB LED's to play with.
 
T

Tom2000

Senior Member
Technical said:
Up to 4 internal program slots – up to 4000 lines of code with 1000
Click to expand...
Technical, have you any plans to revamp the BASIC implementation to include local variables and passed parameters to and from subroutines?

One could possibly write a huge program, or set of programs, for one of these X2 parts. However, even the program memory in the 28X1 has far outstripped the capabilities of the language. The X2 only exacerbates the situation.

Right now, it's impossible to write a readable and maintainable program that occupies a fair share of program memory. (I've tried and failed. Twice. I spent many hours on each attempt, giving the development a good, solid effort. I really wanted to bring in both designs using the 28X1. In one case, I wound up using an Arduino. For the other, I implemented my design using a PIC 18F2431.)

There is absolutely no way that one can take advantage of the program space and capabilities of the X2 using your current language structure.

Thanks,

Tom
 
M

moxhamj

New Member
Re Tom2000

"Technical, have you any plans to revamp the BASIC implementation to include local variables and passed parameters to and from subroutines?"

A very good question, and one that I'll second. It is a simple "yes/no" question, and I guess if the answer is "no" then we can leave it at that.

If "yes", I agree that the huge program space of these chips needs code that is easy to understand. Local variables are one of those structures - I agree 100%. I also agree 100% with passed variables. And to that I might add some string handling.

This may not be as complex as it seems. I've been doing some work recently with an ancient program called sbasic which was written for the Kaypro in the late 70s/early 80s. It is long forgotten, but in my humble opinion it was way ahead of its time, and includes some structures which would be considered very modern. Two of these are...local variables and passing parameters.

What this means in practice is you can create your own language. So Rev Ed might not necessarily have to write any actual code like string handling. All that is needed is the ability to create your own functions and procedures, and many people on this forum would go to work writing those procedures and sharing them.

sbasic has simple string handling like mid, left, right and instr. But it doesn't have the more modern functions like lcase and trim. So... you add them, and then use them in exactly the same way as the inbuilt instructions. This is the key really - the new functions you write end up being used with the same syntax as inbuilt instructions.

An example in sbasic for the lcase function:

Code: 
function lcase(mystring=string) = string
	var i=integer
	var outstring=string
	var ch=byte
	outstring=""
	for i=1 to len(mystring) 
  		ch=mid(mystring,i,1)
		if ch>='A' and ch<='Z' then ch=ch+32	
		outstring=outstring+chr(ch)
	next i
end=outstring
To use it:
var teststring=string rem note not the same as the string name used in the function
teststring="HELLO WORLD"
teststring=lcase(teststring)

Procedures work in a similar way, except you can pass multiple paramters.

This leads to a different programming style. You write functions and procedures as seperate entities, with their own local variables. Then you put them in a library, and when they are needed you drop them into the code. Then the "actual" program might end up being only a few lines and is a lot easier to follow.

Local variables means that memory can be conserved. With strings for instance, you declare a string in a function and it is discarded at the end, freeing up memory. (sbasic also can conserve memory by keeping strings short if you want, eg var mystring=string:10 It defaults to 80 bytes if you leave out the colon and number).

Functions and procedures are very powerful. I think C got onto this earlier than basic, but as an example, even something as simple as PRINT could actually be a hand coded function. I'm looking at some 18X picaxe code I have written to print strings to an LCD and it is so messy I don't want to post it here!

Local variables, passing variables, and (if possible) some simple string handling. It would really complement these chips!
 
Last edited:
hippy

hippy

Ex-Staff (retired)
Technical may well have their own views but I have considered how to add local variables and parameter passing in the past. While it is possible, it is not easy to do while keeping within the spirit of how the PICAXE programming language is now.

The first problem is in deciding what a subroutine is and what a subroutine argument or local variable would be, plus how they would be represented and used, then where they would be put within the chip and how are they accessed ? It gets even more complicated when considering function return values.

The language is currently pretty much 'anything goes' as opposed to being rigidly block-structured and this suits both its primary market and the skills of the users there along with many others, so any change has to not alienate the existing markets and be able to work in conjunction with the way the PICAXE is used now.

On taking advantage of the larger memory I think that really depends on what one is doing. I don't think it's unreasonable that if Microchip gives us extra capacity for code then that should be passed on to the users rather than simply rendering it inaccessible. We don't particularly promote new PICAXE's as having more memory as the primary selling point, that's just something which comes along 'for free' as we add extra capabilities and more flexibility for the PICAXE range.

It may well be true that for many cases there is far more code space than anyone should need to use and it may be best to think of the extra space as allowing room to grow for those programs which do. This extra capacity is ideal for people with programs well suited to the existing PICAXE language but want to have larger lookup tables, longer text strings for output and display and allows greater flexibility in using block structured commands without running into limitations they may otherwise run into.

In terms of being able to exploit the large memory capacity, this is why I say it depends on what one is trying to do. For programs which are primarily state machines or have large but mainly linear flow, use relatively little data and are not overly complicated in themselves this can be a perfect fit - The extra capacity would have been ideal for an MP3 player controller I worked on for the 18X where I ran into memory limits there and had to trim out some functionality and shorten LCD display messages.

The relatively low cost of the PICAXE also makes it very useful where particular capabilities can be taken advantage of even if a lot of its abilities 'goes to waste'. As smart peripherals, even if needing very little program memory, they can still be an appropriate and cost effective solution because of what else they offer.

Some programs, even small ones, are admittedly not ideally suited to the PICAXE programming language; recursion is one particular case. The PICAXE could be thought of as a very advanced and capable process controller rather than a general purpose software development platform for complicated algorithms and processing. As always there are appropriate tools for any job and trying to bash a square peg into a round hole isn't always the best approach, and making the round hole takes square pegs isn't always appropriate nor easy. I think everyone here accepts that the PICAXE may not be the best choice for some particular jobs and that there may be better alternatives to use in those cases. I expect that will always be the case, and for all products.

One thing introduced with the X2 is 'bptr' and associated '@bptr' variables which can help with emulating parameter passing as well as allowing the byte variables to be indexed, while Peek and Poke can also be used to indirectly manipulate variables fairly easily.

Obviously we do take note of how people use the PICAXE, what problems they run into, and how we can make life easier for them, so things can and do change. Your points are perfectly legitimate so please don't take this as rejection or dismissal of them. I have thought about the issues you raise, expect Technical and others to have also, and I am sure we will continue to do so.
 
hippy

hippy

Ex-Staff (retired)
@ Dr_Acula : It is a simple "yes/no" question

I'm not sure it is, not as clear-cut as "yes, we are revamping the language and will provide that", "no, we're never doing that", as there are a number of reasonable responses in between. I'll leave Technical to give an official response.
 
M

moxhamj

New Member
Good points Hippy.

Hmm - brainstorming passing variables. Maybe start with something very simple - only byte variables for the moment. If you declare it with a dim or a var or whatever, it stays around till the end of the function or procedure. Writing a compiler to do that is a bit complicated - sbasic cheats a bit there by putting all the functions at the beginning and the "main" program is the last bit of the program. Also, you can't address functions below the one you are using. So you put the simple ones at the beginning, and more complex ones further down. It makes for a slightly different structure but is much easier to write a one-pass compiler.

Of course, a two pass compiler would be the better way to do things, and I found that some years ago writing a high level program that took a 'schematic' language with graphical things like timers and leds and logic gates and turned it directly into raw machine code. The first pass collects up all the variables and then the second pass has access to this list.

So - you declare your variables and the program keeps track of where they are, and when they are deleted at the end of a function that frees up a byte for another function. So one complicated thing behind the scenes is keeping track of that list. Probably just have a rolling array and add new ones at the end and when you run out of memory start at the beginning and put new ones in the gaps that have now appeared in the array.

Passing and returning just passes the location in ram of the byte variables. That ends up pretty simple.

The more complicated stuff is what variable types you are allowed. You can do a lot with just 4 - byte, integer, real and string. But real and string are a lot more complex. Real is probably the hardest, but I've seen a Z80 compiler that can handle floating point and it is cunning but not all that hard.

String may end up quite easy if you declare the string as fixed length. Then they are just a list of bytes and you know how long the list is too.

Obviously it would need to be backwards compatable with current code.

I'd like to get hold of one of these chips and really test out that memory and see how it works!
 
Last edited:
B

benryves

Senior Member
I quite like the BBC BASIC approach; you can use the LOCAL keyword within a procedure or function to push variables to the stack, and they are automatically popped back off when the procedure/function returns. Procedure or function arguments are implicitly local.
 
You must log in or register to reply here.
Top