I really like the picaxe chips they are very easy to use and quite versatile, when I needed a bit of extra speed I used to use the convert basic to assembler function in PE5 which was just enough to do the job, it unfortunately was dropped in PE6 and the PE5 version will not as far as I can tell run on the new windows 34/64 bit systems. My original intention was to learn pic programming using picaxe basic then progress on to using assembly language as I used to on the Z80 and 6809 processors of the seventies and eighties (yes I'm well past the first flush of youth and I'm out of date with the tech). I really don't want to get into using compiled basic because most of the compilers I have looked at have so many bells and whistles by time you have set everything up Define include processor ...ditto you may as well have used assembler! I tried Arduino and hated it because of C, to blink an L.E.D takes lines of code to set up and about three lines for the program! I have some resevations about some features of picaxe basic but I find most of them can be ignored. I thought at least half of my remaining brain was still working until I decided have a go at MPLAB 1/2/3/4/5/6/7X or whatever the version will be by time I finish this post I find it incomprehensible not the coding the whole IDE or whatever they want to call it next week is ______(insert expletive here). They say read up I have of and on for five years everytime I nearly get there someting else changes never mind the Pickit2/3 debaucle and 90% of text books and the net (often full of misinformation) out of date. Ok a bit long winded and not exactly picaxe anyone got any suggestions.
Picaxe what next?
- Thread starter bag57pipe
- Start date
BeanieBots
Moderator
How about Rpi running Gambas3 (very similar to VB) with PICAXE doing the hardware interfacing.
High level coding in BASIC with nice antialiased graphics that could be on a very readable 3.5" colour display including touch sense.
PICAXE to drive any hardware that also protects the fragile Rpi I/O from any accidents.
Rpi to PICAXE comms can be serial or I2C or even Bluetooth with some cheap modules.
My solar monitor does just that. PICAXE does all the control and sends data via Bluetooth to Rpi+3.5" TFT display to show results graphically and touch screen to turn devices connected to PICAXE I/O on/off.
High level coding in BASIC with nice antialiased graphics that could be on a very readable 3.5" colour display including touch sense.
PICAXE to drive any hardware that also protects the fragile Rpi I/O from any accidents.
Rpi to PICAXE comms can be serial or I2C or even Bluetooth with some cheap modules.
My solar monitor does just that. PICAXE does all the control and sends data via Bluetooth to Rpi+3.5" TFT display to show results graphically and touch screen to turn devices connected to PICAXE I/O on/off.
Picaxe is an ideal platform for kids, students, education, and for hobby projects where program execution speed is not critical. Picaxe has even made into Earth Orbit where it performed beyond expectations. It is a good product with good support.
However, if program execution speed is required then you will need something else. Unfortunately your seem to have ruled out nearly all alternatives.
To get execution speed you will need to use a compiled language of some kind. You seem to have ruled out compiled BASIC, Arduino and MPLAB (C, or ASM). So what does that leave ?
Not very Much.
There is "PIC Pascal" and "JAL" for PICS. I am not sure of alternatives for AVR except for Atmel Studio. But these all require that you, the programmer, do the things that Picaxe does automatically. ie. Set up the Oscillator, #defines, set pin directions, pragmas, configure peripherals, et al .. But this is really all normal stuff and a part of embedded systems programming. You have to do some added work.
The bottom line is that if you want code execution speed you will need to accept that you will: (1) Need to use a programming language that can be compiled/assembled, (2) that there will be significant learning curve involved ( This stuff is not easy). And (3) that there is no perfect platform.
I hope you find what you are looking for.
BTW:
MPLAB is now MPLABX as in MPLAB "10" (Version 3.5) and it is indeed a monster of an IDE and difficult to navigate . However if you use the "Wizards" things can be easier. The included tutorials are helpful.
However, if program execution speed is required then you will need something else. Unfortunately your seem to have ruled out nearly all alternatives.
To get execution speed you will need to use a compiled language of some kind. You seem to have ruled out compiled BASIC, Arduino and MPLAB (C, or ASM). So what does that leave ?
Not very Much.
There is "PIC Pascal" and "JAL" for PICS. I am not sure of alternatives for AVR except for Atmel Studio. But these all require that you, the programmer, do the things that Picaxe does automatically. ie. Set up the Oscillator, #defines, set pin directions, pragmas, configure peripherals, et al .. But this is really all normal stuff and a part of embedded systems programming. You have to do some added work.
The bottom line is that if you want code execution speed you will need to accept that you will: (1) Need to use a programming language that can be compiled/assembled, (2) that there will be significant learning curve involved ( This stuff is not easy). And (3) that there is no perfect platform.
I hope you find what you are looking for.
BTW:
MPLAB is now MPLABX as in MPLAB "10" (Version 3.5) and it is indeed a monster of an IDE and difficult to navigate . However if you use the "Wizards" things can be easier. The included tutorials are helpful.
try http://gcbasic.sourceforge.net/ for pic and amtel and maybe http://scruss.com/blog/2015/03/25/running-freebasic-on-raspberry-pi/ for RPi. I don't do C and pic asm is tedious. RPi is linux which to me is windows cmd difficult and python is pure slow. There's the pigpio pack that probably works with it. I'd go for gc basic and a pic programmer. Shows asm for each basic line and the usual hex file. ps I never uses mplab,just mpasm.exe and notebook,much quicker.
Last edited:
westaust55
Moderator
@bag57pipe,
If What speeds are you running your PICAXE chips at?
M2 parts can operate at up to 32 MHz with the SETFREQ command.
The 20X2 can operate up to 64 MHz.
Using an external resonator the 28X2 and 40X2 can be run well above the nominal 64 MHz max speed.
I have circuits with 28X2 running reliably at 80 MHz (20 MHz resonator - no warranty through) and hippy has in the past operated one at 100MHz (25 MHz resonator).
Running at these higher speeds will require that you determine new constants for comms such as i2c and hserout.
If What speeds are you running your PICAXE chips at?
M2 parts can operate at up to 32 MHz with the SETFREQ command.
The 20X2 can operate up to 64 MHz.
Using an external resonator the 28X2 and 40X2 can be run well above the nominal 64 MHz max speed.
I have circuits with 28X2 running reliably at 80 MHz (20 MHz resonator - no warranty through) and hippy has in the past operated one at 100MHz (25 MHz resonator).
Running at these higher speeds will require that you determine new constants for comms such as i2c and hserout.
cravenhaven
Senior Member
You could have a look at the micromite/maximite chips. They are based on the pic32mx processors so should be significantly faster but use the basic language.
http://geoffg.net/mini-maximite.html
http://geoffg.net/mini-maximite.html
PhilHornby
Senior Member
PE5
If I try to use the "Convert Basic to Assembler" wizard, it fails with: "You must have a Revolution PIC Programmer attached to use this feature!" - which is fair enough, since I don't have one.
PE 5.5.6. still runs on my Windows 10 Pro 64bit system (I'd forgotten it was still installed).
If I try to use the "Convert Basic to Assembler" wizard, it fails with: "You must have a Revolution PIC Programmer attached to use this feature!" - which is fair enough, since I don't have one.
If you remember Z80 you may even have dabbled with FORTH
http://flashforth.com/
If you didn't, it's probably not a good time to start - "Idiosyncratic"
http://flashforth.com/
If you didn't, it's probably not a good time to start - "Idiosyncratic"
Even so , Compiled C Code or Compiled Basic (eg. Great Cow) will execute ~50 times faster on the same PIC operating at 16 MHz.
The maximite/minimite uses a limited range of 32-bit PIC Chips and like the Picaxe uses Interpreted Basic that resides in the chip's Flash Memory. Math functions are a bit faster but all in all not much better code execution speed than a Picaxe unless you use the 250MHz MMX5 version. However it does now support adding inline C and ASM Code that can speed things up significantly. But it is still interpreted Basic and code execution speed will never compare to compiled code
A good question since you have dissmissed the obvious contenders.
If you are looking for something PICAXE like, but just more powerful and faster, I dont think your going to find it.
There is an interpreted Basic that keeps getting mentioned, but my observation would be that its a constantly changing environement, not stable and reassuring like PICAXE. What I like about PICAXE and indeed a lot of compilers is that the editors syntax check. If you have a typo in your program, you know about it before the program is loaded. With some intrepretters you may not find out about the error in a sub-routine until a long time after the code was originally written, not good.
Last edited:
I would also recommend taking a look at Micropython. It’s very similar to Python running on the Raspberry Pi, for example, but is designed for embedded applications. It is well supported by an enthusiastic community that is contributing to a rapidly growing list of library routines (GPS parser ext). The choice of compatible SBC is increasing, with the BBC Micro:Bit being quite popular and relatively low cost.
I agree assembly is very tedious thats why I used to use the convert to assembler in PE5 I could tweek the bits I needed to and if it bombed (it usually did) I just kept on banging away and usually got there even if just by process of elimination (Duh). I thought mpasm was dead in the water since mplab came along Microchip are not going out of their way to, help any enquiry takes you to MPLABX even when you find the right page they still keep redirecting to that monster! No wonder its X rated. I was unsure if Great Cow was cripple ware and ony allowed a few processors unless you subscribed not to mention chipaxe (the cheek) I'll give it a second look. I probably have come over as rather critical the picaxe system is great, considering it is really an educational tool it probably being used way past the origional design expectations.
kranenborg
Senior Member
In line with the statements by Goey and others, I think it is safe to say that there is no system that combines ease of use, versatility and support (both regarding support of the hardware modules in the PICAXE devices through appropriate BASIC commands, as well as the very active and friendly forum here) as the PICAXE system, at least when regarding applications that are not too resource-demanding. Therefore I think that one does best by really trying to implement a system with a PICAXE first, with help of the forum if needed.
However (and in response to srnet), when speed and/or complexity requirements in the end rule out a PICAXE, there is still one microcontroller system using BASIC one should have a look at that is extremely powerful, namely ZBASIC (www.zbasic.net). It is not well-known, but I am an active user of it as well. It supports a full Visual BASIC - based language (compiled) with a very advanced library of system utility functions extending it. Furthermore it supports multitasking with fine-grained task control, full Object-Oriented programming, it allows C-code or Asm code-inlining and even -for certain models - allows the use of Arduino-related library functions. It has a learning curve though (not surprisingly; the simplicity of the PICAXE allows to shield a lot of details at the expense of some advanced features) and is more expensive to use (the cheapest are the ZX-328L and ZX-328n at around 10$, showing how cheap picaxes actually are). Still, for very demanding applications it is extremely powerful and worth a look.
Even so, I use PICAXE in at least 75% of the cases because it allows prototyping so quickly and can be paired easily for distributed processing using serial comms. And they allow multitasking too!
However (and in response to srnet), when speed and/or complexity requirements in the end rule out a PICAXE, there is still one microcontroller system using BASIC one should have a look at that is extremely powerful, namely ZBASIC (www.zbasic.net). It is not well-known, but I am an active user of it as well. It supports a full Visual BASIC - based language (compiled) with a very advanced library of system utility functions extending it. Furthermore it supports multitasking with fine-grained task control, full Object-Oriented programming, it allows C-code or Asm code-inlining and even -for certain models - allows the use of Arduino-related library functions. It has a learning curve though (not surprisingly; the simplicity of the PICAXE allows to shield a lot of details at the expense of some advanced features) and is more expensive to use (the cheapest are the ZX-328L and ZX-328n at around 10$, showing how cheap picaxes actually are). Still, for very demanding applications it is extremely powerful and worth a look.
Even so, I use PICAXE in at least 75% of the cases because it allows prototyping so quickly and can be paired easily for distributed processing using serial comms. And they allow multitasking too!
Last edited:
I'm not being deliberatly dismissive all of the programming systems I have mentioned have value ,most of what I do is by current standards primitive. I first started using the programming editor with 16C84's about 13 years ago the software then did not support pauseus but I could easily tweek the pause subroutine to speed it up .More than a few lines of assembler and my brain would probably explode most of the time my pojects would fit in a 12F629,16F84 or a 16F819 the driving software for the rev ed pic programmer will not run on windows 7/8/10at least one of the exe files is 16 bit and will not run even in compatability mode ( unless someone knows better) MplabX is overkill and I was under the impression mpasm was dead in the water. I heartily agree pcaxe is great as is support on the forum I would not have posted this anywhere else for fear of being shouted down or being given the brush-off
Yep PE5 runs great on windows 10 (better than PE6 on mine) but the rev_ed programmer driving software will not it's only 16bit and I could not get it going even in compatability mode which was a pity most of the time I do just fine with basic it has more functions than I know what to do with but just occasionally I need to poke a half a dozen bytes . All I was wondering was there a way of using a bit of assembly without having to invest too much time in learning a whole new system.
I have recently bough a micromite and the serial terminal chip it works pretty much as a stand alone computer the terminal chip should go great with picaxe especially the 28x board. As for the micromite itself I know this is not a picaxe but I see it as akin-to than a competing system . I need to find out if there is an easy(ish) way of inserting bit of assembly language if there is it may be the way for me to go.
No need for special hardware, pure Web (nothing to install), connected : esp8266basic used with $5 NodeMcu
I tried running the 20M at 32 mHz but it wans'nt fast enough from what I understand the picaxe program is folded up inside the chip pretty tight (pretty miraculous to me how they do it) and with interpreting on top it's a small wonder anything gets done at all full marks to the designer. Having said that running at say 100mHz one of the X2 chips may do the trick the hserout/in command allows custom baud rates Spi and I2 may be less problematic. A bit of overcloking may make an interesting project in its own right, fan or water cooled? (Only kidding). I'm grateful for the input from all of the contributers I really was not expecting such a large response I wrote my original post after particularly fraught day on the microchip website iterspersed with failed attempts t get sense out of their programming software I probably found the answer but had been banging on so long I had forgotten the question. A bit of a natter helps put things back into perspective.
Having come back to micro controllers after a 15 year lapse I found the picaxe last September and for my robot interests seemed ok but then I wanted to use interrupts and picaxe is really an educational demo,You can't use it to say run 2 stepper motors because the main program is so slow. You can't draw lines on a lcd fast enough or load a 1K screen buffer at 50Hz frame rate. You can't get slow pwm unless you lower the setfreq. I did buy 8 picaxe chips though so not moaning. I found GC basic last November and it's like picaxe basic (gosub is sub,symbol is #define,high is set etc.) Good syntaxe checker 
all round good apple and does arduino chips..I think with same code.
Just trying freebasic on rpi,very nice,you have to compile 1st. Great to be able to write games that run fast. Pees all over python.. get a key press in python,try it. Just what rpi needed.
These are the programming choices I like,horses for courses.
If only picaxe inline asm was run as asm, not interpreted asm which is educashunal.
all round good apple and does arduino chips..I think with same code.Just trying freebasic on rpi,very nice,you have to compile 1st. Great to be able to write games that run fast. Pees all over python.. get a key press in python,try it. Just what rpi needed.
These are the programming choices I like,horses for courses.
If only picaxe inline asm was run as asm, not interpreted asm which is educashunal.
Last edited:
Yes The bear,the forum is great for lots of info and chat. You can talk about non RE items and stuff that's all related no matter the controller. I'm 63 but once you know what programming is it's how to implement ideas and what to use. There seems a loyalty thing to what people used first. Older people like basic,people 15 years younger use c because c was taught instead of basic.
Simple went out of favour when they realised normal people could program
Simple went out of favour when they realised normal people could program
Wow, you figured it out. I have been puzzled by how complex programming languages have become. I went all out to learn Python and am semi proficient at it but I can never do things the "Pythonic way", somehow the initiates can do things in 2 lines of code that takes me a page worth of code. I honestly think there is a little bit of a priesthood or a guild to programmers an effort to make simple complicated. The lack of arrays in Python is just plain silly, we are all used to arrays instead we have to learn Lists and tuples in Python. I have strayed to arduino, micromite and GCBasic and always return to the rock stable picaxe, it's an almost perfect product. I've noticed many members on this forum programmed assembly on the classic chips, Z80, 6502 and others of that generation. I loved Z80 assembly it was very logical and easy to use while programming a PIC chip in assembly is a massive hassle and the X IDE is so overblown.There seems a loyalty thing to what people used first. Older people like basic,people 15 years younger use c because c was taught instead of basic.
Simple went out of favour when they realised normal people could program
Jeremy Harris
Senior Member
This is a topic that comes up time and time again.
Essentially, Rev Ed make their (small) profit on the embedded interpreter. Over the years, lots of people have wanted the ability to use the Picaxe in standard interpreted form, then, for projects that need more speed, switch to exactly the same source code, but compiled and loaded to the chip, rather than interpreted.
At one point, I seem to remember that this was going to be a feature included in PE6 when it came out. Sadly it wasn't. I can understand the risk here, if you could use the incredibly useful and quick interpreted Picaxe system to develop and debug something, then just switch to buying cheap PICs from anywhere and programming them with the same source code, but compiled to PIC machine code, then Rev Ed would be giving away a valuable asset.
Now, I'm a great fan of Open Source, BUT, and it's a very BIG BUT, you simply cannot place trust in Open Source code. The classic example is the Arduino. To use it, you are almost wholly reliant on libraries that have zero provenance. You have no easy way of finding out what's in those libraries, whether they were competently coded, or even whether they contain malicious code. In general, the Open Source movement is a very good thing, but it is a bit of a free-for-all, and there's no real way (apart from effective peer pressure) to ensure the quality and integrity of the system you're using.
The great advantage of the Picaxe system is that is is robust, very well checked and from a source with a very good provenance. To me, that's important, but that doesn't mean that I wouldn't really appreciate some extras! Floating point, or at least signed integers, would be really useful (without having to use very clunky work-arounds, like the co-processor, or big hunks of complex math code). Having the ability to compile some parts of any code, so that speed-critical tasks could be run many times faster, with no loss of the inherent ease of use of the Picaxe system would be great.
BTW, having recently been playing around with the Raspberry Pi, I have to agree with the opinions stated earlier. Python is, quite simply, a PITA. And, just to put this in contest, my background was writing assembler with MASM, doing complex math with Fortran and a bit of playing around with other languages, from COBOL through to Pascal (and I have to say I never really got to grips with object-oriented programming).
Essentially, Rev Ed make their (small) profit on the embedded interpreter. Over the years, lots of people have wanted the ability to use the Picaxe in standard interpreted form, then, for projects that need more speed, switch to exactly the same source code, but compiled and loaded to the chip, rather than interpreted.
At one point, I seem to remember that this was going to be a feature included in PE6 when it came out. Sadly it wasn't. I can understand the risk here, if you could use the incredibly useful and quick interpreted Picaxe system to develop and debug something, then just switch to buying cheap PICs from anywhere and programming them with the same source code, but compiled to PIC machine code, then Rev Ed would be giving away a valuable asset.
Now, I'm a great fan of Open Source, BUT, and it's a very BIG BUT, you simply cannot place trust in Open Source code. The classic example is the Arduino. To use it, you are almost wholly reliant on libraries that have zero provenance. You have no easy way of finding out what's in those libraries, whether they were competently coded, or even whether they contain malicious code. In general, the Open Source movement is a very good thing, but it is a bit of a free-for-all, and there's no real way (apart from effective peer pressure) to ensure the quality and integrity of the system you're using.
The great advantage of the Picaxe system is that is is robust, very well checked and from a source with a very good provenance. To me, that's important, but that doesn't mean that I wouldn't really appreciate some extras! Floating point, or at least signed integers, would be really useful (without having to use very clunky work-arounds, like the co-processor, or big hunks of complex math code). Having the ability to compile some parts of any code, so that speed-critical tasks could be run many times faster, with no loss of the inherent ease of use of the Picaxe system would be great.
BTW, having recently been playing around with the Raspberry Pi, I have to agree with the opinions stated earlier. Python is, quite simply, a PITA. And, just to put this in contest, my background was writing assembler with MASM, doing complex math with Fortran and a bit of playing around with other languages, from COBOL through to Pascal (and I have to say I never really got to grips with object-oriented programming).
PE6 is still intended to include the capability, it has simply not happened yet. Unfortunately, as is the way with the world, other things come along and sometimes have higher priority. So still coming, but I am afraid I do not have any knowledge or estimate of when that will be.
Python is one of those love it or hate it languages; and sometimes both. I use it but have mixed feelings about it. I don't believe it's quite the 'novice-friendly language' some people make it out to be, it has some features which really go against that, but I do find it quite nice when code works. No programming language is perfect or perfect for everyone.
Pongo
Senior Member
Python lover here, I have to disagree with that
Firstly, let me say that I am an enormous fan of PicAxe. I love the entire ethos of the PicAxe 'System' from the programming environment to the programming interface on the chips themselves. If there was a way that Revolution Education could 'brand' their chips so that fully compiled code from their programming environment could only run on their chips (at full speed) I'd be in heaven. I love the code simulator, how it runs showing the progress of the program by highlighting the current command in the editor and by lighting the relevant pins on the virtual chip, even connecting to LCD displays and the like as well. It really is superb. Sadly, for a large number of projects I have, the interpreted code can't run fast enough and the interpreter can occupy valuable code space on the chip, therefore I've been looking for something that is simple to use with greater flexibility.
My vote is another for GreatCowBasic. I find that it has a flow that fits within my head's own limited code space. I write the code in the editor, compile it, download it into the chip using MpLAB IPE (NOTE: I.P.E, Integrated Programming Environment, not the full, bloated, incredibly confusing [for me] IDE) and an inexpensive PicKit clone, done. Granted I've yet to find a simulator of any sort that is useable [or simple enough for me to follow what the heck it is trying to tell me] in any way, but apart from that I have started to move all my current and future work projects to Marvellous Moo Basic, and no longer intend to start any home projects with PicAxe.
It isn't just the raw speed of compiled code that is giving me the impetus to change, it is the lack of support for the Mac {no simulator for the Mac unless I run the PicAxe editor in a WINE environment, which is rather unstable} which negates the main advantage that the simulator gives to PicAxe.
There is all that code space too! Using either a 16F1829 or 16F1825 means that they are a near 'drop in replacement' for a 20M2 or 14M2 and I've used them directly in PCB's designed for the PicAxe versions. A one thousand+ line basic program once compiled for the 16F1829 [20M2] consumes just 52% of program space, twenty variables with two arrays, five words and thirteen bytes takes up just 10% of the variable space.
The forum for the Moo basic is very helpful, I've spotted one or two people from here over there, the language is being updated regularly and there are plans to add floating point arithmetic.
I still have nothing but praise for PicAxe. Without it I'd never have got into microcontroller programming. I, like Jeremy, have progressed through languages from Sinclair Basic, BBC Basic, COBOL, OPL (Psion Organiser Programming Language.), EPOC (16bit version of OPL.), Visual Basic (Yuk! For almost every version I ever tried.), Delphi (Object orientated PASCAL - I loved Delphi, my network capable spreadsheet and spell checker written in Delphi are the programs I'm most proud of.), PicAxe Basic and finally GCBasic. I would most happily go back to Delphi (The last version by Borland, before Imprise, Embarcadero et. al. took over.), but my current job requires me to program microcontrollers, not PC's so GCB it is.
My vote is another for GreatCowBasic. I find that it has a flow that fits within my head's own limited code space. I write the code in the editor, compile it, download it into the chip using MpLAB IPE (NOTE: I.P.E, Integrated Programming Environment, not the full, bloated, incredibly confusing [for me] IDE) and an inexpensive PicKit clone, done. Granted I've yet to find a simulator of any sort that is useable [or simple enough for me to follow what the heck it is trying to tell me] in any way, but apart from that I have started to move all my current and future work projects to Marvellous Moo Basic, and no longer intend to start any home projects with PicAxe.
It isn't just the raw speed of compiled code that is giving me the impetus to change, it is the lack of support for the Mac {no simulator for the Mac unless I run the PicAxe editor in a WINE environment, which is rather unstable} which negates the main advantage that the simulator gives to PicAxe.
There is all that code space too! Using either a 16F1829 or 16F1825 means that they are a near 'drop in replacement' for a 20M2 or 14M2 and I've used them directly in PCB's designed for the PicAxe versions. A one thousand+ line basic program once compiled for the 16F1829 [20M2] consumes just 52% of program space, twenty variables with two arrays, five words and thirteen bytes takes up just 10% of the variable space.
The forum for the Moo basic is very helpful, I've spotted one or two people from here over there, the language is being updated regularly and there are plans to add floating point arithmetic.
I still have nothing but praise for PicAxe. Without it I'd never have got into microcontroller programming. I, like Jeremy, have progressed through languages from Sinclair Basic, BBC Basic, COBOL, OPL (Psion Organiser Programming Language.), EPOC (16bit version of OPL.), Visual Basic (Yuk! For almost every version I ever tried.), Delphi (Object orientated PASCAL - I loved Delphi, my network capable spreadsheet and spell checker written in Delphi are the programs I'm most proud of.), PicAxe Basic and finally GCBasic. I would most happily go back to Delphi (The last version by Borland, before Imprise, Embarcadero et. al. took over.), but my current job requires me to program microcontrollers, not PC's so GCB it is.
Last edited:
My thoughts are akin to tmfkam's. I thought python was a bad choice for the RPi it being created initially for educational use,that and using linux. PE6 on linux and picaxe is no longer simple,yeah? RPi relies on 3rd party,open source libraries. Usually you compile the source code so can check it for malicious code.
z80/6502-9 too much hardware for say a robot.
If I had a RE or compatible pic programmer could I use pe5 to convert basic to asm and write to pics?
Microchip xlab is for pickit3 and the newer pics which pickit 2 won't work with so you must buy pickit3...from China on ebay,fnarr!
z80/6502-9 too much hardware for say a robot.
If I had a RE or compatible pic programmer could I use pe5 to convert basic to asm and write to pics?
Microchip xlab is for pickit3 and the newer pics which pickit 2 won't work with so you must buy pickit3...from China on ebay,fnarr!
Its probably because we are (mostly) free-thinking animals, that there are so many different programming languages. The surprise to me is that there are only a few hundred. If we all had the necessary skills to create our own, there would be hundreds of thousands.
It's not that there is necessarily anything basically wrong with a given language. Its just that its authors see things differently to its critics. And of course we tend to seek out and cluster around those that have similar views to our own.
Incidentally, I'm not a fan of Python in an educational context as the next step up from Scratch, as I've found myself trying to justify why code written to Python3 standard does not run under Python2 (and vise versa). But the idea that I am right in my assumption that Python is rubbish, when it occupies a position in the top 5 most popular languages, is laughable. I can sit in a deck-chair like King Canute, but will surely be trampled to death by a hoard of spotty Computer Science graduates!
In an industrial product development environment, you would not stick to a single hardware platform, a single OS, and a single programming language, unless you were limited by the abilities of your development team.
I'll take a guess that the contributors to this thread are not commenting on the limitations of Picaxe relating to the Educational sector. Just like me (with regards to Picaxe & RaspberryPi) you are not part of the primary target market.
So my view is that RevEd should (and probably does) concentrate on the needs of the Education sector, while us hobbyists should spread our wings by selecting the right technologies to suit our projects and our capabilities.
The original post by bag57pipe (who appears to be of a similar fine vintage to me) may have been fueled by frustration, but identifies a problem we all face from time to time: how can I do this with the tools and knowledge I have at my disposal?
It's not that there is necessarily anything basically wrong with a given language. Its just that its authors see things differently to its critics. And of course we tend to seek out and cluster around those that have similar views to our own.
Incidentally, I'm not a fan of Python in an educational context as the next step up from Scratch, as I've found myself trying to justify why code written to Python3 standard does not run under Python2 (and vise versa). But the idea that I am right in my assumption that Python is rubbish, when it occupies a position in the top 5 most popular languages, is laughable. I can sit in a deck-chair like King Canute, but will surely be trampled to death by a hoard of spotty Computer Science graduates!
In an industrial product development environment, you would not stick to a single hardware platform, a single OS, and a single programming language, unless you were limited by the abilities of your development team.
I'll take a guess that the contributors to this thread are not commenting on the limitations of Picaxe relating to the Educational sector. Just like me (with regards to Picaxe & RaspberryPi) you are not part of the primary target market.
So my view is that RevEd should (and probably does) concentrate on the needs of the Education sector, while us hobbyists should spread our wings by selecting the right technologies to suit our projects and our capabilities.
The original post by bag57pipe (who appears to be of a similar fine vintage to me) may have been fueled by frustration, but identifies a problem we all face from time to time: how can I do this with the tools and knowledge I have at my disposal?
Jeremy Harris
Senior Member
That's something to look forward to then, thanks.
It's not that often that the extra speed of compiled code is useful, but I've had a few projects where it would have been a real boon. I did manage to get around the speed limitations of the Picaxe interpreter in one application, by using an 08M2 to do the "fast stuff", all on it's own, and then pass the data to the main Picaxe for the slower stuff. That was decoding and using the HomeEasy/Byron home automation protocol, where a Picaxe could "just" capture the 32 bits OK at 32 MHz, as long as it wasn't trying to do anything else. You may recall the thread (http://www.picaxeforum.co.uk/showthread.php?23007-HomeEasy-Byron-433MHz-RF-decoding-with-a-Picaxe ), hippy, as you contributed very helpfully to it.
In the final system I dedicated an 08M2 to just capturing the data and sending the code back to another Picaxe that did the "heavy lifting". It's an approach that I've found works well. It's often a lot easier to use two or three smaller Picaxe chips in a project, than try and get things done with one. Apart from anything else it makes testing the code in each a lot easier, and it can be cost-effective, too. It also allows true multitasking in a project, and sometimes that's handy even in a simple project. Some may recall my radio link controlled chicken coop door. That now has a second 08M2 that reads a local RFID reader, so I can open and close the door without going indoors and using the remote - I just swipe the RFID tag from my keyring over it and it activates. This works because both 08M2s are waiting for serial data, so "stuck" in effect. The latching relay that drives the door actuator is just diode OR'd to both Picaxes, so either can activate it.
Last edited:
In my first post last September I said how impressed I was with picaxe. 16 years ago I thought it was just educational,same with stamp. The fact that both are still around for new users is interesting with all the choices that have come later.
In the uk,schools,uni,open uni don't teach basic or pascal it's c++, if programming is/ever was taught in schools. Would you apply for a programming job if you weren't competent with c. COBAL programmers are probably still wanted.
From a modern technology point err..8 bit is 80's, it's all 32 bit these days but I can't see me coding the registers in the broadcom quad core RPi processor anytime just using the pins on the board is enough for me.
Picaxe would be even better if inline asm worked and you needed speed.
Processors are just a bit of fun for me,it's nice there's plenty of choice nowadays and hardware's cheaper and much more info available.
I was mislead about the term "compiler" when I bought into picaxe thinking it was different to stamp.
In the uk,schools,uni,open uni don't teach basic or pascal it's c++, if programming is/ever was taught in schools. Would you apply for a programming job if you weren't competent with c. COBAL programmers are probably still wanted.
From a modern technology point err..8 bit is 80's, it's all 32 bit these days but I can't see me coding the registers in the broadcom quad core RPi processor anytime just using the pins on the board is enough for me.
Picaxe would be even better if inline asm worked and you needed speed.
Processors are just a bit of fun for me,it's nice there's plenty of choice nowadays and hardware's cheaper and much more info available.
I was mislead about the term "compiler" when I bought into picaxe thinking it was different to stamp.
Last edited:
techElder
Well-known member
The word "mislead" is a bit harsh given what we all know about the PICAXE system.
I keep reading words about "not fast enough" or even "slow", but every project doesn't need speed. I'll even go out on a limb and say very few projects really need the speed.
I'm impressed by the PICAXE's ability to just chug along and get things done.
Sometimes speed is just marketing hype.
I keep reading words about "not fast enough" or even "slow", but every project doesn't need speed. I'll even go out on a limb and say very few projects really need the speed.
I'm impressed by the PICAXE's ability to just chug along and get things done.
Sometimes speed is just marketing hype.
It all depends on the type and requirements of the projects you do.
In my case the majority of my new projects do need more speed than Picaxe can provide. So I use something else. However, if speed is not required then I certainly may use a Picaxe.
I would agree with Texasclodhoper that "few projects really need the speed" , but only in the context of educational and hobby stuff and possibly some light commercial stuff. The embedded world extends far beyond the users here.
The vast majority of industrial and commercial stuff does require "speed" not afforded by interpreted Basic.
In my case the majority of my new projects do need more speed than Picaxe can provide. So I use something else. However, if speed is not required then I certainly may use a Picaxe.
I would agree with Texasclodhoper that "few projects really need the speed" , but only in the context of educational and hobby stuff and possibly some light commercial stuff. The embedded world extends far beyond the users here.
The vast majority of industrial and commercial stuff does require "speed" not afforded by interpreted Basic.
I didn't know the picaxe's capabilities at first, I just thought, having used a pic basic compiler that it ran asm and it did say in line asm some where. For robots with pauses for the sensors to settle speed is fine but try running 2 unipolar stepper motors continuously and a program to do the rest doesn't work-I've tried.The main program runs like in the simulator on slowest. Edmunds project could do with a speed boost it seems.
You couldn't turn a lcd into a simple oscilloscope, I tried that, 1.5S to plot a sine wave from a table. But who does these things like build lcr meters?
Forum members say just use a dedicated picaxe or a 555 for the donkey work. I got a 15 year old 16f84 robot board that uses interrupt "software pwm" for the motors and contains the robot program but uses a 12f08 whatever for 32khz IR,which is legit use,couldn't fit on 1 pic but then I got a 16f876 which kicked bottom.
I think I'll get an arduino board to play with and use gc basic to program it. Stuff is so cheap nowadays. I bought a lcd lcr esr component tester for £5 and there's oscilloscope kits for £8 so why bother? I thought of making a lcd mp3 stereo bargraph but I got winamp on my phone.
You couldn't turn a lcd into a simple oscilloscope, I tried that, 1.5S to plot a sine wave from a table. But who does these things like build lcr meters?
Forum members say just use a dedicated picaxe or a 555 for the donkey work. I got a 15 year old 16f84 robot board that uses interrupt "software pwm" for the motors and contains the robot program but uses a 12f08 whatever for 32khz IR,which is legit use,couldn't fit on 1 pic but then I got a 16f876 which kicked bottom.
I think I'll get an arduino board to play with and use gc basic to program it. Stuff is so cheap nowadays. I bought a lcd lcr esr component tester for £5 and there's oscilloscope kits for £8 so why bother? I thought of making a lcd mp3 stereo bargraph but I got winamp on my phone.
Jeremy Harris
Senior Member
Worth looking at the "multiple Picaxe" approach I mentioned above. You gain speed and a great deal more programming flexibility if your application lends itself to splitting tasks out into discreet blocks that can each do just a part of the main task.
Some may recall that one of my longer term projects is to replace all the time switches in our new house with a central control that transmits on and off codes to RF controlled switch modules. That way I can have one master clock and that master clock can automatically adjust for the BST/GMT switch twice a year (daylight saving time for those outside the UK). I was going to use an MSF receiver, but try as I might I cannot get a reliable MSF signal here, even after investing in some of the nicer Canadian receivers, the ones with better sensitivity and a longer ferrite antenna. For some reason GPS gets through fine, so I've built a master clock that around a cheap Ublox GPS module, an 08M2 to handle the GPS data handling and conversion from UTC to BST at the right times, and that passes serial data to a 14M2 that runs a display in 4 bit mode and a DS1307 real time clock as a half hourly updated master clock.
The point here is that by using two Picaxes, a relatively cheap 08M2 to do all the time data collection and manipulation, once a second, and a separate display and date and time data output Picaxe, I've got around the problem of one Picaxe not being fast enough. With two Picaxes, there is plenty of time to spare between GPS data bursts to do a lot more, so I'm actually sending out far more data from the master clock serial output than I could have done with just one. That then adds versatility, as it allowed me to send ASCII data as well as binary data, so anything downstream can just pick direct ASCII date and time to use in a display, for example, or use the raw binary to use in my "master programmable timer" unit. I can also use the master clock data to run the house data logger, rather than rely on an internal DS1307 that needed resetting from time to time, either because of the BST/GMT thing or because of gradual drift.
Anyway, before switching to another microcontroller system, can I suggest just looking at whether a multiple Picaxe approach might just solve the problem?
"Anyway, before switching to another microcontroller system, can I suggest just looking at whether a multiple Picaxe approach might just solve the problem?"
What you've done makes sense. Nice though if the timer event,or pin interrupt event didn't slow the main program to pointless like checking 2 slotted wheels from pin interrupts or run 2 stepper motors. The m picaxe are supposed to be able to run 2 programs at once ,they do and don't. Yes I could use a chip with 10 spare pins for a stepper motor and serial which I don't understand,just use it.
The thread title was What next? and if I can't do something with this I'll use that. My options are only Basic. I've tried c. I can start to use my RPi now I found freebasic. Python and linux script...who makes up all those stupid words and thought it clever to use every symbol on the keyboard to print "hello world". Guess what this rpi code means- fulload() { dd if=/dev/zero of=/dev/null | dd if=/dev/zero of=/dev/null | dd if=/dev/zero of=/dev/null | dd if=/dev/zero of=/dev/null & }; fulload
What you've done makes sense. Nice though if the timer event,or pin interrupt event didn't slow the main program to pointless like checking 2 slotted wheels from pin interrupts or run 2 stepper motors. The m picaxe are supposed to be able to run 2 programs at once ,they do and don't. Yes I could use a chip with 10 spare pins for a stepper motor and serial which I don't understand,just use it.
The thread title was What next? and if I can't do something with this I'll use that. My options are only Basic. I've tried c. I can start to use my RPi now I found freebasic. Python and linux script...who makes up all those stupid words and thought it clever to use every symbol on the keyboard to print "hello world". Guess what this rpi code means- fulload() { dd if=/dev/zero of=/dev/null | dd if=/dev/zero of=/dev/null | dd if=/dev/zero of=/dev/null | dd if=/dev/zero of=/dev/null & }; fulload
And also worth analysing whether it's the PICAXE which is not up to the task or if it is the algorithm used or a less than optimal implementation or design which is slowing things down.
There are things beyond a PICAXE's capabilities or not suited to it, as will be the case for all computer systems, but careful algorithm design and optimisation can often save the day.
Bit-banged steppers will be fairly slow, simply because of the amount of work which has to be done just to get one revolution out of a stepper. That said a single 4-phase per step stepper can be bit-banged at 2000 steps per second, 1200 RPM. Slap a 12" diameter wheel on that and it will disappear off the bench at over 40 MPH. A more sensible 2" wheel will give around 7 MPH.
For an LCD display, a full 1K of scratchpad bytes can be output in 35ms at 32MHz using HSPI so acceptable frame rates should not be impossible but will depend on how quickly one can create the data to be output.
Seriously. I have the same question now when I'm trying to understand more C code because of different Arduino and ARM implementations of navigation. It is like you cannot type it without a character map open. Why on the planet do you try to make things more complex than they have to be? So they look cool and sophisticated? I don't see that in the example above
.Have fun,
Edmunds
Last edited:
All programming languages are a mystery unless one understands the syntax and semantics. I am not overly familiar with 'bash script' but I think ...
Code:
fulload() { .... }
Code:
fulloadAs to the command ...
Code:
dd if=/dev/zero of=/dev/nullThe | are pipes from one into another which in this case I guess, because there are four commands, and run on a four core processor if a Pi 3, uses all cores. The & causes it to run in the background so a command prompt is returned to once those commands are all running.
I would guess it's intended to utilise all cores of the processor 100%. Probably a heat test given the issues people have had with Pi 3's getting hotter than is desirable.