Does anybody now how many clock cycles it takes for an instruction to be executed by a picaxe? Does it vary depending on the type of instruction?
Since a PICAXE is a PIC, it
Since a PICAXE is a PIC, it takes 4 instruction cycles, so MIPS= Clock freq/4
Thank you 
Thank you. But then i’ve got another question. I’ve heard that using an in-chip basic(programming language) interpreter makes the program slower than if you were programming in, for example, assembly. But how can this be true if, as it appears from your answer, speed is only chip-dependant?
That clock speed / 4 works
That clock speed / 4 works only if you use assembler. If you use some freacky higher level thingy then… it is hard to detect…
Ahh ok got it. But is there
Ahh ok got it. But is there a way to obtain higher speeds? For example: why does the PICAXE need to have a basic interpeter? Couldn’t you have a program which converts your basic program to something like assembly and THEN transfers it to the chip so that it does not need an on-board interpreter?
That’s excactly what the
That’s excactly what the Picaxe editor does
However, the code can never be as “clean” as if you write it all straight in assembly.
I really wonder what all those speed issues are about?
Sure, I have space & speed issues all the time, that’s what all the fun is about. I program my way out of it. Have you posted the project that is so speedy-needy somewhere tuna? Maby I can help with the code?
Here’s my story: (sounds
Here’s my story: (sounds like one of those conventions where people talk about their problems related to alcohol :D)
It all started when i tried this https://www.robotshop.com/letsmakerobots/node/7075
It was a test for a laser tag project, not for a robot. I agree about what you say about speed issues on robots, a picaxe running with a 4MHz resonator is more than enough, imagine one running at 64MHz (16MHZ resonator on a 28X2)! But since in this laser tag project i need speed, that’s why i was worried.
Basically the brain in this project has to do this:
-“shoot”, which means do the SEROUT so that the IR LED sends out the signal
-receive SERIN, which are “bullets” from another players
-send signals to the ISD chip to play sounds
For this reason i need the chip to be fast. Say you are shooting, and during this the enemy fires at you. The chip has to be fast enough to understand that someone is shooting at you (which means activate the interrupt), receive the “bullet” (which is going to SERIN mode) and switch to firing mode as quickly as possible, and if possible mantaining the right firing frequency (for example 5 bullets per second).
Maybe an X2 at 64MHz is more than enough, but i get frustrated when i read that bare PICs or AVRs can run much higher (which is not an issue for the kind of robots i make, but it is for this project)
As I understand this, there
As I understand this, there is no doubt; You wil need 3 MCU’s, since you are dealing with multitasking and chips that does not do multitasking:
One to control out, one to control in, and one to decide.
The in & out’s can be tiny 08’s, and they set pins high or low to the mother-chip. The mother does not need to be fast at all, it can just take it easy and see what the guys says, and take action needed.
This way 2 things can happen at the same time. But of course one came before the other, and the mother-MCU will know which one, because it is reacting fast, just listening to the 2 in the main loop.
(Did not read your original posting or any comments, do not have enough time, it looked so long
True :)I also hate long
True
I also hate long posts, but the problem is that i also MAKE them!
I though about having more than one chip on the board. In fact i have ordered a bunch of 08Ms and two 28X2 to do some testing. But the problem with the post i linked still exist. Basically this is the problem : takes too much time to switch from the interrupt to the SERIN. But anyway, i’ll try out the higher speed ones and then compare the results tomorrow.
Hmm… Perhaps we should
Hmm… Perhaps we should Skype about this, would be faster.
I like the multiproc idea
I like the multiproc idea that fritz had, and as I usually complicate things here is my idea on this.
use 3 procs, one for each point that will be a serin_proc. use another(4th) for serout and 5th to tie it all together.(alternativly, since the 4th doesn’t have much duty and may have a lot of room on board, you could use it as the brain that ties it all together as well)
use the 3 serin_procs and record data to a mem chip or to the internal memory(very limited though).
4th one is the trigger chip, no worry about having to do any work. 5th chip is the brains. it would be used to interface all 3 of the serin chips and get the data from each one. This could be output a serial input somehow.
the seudo code for the serins_procs would be something like
startup wait for 5 seconds for input from the brain (blink an led during this process?).
if input is triggered wait for further instructions.
if no trigger go into record (action, game, whatever you want to call it)mode.
set your interrupt for 2 input pins, one from the brain and one from the ir sensor.(the brain int is a secondary way to tell the serin_proc that it will be getting new instructions, like a reset or something.)
The 4th chip, we’ll call fire_control will have the trigger fire control, autoshot, and single shot modes, plus it would have the code to retreive data from the serin_proc chips. You would also have a setup mode on this one that would let the serin_procs know to wait for the instruction to do whatever you need with the data(reteive, delete, other). When you do a retreive , you would then pipe this data through the brain to whatever setup you have(serial port using something like processing to communicate).
Anyway, this is my semi complicated solution…
The microcontroller itself
The microcontroller itself operates at Fosc/4. Your program language may use several instruction cycles to do one of its cycles, but the MIPS of the actual PIC is still Fosc/4.
this is similar to one of my
this is similar to one of my layouts. I have made several of them:
-using 4 chips, one per input area, and another one for the rest (which is kind of similar to yours)
-using one chip with interrupts for all the 3 sensor areas and one for the rest (similar to frits’s)
-using 1 chip
I guess i’ll be discarding the last one and proceed with the other two. I may stick with the interrupt version IF 8MHz gives me a high enough switching speed (between interrupt and serin) or may try going as high as 64MHz. If i don’t get good enough results i will go for the one-chip-per-sensor-zone version. Well, i think it’s testing time!
btw: looks less complicated than having one chip do everything, unless this chip is a propeller (but then i have no SPI support for the ISD chip and no on-board ADC sampler)
Ok…so it appears that the
Ok…so it appears that the slow speed of the picaxe is related to the language i’m using, or kind of… thanks!
Hey check this
Hey check this out: http://www.rev-ed.co.uk/docs/AXE001_bas2ass.pdf
This basically converts your basic program into assembler and then uploads it to a blank pic via a programmer. I believe there is difference between using the standard picaxe programming editor and this, but i’m not sure about it. Would it make it faster somehow?