Run out of horse power - Any ideas ?

[Tim036]

This is a worse case scenario.

The fastest Picaxe is to slow, and its going to be a large program.

Are there any really fast Pics around ? Factor of 5 to 10 faster than the 65Mhz clock one?

What technology could I migrate to ?

Please tell me a Big very fast Picaxe chip is about to/Just has been released.

Any thoughts very very welcome !



Tim

 

[Dippy]

Are you sure PICAXE is too slow?
Could it be your coding technique , electronic design or something else?
Without details we'll have to rub our C Balls like fury.

If you want faster then you'll have to part with some money.
How's your C ?
Or, if wanting to stay with BASIC/PASCAL, how conversant are you with actual setting up a PIC. All that TRIS and ADCONx and ANSELx and all that detailed PIC stuff?
You will need to read PIC Data Sheets in detail if you want the best out of a compiler.

I'm not going to advertise any here, but I found a certain compiler (beginning with "Mik") to be pretty poor compared to other makes. In C, PASCAL and BASIC. That was 2 years ago, so hopefully they've improved. I know Wolfgang likes them but I didn't.

 

[MartinM57]

I guess what you mean is that the interpreted nature of PICAXE basic is too slow for whatever it is (what is it?) you are trying to do?

A native 64MHz PIC is a pretty fast beast - it's just a bit crippled by giving you a fantastic BASIC-like language with high level constructs and a dev environment that make everything dead easy for you.

Migration path (if there is absolutely no alternative to redesigning/thinking out the box on a different PICAXE-based solution) is, in order of ease, something like:
- a commercial BASIC compiler on a native PIC/AVR
- an Arduino-based system (Google it if you've never heard of it)
- a C compiler on a native PIC/AVR
- a C compiler on an ARM Cortex M3
- etc

It will cost GBP to get into those leagues, a lot of time investment and some good skills - you'll maybe get in the order of 100x the performance though?

 

[Dippy]

Before you start splashing out, it would be a good idea to check the spec of the target micro.
e.g. some ADCing is significantly faster than others....

'Ardweenies are very popular but check the spec and prices.
A PIC or dsPIC will give you more of bang for your buck unless you wish to go ARM+C (and similar) direction. All the Big Boys make micros and there are some terrific specialist ones. All I can suggest is learn the basics of C and then you'll have a handle on all of them.

So: Look before you leap.
I'm not sure this is the best place to start asking detailed qustions about non-PICAXE products ??

 

[hippy]

Many micros have a native execution speed greater than the PICAXE interpreter delivers but once you start to do something with them you can find the speed gain is a lot less than may be expected.

The micro still has to execute the same sequence of instructions to achieve what a PICAXE command does, the gain is in not having to decode the commands, the downside is usually larger memory required. As noted, some compilers may generate pretty inefficient code which lose some of the potential advantages. It all depends on what the program does, what commands are required.

The PICAXE can often 'fight above its weight' by utilising on-chip hardware or through clever coding techniques. When fast speed is of the essence there are alternatives; an XMOS chips delivers 400MHz performance and will outpace most of the competition.

 

[Tim036]

Before you start splashing out, it would be a good idea to check the spec of the target micro.
e.g. some ADCing is significantly faster than others....

'Ardweenies are very popular but check the spec and prices.
A PIC or dsPIC will give you more of bang for your buck unless you wish to go ARM+C (and similar) direction. All the Big Boys make micros and there are some terrific specialist ones. All I can suggest is learn the basics of C and then you'll have a handle on all of them.

So: Look before you leap.
I'm not sure this is the best place to start asking detailed qustions about non-PICAXE products ??

I have tried to learn C before and gave up. I got 'Hello World' to the printer/screen and that was where I stopped.

Prefer assembler or even Machine Code.

Sorry I know its OT but I'm struggling. No A to D involved just fast switching,

Many thanks for the tips - keep them coming !

Basic is so easy and makes Pics a joy to programme using Picaxe technology.



Tim

 

[MartinM57]

Sorry I know its OT but I'm struggling. No A to D involved just fast switching,

So you obviously don't want to reveal the trade secret of the device that will make you a multi-billionaire by next year - but there are some bright people here that, given a bit more info, might be able to suggest PIACXE'able designs...or agree that you're quite right and the PICAXE is way out of the league you need...

 

[hippy]

Sorry I know its OT but I'm struggling. No A to D involved just fast switching,
Many thanks for the tips - keep them coming !

It will be far easier to offer suggestions or solutions with some better information on what's actually required. How fast is this switching, how frequently, what latency / response time must be achieved.

 

[tiscando]

PIC assembler

I started getting into reading PIC manuals looking into the anatomy of the PICAXE, and then thought about using a PIC12F683 in an application too fast for a PICAXE, basically a frequency-controlled square wave back-shifter which back-shifts a square-wave up to 8kHz depending on its frequency itself.

I first used non-microcontroller components to try and accomplish this, but then I thought I could program a Pic12f instead, which would be a 3rd of the size. I started looking at the assembler instruction set, which is when I started programming assembler in PE. It took time finding out all the registers which need to be initialised, but it was worth it.

Once I brought a Bas800 pic programmer, some PIC12F683 ICs and 20MHz oscillators, I started off slowly with a button controlled LED flashing program which worked perfectly second time after realising CLRWDT is required to pat (reset) the watchDOG timer, which is useful in case the PIC crashes when it will reset it and get it working again.

Next, I invented and tested a robust bitbang-serin and serout assembler code snippets, and used them in a serial computer control terminal program where a computer sends serial commands to the PIC to modify PIC variables, which took time but worked very well. Then I looked into the EEPROM registers in the datasheet and found out how to read from and write to the EEPROM to save the serial modifiable variables to.

Finally, I decided on which perhipherals to use, which was the CCP in compare mode, with its output as the output of the square-wave shifter, and Timer1 with gate control, where the gate is the input of the square wave shifter, which triggers the CCP output and measures the period of the incoming square wave. I then developed the calculation routine which is determined by the serial-adjustable variables.

Once two of them, both clocked by one standalone 20MHz oscillator, are inline with a brushless motor commutation circuit, they are of real benefit to the speed and efficiency of an optical-sensored syncronously-commutated stepper motor.


I hope this gives you an idea of the PIC assembler route. The PIC12F683 is actually a very powerful 8-pin PIC.


PS if you want the EC osc functionality, there was a bug in the Picdef.ini setup which prevents EC-osc from being selected in the PIC programmer, even when the PIC selected supports it. I have attached this as a txt. In \Program files\programming editor\picprog, remame the existing picdef.ini to picdef_o.ini, open the picdef.txt attachment in notepad, and save to the \picprog folder as 'picdef.ini'. In here, I just simply copied each 'EXTCLK' directives, renaming each copy as 'EC'. The programmer recognises EC, but not EXTCLK. It should say it is modified by TCD.
One catch though is it still doesn't allow PE to program the EC bit, so I have to open the PIC Programmer software after I have programmed the IC using PE, load the HEX file, select the EC button, uncheck the program and data boxes, leaving the configuration box checked, and program this configuration.

EDIT: the assembler templates (file - new - template) help a lot in starting an assembler program.

I hope this makes sense.


PSS the assembler complier doesn't like filenames including their paths longer than 63 characters, or, another problem I've encountered, filenames with dashes in them.

Definitions like PORTA are case sensitive. Also see http://www.picaxeforum.co.uk/showthread.php?t=11572&highlight=mpasm for more information, and the manual, on assembler code. I hope you find this useful.

 

[Tim036]

I started getting into reading PIC manuals looking into the anatomy of the PICAXE, and then thought about using a PIC12F683 in an application too fast for a PICAXE, basically a frequency-controlled square wave back-shifter which back-shifts a square-wave up to 8kHz depending on its frequency itself.

I first used non-microcontroller components to try and accomplish this, but then I thought I could program a Pic12f instead, which would be a 3rd of the size. I started looking at the assembler instruction set, which is when I started programming assembler in PE. It took time finding out all the registers which need to be initialised, but it was worth it.

Once I pur(r)CHASEd a Bas800 pic programmer, some PIC12F683 ICs and 20MHz oscillators, I started off slowly with a button controlled LED flashing program which worked perfectly second time after realising CLRWDT is required to pat (reset) the watchDOG timer, which is useful in case the PIC crashes when it will reset it and get it working again.

Next, I invented and tested a robust bitbang-serin and serout assembler code snippets, and used them in a serial computer control terminal program where a computer sends serial commands to the PIC to modify PIC variables, which took time but worked very well. Then I looked into the EEPROM registers in the datasheet and found out how to read from and write to the EEPROM to save the serial modifiable variables to.

Finally, I decided on which perhipherals to use, which was the CCP in compare mode, with its output as the output of the square-wave shifter, and Timer1 with gate control, where the gate is the input of the square wave shifter, which triggers the CCP output and measures the period of the incoming square wave. I then developed the calculation routine which is determined by the serial-adjustable variables.

Once two of them, both clocked by one standalone 20MHz oscillator, are inline with a brushless motor commutation circuit, they are of real benefit to the speed and efficiency of an optical-sensored syncronously-commutated stepper motor.


I hope this gives you an idea of the PIC assembler route. The PIC12F683 is actually a very powerful 8-pin PIC.

That is most useful ! May have to follow the same route.

Many many thanks.

: )

Tim

 

[tiscando]

That is most useful ! May have to follow the same route.

Many many thanks.

: )

Tim

Your welcome
Migrating to assembler should give you at least 10x faster processing for a 20MHz PIC than a 64MHz PICAXE, if not a lot more than that, plus a greater flexibility.

 

[MartinM57]

Personally I find the PIC archirecture non-intuitive for some reason - my other life is with Atmel ATMEGA AVRs in assembler and they seem very straightforward to me. It's just familiarity I suppose...

 

[Dippy]

True. Quite a few people moan about PICs. Frankly, though, 99.99% of people needn't worry about it.

 

[Janne]

Personally I find the PIC archirecture non-intuitive for some reason - my other life is with Atmel ATMEGA AVRs in assembler and they seem very straightforward to me. It's just familiarity I suppose...

Same here.. Also the free C-compilers for AVR seem to be much better than for pic's.

Though I nowdays use the AVR quite much, i find that picaxe still has plenty of uses.. For a simplistic task, you can have your project up and running in under an hour with picaxe, not something that at least i can achieve with plain AVR's.

 

[Chavaquiah]

my other life is with Atmel ATMEGA AVRs in assembler and they seem very straightforward to me.

I also tend to use mostly AVRs these days. Although I program them in C most of the time, I particularly like their assembler instruction set.

At the start it was not so easy, though. Stuff I could do with one simple BASIC line in Picaxe required writing full libraries for the AVR and delving through hundreds of pages worth of datasheet stuff.

Not to mention how you can get a full prototype built with a Picaxe for less than the price for just an AVR programmer...

Anyway, much as I like Atmel AVRs, I still tend to use Picaxes to test new components or to start simpler projects. The programming environment is superb. I also discovered that the relatively lower execution speed doesn't prevent me from doing most of the tasks. It just makes me think a little bit harder about how to write better code.

 

[tiscando]

Though I nowdays use the AVR quite much, i find that picaxe still has plenty of uses.. For a simplistic task, you can have your project up and running in under an hour with picaxe, not something that at least i can achieve with plain AVR's.

I still use the PICAXE for tasks which it can do and where speed is not too important, such as for a clock. It is easy to program especially where menus are required, which would be too complicated to program in assembler. But I could program PICs which can be controlled by PICAXEs and do functions a PICAXE cannot do, such as two-lane serial where the clock signal is also bidirectional , PS/2 keyboard host and some other weird bit-intensive stuff like this, therefore acting as external PICAXE perhipheral PICs.

Although I might prefer AVR's 1 MIPS per MHz efficiency, compared to 4 clock cycles per instruction for PIC, when I start university in 2 or 3 years.

 

[Tim036]

I still use the PICAXE for tasks which it can do and where speed is not too important, such as for a clock. It is easy to program especially where menus are required, which would be too complicated to program in assembler. But I could program PICs which can be controlled by PICAXEs and do functions a PICAXE cannot do, such as two-lane serial where the clock signal is also bidirectional , PS/2 keyboard host and some other weird bit-intensive stuff like this, therefore acting as external PICAXE perhipherals.

I have used assembler with a 16F84 to generate a Pseudo Random Pattern Generator about 8 year ago.. Obtuse architecture ! were my thoughts at the time. Most details long forgotten ! Yes I had thought of multiple processors. But early stage so not decided yet.

Many thanks for the input.

: )

Tim

 

[Chavaquiah]

Although I might prefer AVR's 1 MIPS per MHz efficiency, compared to 4 clock cycles per instruction for PIC

Not all PICs, though. For instance the PIC12F683 (as used for the Picaxe-08M) already implements a RISC architecture with most instructions taking only one cycle.

(Yes, a true wolf in sheep's clothes!)

 

[Tim036]

Not all PICs, though. For instance the PIC12F683 (as used for the Picaxe-08M) already implements a RISC architecture with most instructions taking only one cycle.

(Yes, a true wolf in sheep's clothes!)

Very interesting ! Might be a clue to to gaining a solution !

What is the fastest clock for 08M s ?



Tim

 

[Dippy]

Whilst we love to hear about C and ASM skills I haven't actually got to grips with the question...

"Are there any really fast Pics around ? Factor of 5 to 10 faster than the 65Mhz clock one?"
Are we talking PICs or PICAXEs here?
People often abbreviate PICAXE to PIC - this often causes endless confusion which sometimes requires nail-pulling interrogation to clarify


You really need to consider YOUR application rquirements and read the micro DATA SHEET before anyone can start making sweeping comparisons. There is a LOT more to it than MIPs and/or fancy jargon.

If you are talking PICs then there are many processors around for you to investigate from AVRs to ARMS to dsPICs and a host of others.
BUT you must investigate the peripherals too.

When I last looked at an ATMEGA48-something I was unimpressed by the maximum ADC speed. An average 18F PIC was >4x faster.
(I didn't look any further so I don't want a lesson thanks).

So, I think you'll have to spec your requirements against micro spec.
And that could be quite a long job. So, good luck and enjoy. Good Hunting.

 

[Tim036]

Whilst we love to hear about C and ASM skills I haven't actually got to grips with the question...

"Are there any really fast Pics around ? Factor of 5 to 10 faster than the 65Mhz clock one?"
Are we talking PICs or PICAXEs here?
People often abbreviate PICAXE to PIC - this often causes endless confusion which sometimes requires nail-pulling interrogation to clarify


You really need to consider YOUR application rquirements and read the micro DATA SHEET before anyone can start making sweeping comparisons. There is a LOT more to it than MIPs and/or fancy jargon.

If you are talking PICs then there are many processors around for you to investigate from AVRs to ARMS to dsPICs and a host of others.
BUT you must investigate the peripherals too.

When I last looked at an ATMEGA48-something I was unimpressed by the maximum ADC speed. An average 18F PIC was >4x faster.
(I didn't look any further so I don't want a lesson thanks).

So, I think you'll have to spec your requirements against micro spec.
And that could be quite a long job. So, good luck and enjoy. Good Hunting.

Picaxe is the yardstick.



Tim

 

[Dippy]

Excellent. That's cleared up that one then

 

[tiscando]

Not all PICs, though. For instance the PIC12F683 (as used for the Picaxe-08M) already implements a RISC architecture with most instructions taking only one cycle.

(Yes, a true wolf in sheep's clothes!)

I meant that each PIC assembler instruction takes 4 oscillator pulses to execute, so one cycle takes 4 oscillator pulses.

 

[tiscando]

Are we talking PICs or PICAXEs here?
People often abbreviate PICAXE to PIC - this often causes endless confusion which sometimes requires nail-pulling interrogation to clarify

When I last looked at an ATMEGA48-something I was unimpressed by the maximum ADC speed. An average 18F PIC was >4x faster.
(I didn't look any further so I don't want a lesson thanks).

I don't abbreviate PICAXE to PIC here.
Good point...

 

[Tim036]

I meant that each PIC assembler instruction takes 4 oscillator pulses to execute, so one cycle takes 4 oscillator pulses.

Is that not true for all Pic processors because of its layered pipe architecture ?



Tim

 

[Dippy]

ds and PIC32 use different architecture, so NO. For details check Microchip website.

OK, PLEASE can we go back to the OQ?

Clarify: Are you asking for details on a micro (of any make) that is 10x faster than a PIC (running native code) or a micro 10x faster than a PICAXE running PICAXE BASIC??????

If you are referring to the best PICAXE flat out then you will find that a similarly clocked PIC (yes, PIC) running compiled code will easily give you that speed boost. Buy a compiler and a hardware programmer. Read Data Sheets. Learn the compiler. Job done, next please

 

[Tim036]

ds and PIC32 use different architecture, so NO. For details check Microchip website.

OK, PLEASE can we go back to the OQ?

Clarify: Are you asking for details on a micro (of any make) that is 10x faster than a PIC (running native code) or a micro 10x faster than a PICAXE running PICAXE BASIC??????

If you are referring to the best PICAXE flat out then you will find that a similarly clocked PIC (yes, PIC) running compiled code will easily give you that speed boost. Buy a compiler and a hardware programmer. Read Data Sheets. Learn the compiler. Job done, next please

Fair comment !

Many thanks for your understanding.



Tim

 

[tiscando]

OK, PLEASE can we go back to the OQ?

Clarify: Are you asking for details on a micro (of any make) that is 10x faster than a PIC (running native code) or a micro 10x faster than a PICAXE running PICAXE BASIC??????

If you are referring to the best PICAXE flat out then you will find that a similarly clocked PIC (yes, PIC) running compiled code will easily give you that speed boost. Buy a compiler and a hardware programmer. Read Data Sheets. Learn the compiler. Job done, next please

From common sense and that he said "the fastest picaxe is too slow", I think he just meant to say "are there any PICAXEs a factor of 5 or 10 faster than the 64MHz PICAXE?" My answer would be no, but isn't there one planned yet?

 

[Dippy]

So many people switch between "PIC" and "PICAXE".
So many times we speak at cross-purposes.

If you correctly thought that Tiscando, then why didn't you post that reply earlier rather than talk about ASM?

Hindsight is 20/20 huh? And the thread was meandering....

 

[BeanieBots]

I'm still none the wiser about the application besides "fast switching".
Well, nothing switches faster than raw hardware! Maybe 10,000 times faster than the fasted micro.
Next to that, programmable logic arrays.

Does it NEED to be written in software?

 

[hippy]

Technically the PICAXE switches as fast as any other hardware but it may have a longer latency between activation to switching

Without further information on the actual requirements no one can really add much more.

 

[Tim036]

I'm still none the wiser about the application besides "fast switching".
Well, nothing switches faster than raw hardware! Maybe 10,000 times faster than the fasted micro.
Next to that, programmable logic arrays.

Does it NEED to be written in software?

Yes, , its two parrallel very complex related fast data pulses and the contents are very likely to change in the short term. Software IMHO is the easiest way to stay flexible.



Tim

 

[InvaderZim]

I agree with BeanieBots: if it is just one thing holding you back, do it in hardware. You can save a ton of coding with a single AND gate, or a clever 555 timer circuit, or a few flip flops. You can design a logic circuit that can be far, far faster than you could hope to get this side of a specialized computer, and it'll work with minimal or no code and cost less than $1. And it's "parallel processing" of a sort.

You don't see hardware solutions in industry as much because hardware costs money per unit sold, where software is more of a one-time cost. If you are scaling up to millions of units, the choice is pretty clear to use a good size processor and as little else as possible, even if it means months of horrible coding trials. Saving $0.25 in hardware is big bucks to a consumer product, that's a hundreds of thousands in pure profit. But to us, a quarter is just a quarter. Spend it on some hardware and save hours of coding. Think outside the processor!

I've sometimes thought "hmm, PICAXE can't do X; I've been wanting to try some C code, maybe I need to dump PICAXE..." but then I come to my senses and realize that there is still a pretty big pain in the butt to take to do half the things that an 'AXE gets you right off the bat. So I man up, make some hardware, and get back to having fun with the 'AXE.

 

[Tim036]

I agree with BeanieBots: if it is just one thing holding you back, do it in hardware. You can save a ton of coding with a single AND gate, or a clever 555 timer circuit, or a few flip flops. You can design a logic circuit that can be far, far faster than you could hope to get this side of a specialized computer, and it'll work with minimal or no code and cost less than $1. And it's "parallel processing" of a sort.

You don't see hardware solutions in industry as much because hardware costs money per unit sold, where software is more of a one-time cost. If you are scaling up to millions of units, the choice is pretty clear to use a good size processor and as little else as possible, even if it means months of horrible coding trials. Saving $0.25 in hardware is big bucks to a consumer product, that's a hundreds of thousands in pure profit. But to us, a quarter is just a quarter. Spend it on some hardware and save hours of coding. Think outside the processor!

I've sometimes thought "hmm, PICAXE can't do X; I've been wanting to try some C code, maybe I need to dump PICAXE..." but then I come to my senses and realize that there is still a pretty big pain in the butt to take to do half the things that an 'AXE gets you right off the bat. So I man up, make some hardware, and get back to having fun with the 'AXE.

Its about a dozen details that stop a hardware solution. wrapped round flexibilty.



Tim

 

[BeanieBots]

Sounds like a programable logic array would be ideal though.

 

[Tim036]

Sounds like a programable logic array would be ideal though.

Will investigate, many thanks for the tip !



Tim