PICAXE & Arduino (code size comparisons - just for fun)

mrburnette

Senior Member
Note: Please do not make religious/fanboy arguments about either product. This post is informational ONLY and is based on the first 4 Arduino BASIC examples sketches. Where possible, I selected PICAXE examples from Manual 1 and then I took poetic license to edit as I saw fit to align the intention with the descriptions in the Arduino sketch.

Overview:
The reader should not take too much away from this light discussion of the two uC programming environments. I am not presenting any information that will suggest that one is better or more appropriate than the other. I do suggest (opinion) that after one has utilized the powerful Arduino environment that one may have a deeper appreciation of the PICAXE and its general ease-of-use. However, the reader is cautioned to understand that the PICAXE is running an interpreted BASIC language and that all of the statements supporting that language are in the PICAXE firmware. The Arduino environment was defined as a Arduino Uno (latest) using the core libraries provided under version 1.0.

Additionally, the user is cautioned to understand that there are no firmware libraries in a naked Arduino ATmel processor. The bootloader is simply that, a bootloader that allows for serial programming. The Arduino does allows for programming the ATmel processor without a bootloader but requires additional hardware in the form of an In-Service-Programmer (can be another Arduino as a sketch is provided to support this use.)

Now, with the fine print behind us, I only wish to concentrate on a few examples. I hope you find these intellectually stimulating comparisons.

#1 - Blank program
Picaxe:
Code:
# REM 08M2+ minimum program is a blank!
# Storage space required = 3 Bytes
Arduino:
Code:
// Arduino bare minimum = 466 Bytes

void setup() {
  // put your setup code here, to run once:
}

void loop() {
  // put your main code here, to run repeatedly: 
}

#2 - Read EEPROM and display to serial console

Picaxe:
Code:
REM PICAXE progrma to read 256 eeprom values and display
REM Memory used = 35 bytes
;
Do while b0 < 256
	read b0, b1
	sertxd (#b0, "     ", #b1,CR,LF)
	INC b0
loop
end
Arduino:
Code:
// Arduino sketch to read 256 eeprom values and display
// Binary sketch size: 2458 bytes 

#include <EEPROM.h>

void setup()
{
  Serial.begin(9600);
}

void loop()
{
  int a;
  int value = EEPROM.read(a);

  Serial.print(a);
  Serial.print("\t");
  Serial.print(value);
  Serial.println();

  a = a + 1;

  if (a == 512)
    exit;
}
#3 - Read and display ADC value to a serial monitor
Picaxe:
Code:
REM PICAXE read and display ADC value
REM Memory used = 12 bytes
;
main:
	readadc C.1,b0 ; read ADC1 into variable b0
	sertxd (#b0, CR, LF)
	goto main
Arduino:
Code:
// Arduino sketch to read and display analog value
// Binary sketch size: 2464 bytes
/*
  AnalogReadSerial
 Reads an analog input on pin 0, prints the result to the serial monitor 
 */

void setup() {
  Serial.begin(9600);
}

void loop() {
  int sensorValue = analogRead(A0);
  Serial.println(sensorValue);
}

#4 - Blink a LED on a digital pin for 1 second on and 1 second off, repeat

Picaxe:
Code:
REM PICAXE Blink a LED: one second on, off, repeat
REM Memory used = 14 bytes
;

symbol LED = B.4 ; rename output4 &#8216;LED&#8217;

Do
	high LED ; LED on
	pause 1000
	low LED
	pause 1000
	Loop
Arduino:
Code:
// Arduino sketch to blink a LED
// Binary sketch size: 1026 bytes
/*
  Blink
  Turns on an LED on for one second, then off for one second, repeatedly.
 */

void setup() {                
  // initialize the digital pin as an output.
  // Pin 13 has an LED connected on most Arduino boards:
  pinMode(13, OUTPUT);     
}

void loop() {
  digitalWrite(13, HIGH);   // set the LED on
  delay(1000);              // wait for a second
  digitalWrite(13, LOW);    // set the LED off
  delay(1000);              // wait for a second
}

# 5 - Read and display on a serial console the Hi (1) and Lo (0) state of a PIN

Picaxe:
Code:
REM PICAXE read a physical pin and report state to serial console
REM Memory used = 10 bytes
;

Do
	sertxd (#pinC.3,CR,LF)
	Loop
Arduino:
Code:
// Android sketch to read a pin and display to console
// Binary sketch size: 2734 bytes 
/*
  DigitalReadSerial
 Reads a digital input on pin 2, prints the result to the serial monitor 
 
 This example code is in the public domain.
 */

void setup() {
  Serial.begin(9600);
  pinMode(2, INPUT);
}

void loop() {
  int sensorValue = digitalRead(2);
  Serial.println(sensorValue);
}

I have worked for some time with the PICAXE chips (08M2, 18M2, 20X2) all on breadboards supported with USB-Bub interfaces and with the ATmel Tiny85, ATmega 168 and the ATmega UNO/ATmega328 supported with the UNO interface either natively or with the ArduinoISP sketch supporting breadboard activities.

  • Both environments are productive
    Both environments are easily interfaced
    Both environments support USB easily

As I was playing around with sorting similar programs to put into this thread, I reflected a moment on the PICAXE firmware and the great efficiency that was put into that code. As one notices the very simple BASIC code and the small source size, one must keep in mind that the machine-code library that support all of the PICAXE commands is already loaded into the PICAXE as firmware. In the past, I have argued that this approach is wasteful since much of the firmware goes unused for simple BASIC programs. However, in all fairness to RevEd, this approach never offers any OMG surprises as the Arduino does since adding one instruction in that environment can pull in an external support library that causes a significant jump in uC program storage requirements.

The reader is left to ponder this: I am certain that ATmel and PIC folks will remain in their respective encampments. But from a hobby programming perspective, both are equally interesting and capable. While the Arduino is often stated as more expensive for projects, this is actually not the case (opinion) since with some effort, the programmer can avoid the use of the bootloader and can avoid the use of the external crystal. The PICAXE is often described as a beginners environment, but I (opinion) disagree since many complex projects can be easily supported by these chips.

- Ray
 

tinyb

Member
Excellent work.

I too have found many of the point you have mentioned above in both my teachings of picaxe and arduino and my personal quest of picaxeing the sparkfuns inventors kit. although not uploaded to the blog at the moment, it has been an intersting process.

if you have completed more examples i would love to see them.
 

srnet

Senior Member
Very Interesting.

Wonder what the comparisons would look like if the total PICAXE code size (i.e. inc the firmware) was compared with the total Arduino program size or the programs were substatially longer ?
 

BillyGreen1973

Senior Member
the picaxe 'led blink' code can be made even smaller by using the toggle command. 9 bytes.

Code:
REM PICAXE Blink a LED: one second on, off, repeat
REM Memory used = 9 bytes
;

symbol LED = B.4 ; rename output4 ‘LED’

Do
	toggle LED ; LED on/off
	pause 1000

	Loop
 

mrburnette

Senior Member
if you have completed more examples i would love to see them.
I guess the list could go as long as there are 'sample' programs for the Arduino! I gave some consideration to not even posting since the effort was more or a tangent to something else I was doing and I just needed some 'down time' to regroup some overworked neurons. I also did not wish to offend anyone in either camp... so, I purposely picked examples that do not involve a lot of programmer introspective or experience.

And giving this forum is hosted by RevEd, I certainly did not wish to get into any confrontations; just wished to present facts and provide an insight into the two products. Going beyond what I did would probably get into slippery slopes. If I continue, I will probably post in the Blog area rather than the code snippets.

- Ray
 

mrburnette

Senior Member
the picaxe 'led blink' code can be made even smaller by using the toggle command. 9 bytes.
Addressed in my opening statement, "Where possible, I selected PICAXE examples from Manual 1 and then I took poetic license to edit as I saw fit to align the intention with the descriptions in the Arduino sketch."

However, you present a valid point... some PICAXE commands and syntax usage can have an effect on code size and code size can be (does not have to be) indicative of instructions which then can predict the overall efficiency. However, applying this to a truly compiled C/C++ language which is the back-end of the Arduino can be really problematic. Thus, if I were to wade through that muck, I would surely want my wellies pulled up tight!

What I did not mention in my opening statement is that I had my Arduino environment "set-up" for an ATtiny85... using internal oscillator at 8MHz and no bootloader. I was using the Uno as an AVR programmer for the ATtiny85. I did this specifically so that I could run a syntax check on the Arduino code and ensure that I was working with non-core libraries... that is, I wanted to insure that #include was added where necessary. I also did not want to be crude and directly try and compare an ATmega328 to any PICAXE since I do not have a PICAXE developed protoboard.

There are all kinds of ways to spin this; but I think that to be absolutely fair to both camps, that what the 'take away' should be is that PICAXE chips ALL have 100% of their libraries internal. In the Arduino world, source code is linked with libraries and the composite is loaded into the ATmega chip; thus, source code size has no relevant yardstick to machine code size. Rather, in the Arduino world, program size is directly related to library complexity. In the PICAXE world, source code size is fairly indicative of storage requirements in the PIC hosting the PICAXE interpretive environment.

Again, I suggest that RevEd's coders have created a very crafty and efficient library and interpreter. When PICAXE'ers go a-looking for code examples, we turn to BASIC source code exclusively. In the Arduino world, things are much more complex and you may find yourself torn between many libraries that are required to support a program (core Arduino environment has something like 12 complex libraries.) That the two chips are used in similar projects by similar amateurs for hobby and project use is a testament to the hardware and supporting software.

It would be easy to make a broad statement that a beginner should begin in BASIC and move toward C/C++... or said another way, start with PICAXE and end up with Arduino. But there was recently an argument in the forums that suggested that if you did not use assembler, you were somewhat hand-tied. I view things quiet differently and suggest that every environment has something to offer positive and sustainable. That I elect to program some things in the Arduino environment and other things in the PICAXE environment is because they both have appeal, they have value, and are holding their own. I would caution that the PICAXE programmer environment (editor, downloader) do not have the "feel of sophistication" but that may be just that the PICAXE GUI environment has evolved differently in the proprietary code-base. In the Arduino environment, I particularly like their use of separate windows and not the child MDI windows presented by PE (PE just feels too much like the old Windows text editor - Opinion.) I think RevEd has done a far superior debug environment, however.

- Ray
 

mrburnette

Senior Member
Very Interesting.

Wonder what the comparisons would look like if the total PICAXE code size (i.e. inc the firmware) was compared with the total Arduino program size or the programs were substantially longer ?
How I wish I could ferret this out! WestAust55 has done a tremendous quantity of work around instruction times, but if one cannot get the code into the uC... whatcha going to do? Move up to the next PICAXE chip capacity. This is not always an appropriate path since the move may change the physical characteristics of the uC... pins, size, power... and there is the cost$ associated with the more capable chips- essentially if more than one unit is envisioned.

The Arduino libraries are granular, so the programmer generally gets only the function(s) s/he needs. However, there is always library bloat in larger and more complex libraries such as the I2C or the LCD or even the eePROM libs. Too much granularity presents an inefficient programming approach as too much initialization and type code is required. Too little granularity leave unused functions in the environment. But, Arduino libraries are almost always in source code, so one can (with effort) remove code not needed for a particular use IF size matters.

- Ray

After thoughts:
I respectfully suggest that RevEd has done a good job getting all of their libraries and code into the PIC to create a PICAXE. Of course, there are additional instructions to be gained as one goes up the PIC sophistication uC chain from the 08M2 to the 20X2, etc. I think sometimes the fact that different chips have different instruction sets is lost until one actually goes to use an instruction only to realize the PICAXE does not support that functionality. This is not to say that different ATmel chips do not have different capabilities; rather it is only suggestive of the nature of the beast.

BASIC is a good language but there are lots of good languages! The question is, will a particular language work for me? The next question is does the investment in time/effort/expense equate to an investment in my knowledge and expertise... or asked another way, am I continuing to grow personally/professionally from this effort? One must remember that the "B" in BASIC is "beginners" and a tremendous quantity of abstract programming skills cannot be based upon PICAXE BASIC... for example, Function, Object, Array, Inheritance, and so on. If I were a teacher in middle school, I think I could use the Arduino environment to teach introductory programming nearly as easy as using the PICAXE. While I cannot provide any statistics for my belief, I believe that starting in an Arduino environment would be a more significant value to the student and would introduce an environment with more (future) capability and a set of skills that could be used as the basis for growth in high school and college and beyond. I am certainly not taking away from the PICAXE utility but I am merely suggesting that there are huge holes in computer programming concepts that are not filled by the PICAXE environment at present.

As the Arduino environment is currently targeted for ATmega, there is really no reason that the same open-source environment could not be used to support the PIC uC. The core work effort would be in "Wiring" and replacing the underlying ATmel-centric bootloader and flashing software. Of course, what significant benefit would this present to RevEd? At present, I can think of nothing; however, Microchip may see some additional sales of raw chips.

Business is a bitch, ain't it?

- Ray
 
Last edited:

graynomad

Senior Member
As the Arduino environment is currently targeted for ATmega, there is really no reason that the same open-source environment could not be used to support the PIC uC.
It already is on PIC (ChipKit?, not official Arduino but the same AFAIK), and ARM (official) coming soon as well.
 

mrburnette

Senior Member
@graynomad... yes, it is... thanks for mentioning, I had not seen the adverts... I live in my basement workshop and if I don't run across an advertisement in other research, I miss out on the whole experience!

Anyway, with PIC now available in the Arduino environment (manf.=digilent) and they appear to be targeting the high-end academic market, it just means more competition for Rev.Ed. (In my opinion but I do not know the penetration level of PICAXE in higher academia- so maybe this is not a concern or maybe the product is too new at less than 1 year to be any threat.)

I have been slightly critical of Rev.Ed. recently because I like working with the PICAXEs but I am not seeing the advances in their products (primarily the PE and toolchain) that is happening in the Arduino free-market... probably better said as, "open source" market since nothing "arduino" is free if there is any mention of the noun 'hardware.'
The specs are impressive:
Microchip® PIC32MX320F128 processor 80 Mhz 32-bit MIPS 128K Flash, 16K SRAM
... At under $30 U.S. it is within $5 of the ATmega UNO or exactly the same as the UNO from SparkFun. It I were building a high-end embedded system where I needed this kind of power, I would certainly invest.

I am retired and use my lab time these days for play and personal satisfaction, but if an oldfart like myself can find fun and enjoyment in the Arduino which was designed and targeted for the artsy fartsy market, then there must be something appealing in the interface or hardware or a combination thereof. I do not even particularly like the UNO design with the vertical headers, but I am finding that I am only using it for programming (like my PICAXE breadboards) and then I move the chip to the big breadboard or a protoboard for continued work. I find myself doing the same with the PICAXE, too, and rarely do I use the InCircuitProgramming option... Of course, I work with ZIF sockets... so, my mileage may be different than others.

- Ray
 
Last edited:

hippy

Senior Member
I have been slightly critical of Rev.Ed. recently because I like working with the PICAXEs but I am not seeing the advances in their products (primarily the PE and toolchain) that is happening in the Arduino free-market...
Fair criticism is always acceptable, and that is always taken on board even if it doesn't seem to be immediately acted upon - For the Programming Editor there are plans in the pipeline which are actively being progressed, VSM now supports X2 and M2 parts, somewhat later than we had hoped for but the simplicity of use of PICAXE within VSM hides the complexities behind it all.

One must however bear in mind that the primary target audience for the PICAXE is the educational sector and often that's students with little or no prior programming experience, so a lot of what we do is focused towards that, rather than competing directly with systems which are aimed at users who are more experienced or more capable. That said, we do however hope to cater for a wide range of users with diverse experiences and capabilities, but it has to be recognised that it's difficult to have any product which is ideally suited to everyone's tastes.
 

westaust55

Moderator
Just implement in-line assembler, then everyone will be covered :)
As soon as an in-line assembler is implemented someone will try to download/"dump" the firmware to create their own "PICAXE". Then the clones will be on Ebay and elsewhere.

The firmware is Rev Ed's Intellectual Property (IP) and keeping it securely guarded is their only way to stay in business.
The do not charge a fee for the Programming Editor and their mark up between the raw/native PIC cost and the Rev Ed selling price is their source of income to develop new firmware and pay employees.

Having dis-assembled the tokenized BASIC so I could splice in my own extra functions (such as speech using the SC-01 Speech chip, and low 128x128 pixel resolution graphics) on early microprocessors (mid 1970’s) through to OSI and TRS-80’s (Late 70’s) and Commodore 64 (early 80’s) before my experiments in such when into abeyance, I am fairly conversant in how they work. From my work mrburnette mentioned at post 7, I know a lot more than I will ever disclose to protect Rev Ed’s IP (and myself).
 

mrburnette

Senior Member
You need to get out more :)
Yea, I hear that (often.) I did accompany a friend to Microcenter to buy parts for a new home-built PC... it's fun spending other folks money.

I think my "problem" is that with the exception of one year in research after college in the School of Electrical Engineering as an employee, the rest of my working career was pretty terse; added to the normal issues and time constraints of raising a family, etc. Now retired, I am really having a blast again... like being a teenager in my old garage workshop back when I was in high school... before my military service days except the PICAXE is the new CK722. There is just so MUCH to do and too few hours! Today's project is putting a RTOS on my Arduino uC... really! http://chibios.org/dokuwiki/doku.php?id=start One of the Arduino forum senior members has ported the RTOS to the ATmega328... I may be in my laboratory for a long time (fortunately, pizza delivery is convenient since the workshop has its own door.

- Ray
 

mrburnette

Senior Member
Fair criticism is always acceptable, and that is always taken on board even if it doesn't seem to be immediately acted upon - For the Programming Editor there are plans in the pipeline which are actively being progressed, VSM now supports X2 and M2 parts, somewhat later than we had hoped for but the simplicity of use of PICAXE within VSM hides the complexities behind it all.

One must however bear in mind that the primary target audience for the PICAXE is the educational sector and often that's students with little or no prior programming experience, so a lot of what we do is focused towards that, rather than competing directly with systems which are aimed at users who are more experienced or more capable. That said, we do however hope to cater for a wide range of users with diverse experiences and capabilities, but it has to be recognised that it's difficult to have any product which is ideally suited to everyone's tastes.
I sincerely hope that my words were viewed as 'fair' - that was my intent. I have argued in many threads that Rev.Ed. has a business model and has to be true to that charter... it take lots of time to morph good ideas into a currently successful endeavor.

However, I think you may be underestimating the Arduino audience of 1st time users, non-technical in large majority, this group seems to 'grasp' the programming constructs of a structured language approach very quickly. I taught professionally in industry for 3 years and did adult course development and I am amazed since this 'bucks' hard against what my perceptions would have been...

I am glad RevEd is evolving; it is healthy. But do not undersell the ability of your users to grasp advanced concepts and utilize them effectively - even if it is only cut&paste. Arduino 1.0 provides structure and concept and a template approach; not unlike some of the PICAXE concepts, but the vocabulary used is more attuned and harmonious with advanced computing concepts; which is to say that real functions and procedures and objects and libraries exist naturally and therefore absorbed gradually through the introductory and example period of a student's introduction to the Arduino environment... not concepts that must be learned and applied separately at some later time after learning through the BASIC language. With no disrespect meant, it may be that BASIC stifles some users from advancing since it is so darn easy to use; which is not bad if that user is simply a hobbyist and are comfortable and happy in their comfort zone. But for students that must advance in the engineering sciences and even the creative arts, I have come to believe that perhaps the Arduino team has hit on a real winning concept. I learned BASIC after learning Fortran in college engineering and struggled with the lack of functionality. I learned BASIC again with the BASIC Stamp. So, when I started to play with the PICAXE devices, there were no concepts I needed to learn, I just needed to find my way around the environment and associate old ideas with new implementations. Even for this oldfart, it was an easy transition. But, I do have an assembler background of a few years and I do have formal training of OOP and even contributed to some Delphi work at one time in the Enterprise. So... here is the bottom line for me... I love the PICAXE and it is fun to solder up a little project and even post ideas to the community here and have some light word-play from time to time. But the Arduino has a "natural" draw to the entire environment and the environment is rich is current technology, implementation, diversity, and most importantly flexibility. It is also fun and features advance concepts that are naturally right in the prototyping of every naked sketch. Amazingly, the introductory price in the U.S. for the authentic, assembled Arduino Uno is $23 with the 328P chip which features embedded USB. Peter Anderson sells the AXE401 kit with the 28X2 for $17.95 ... The $5 for a completely soldered and tested board is warranted in my opinion - especially for a novice assembler.

Just food for thought ... but I believe that such things as LCD and CPU boards probably should not be assembled by a novice... but let the experienced kit builder buy all of the parts for a discount. Sorry... not to imply that I'm telling RevEd how to run their business, but I see so much frustration here on the PICAXE forum by beginners trying to get their first board to work correctly - I do not believe in baptism by fire... especially when the ignition device is a 300W soldering iron!

- Ray

do you want Alfred building his first PICAXE kit ... or, would buy one assembled and tested?
alfred-e-newman-how-to-solderc.jpg
 
Last edited:

mrburnette

Senior Member
As soon as an in-line assembler is implemented someone will try to download/"dump" the firmware to create their own "PICAXE". Then the clones will be on Ebay and elsewhere.

The firmware is Rev Ed's Intellectual Property (IP) and keeping it securely guarded is their only way to stay in business.
The do not charge a fee for the Programming Editor and their mark up between the raw/native PIC cost and the Rev Ed selling price is their source of income to develop new firmware and pay employees.
<...>
All true my friend and I have said similar in many threads. But the 'rub' we are dealing with at this point in uC evolution is that alternative open-source products exist and an entire industry is developing to supply wanted goods... even RevEd sells the PICAXE-28X2 AXE401-KIT Shield Kit in the U.S.

So, if Arduino is gaining momentum, how does the PICAXE product respond? In all respect to RevEd and all of the great employees that assist with this forum, I an pretty sure that a proprietary firmware is not the right way. When the BASIC Stamp tried that approach, Scott Edwards and others created assembler libraries and published books on how to bypass the interpreter for fun and profit. Arduino has a footprint that is scary big. I have worked with the environment long enough now that I have 2 UNO boards and 2 breadboard Arduino in my own lab and several ATtiny project boards that I have programmed from the GUI directly without the need for an AVRISP or even the bootloader. Darn stuff works great and assembly is available as is C and C++. What is not to like? But...

My biggest argument is that RevEd BASIC simply is not object oriented. It is powerful and a beautiful work of art but it is stuck inside the darn chip and protected like the Coke Cola formula. When the PICAXE thing began, open source software did not have the footprint it does now and liberal arts people were just beginning to think about using technology in art... today, they are doing lots more than thinking about incorporating technology, they are driving the technology ... and they are sucking in technical folk and software architects and the products are mushrooming and the capabilities are awesome. I mentioned in this thread today that I have the afternoon scheduled to play with ChibiOS on the Arduino.

I do not think in-line assembly is a requirement in the PICAXE market, but for those that want to do it... they have to change product. I am sure RevEd assumes that such attrition is the norm since they focus on education. But here is an analogy... schools in the U.S. have a driver education program for new drivers. Dealers provide new, free automobiles to the schools for the instructors to use because they want to create model affinity with hopes that when the young driver buys a new automobile they will migrate to the dealership providing the automobiles and purchase automobiles that are similar to what the student learned to drive. I have no idea if this plan works, but the dealers need to be reimbursed (somehow) for the expenses associated with this program- maybe a little higher profit margin on new car sells and maybe by some subsidy from the manufacturer. So, the kids are paying just a wee too much for that new car and the manufacturer MAY be slipping a few bucks under the table to support the retail market. And this is the way business has been done for years.

The Arduino marketplace does not work that way. The Linux marketplace does not work that way. Who knows how the Andriod market will work after Oracle? Point is... things are evolving. Remember the proprietary Microsoft Office file format? The European Union move to open document sure changed that, ugh? The market place is fickle and proprietary code can be very valuable one day and completely worthless another. I want to see RevEd succeed - and thrive - but I have no answers for the mess created by Arduino... I just know I like it (Arduino, not the mess.)

- Ray
 

IronJungle

Senior Member
I'm so happy with the PICAXE vs the Arduino I can't see straight.

Just my opinion, but.... the PICAXE is both easier and most difficult to program at the same time. Let me explain...

There is a module, code, shield, breakout board, etc. for most Arduino applications. Makes things easier, but do you really learn anything and what is the fun and chalenge in that. The PICAXE is 'friendlier' if you want to create a uC project and walk away with a better satisfaction of creating something and not just replicating.

Now that said, I so wish Rev-Ed would step up their Mac support... I find for more detailed SW debug I have to go through the long and painful boot process from my old Windows machine. (I hate that).

Still, I don't see any Arduino purchases or recommendations in my future.
 

mrburnette

Senior Member
Do they have to ?
They are privately owned, so the decision is theirs...

@RevEd: I have edited (deleted) the vast portion of this post because it occurs to me that to continue down this thread is not a productive exercise - which is to say, there is no vanishing point to be seen. Playing devil's advocate on either side simply acts to accent the differences and that alone will play to someone's idea of an endorsement for a product / technology.

Regards,

- Ray
 
Last edited:

john2051

New Member
Hi Ray, where in the datasheet does it say that the 328p has embedded usb, because I cant seem to find it.
Maybe you meant the extra 16u2 that converts usb to serial. It would be nice if they did.
regards john
 

nick12ab

Senior Member
Hi Ray, where in the datasheet does it say that the 328p has embedded usb, because I cant seem to find it.
Maybe you meant the extra 16u2 that converts usb to serial. It would be nice if they did.
regards john
The 328 does not have embedded USB. The 16U2 is a microcontroller with embedded USB and it is programmed to act as a USB-to-Serial converter.
 

mrburnette

Senior Member
Hi Ray, where in the datasheet does it say that the 328p has embedded usb, because I cant seem to find it.
Maybe you meant the extra 16u2 that converts usb to serial. It would be nice if they did.
regards john
Sorry, John, my exact quote was
Amazingly, the introductory price in the U.S. for the authentic, assembled Arduino Uno is $23 with the 328P chip which features embedded USB
Which should have said "on board USB" in lieu of "embedded"... the UNO Arduino board at roughly $23 U.S. has USB; said board using the ATmega328P us. Sorry for any misunderstanding.

However, the newest Arduino implements USB firmware in the boot loader:
http://arduino.cc/en/Main/arduinoBoardLeonardo
The Leonardo differs from all preceding boards in that the ATmega32u4 has built-in USB communication, eliminating the need for a secondary processor.
Of course, a number of clone boards have been implementing USB in the ATmel uC boot loader for a while and have gained a fair following.
-Ray
 
Last edited:

Janne

Senior Member
On the hobby and "hacker" market I don't think it's so much about performance(interpreted basic vs. compiled machine code), as many hobby projects are not that demanding on that sector. Programming a bigger project with picaxe basic is a huge pain in the backside compared to C, but again the hobby projects don't usually grow too much.
The biggest impact I think is in the hardware and associated code blocks. Many times a hobbyist doesn't want to spend too much time creating a project from scratch, but rather to borrow upon other's work. Putting the hardware together from a few pre-built shields, and maybe cobbling together something to add to it.. Many times beats the crap out of creating a pcb from scratch.
The same goes on the code side, open source community provides so many libraries that much of the common stuff is very well supported. #Include the parts you need, and add your unique software on top.
If we think of the picaxe, hardware availability is quite ok. But the language totally prevents the idea of simply throwing together a bunch of code libraries or functions created by others. To support this librarized idea, the language would need to (at least) support local variables, that are dynamically allocated from stack/heap, and local namespace.. Just to get started.

In all fairness, I think with the current business model of education being rev-ed's main market, those kind of modifications don't seem likely to happen. The amount of cost associated with that would be too great, and not justified without targeting the hobby sector considerably more.
 

mrburnette

Senior Member
Yes, Janne, you bring up good points... the Ying & Yang of the current "uC and education" and "uC and hobby" environment.

There was a time where the electronic hobbiest relied upon their own total abilities to duplicate and evolve works in "popular" magazines that catered to electronics. OR, just build a kit from Allied, Radio Shack, of Lafayette! Many of the rough-n-tough group were Hams or future Hams and were pretty handy with their hands and a soldering iron. Electronic education was simply not in the secondary schools in the U.S. unless the kids were in a vocational high school for trades such as radio/TV repairs, etc. The world has evolved in 50 years and it is not uncommon to see some electronic circulums in secondary schools and the Internet has created a whole world of hardware/software students. This has created a lots of speciality groups such as PICAXE, Arduino, etc. (Almost like the Windows / Linux / iOS group!)

I have argued in numerous threads that Rev.Ed. "could" evolve the software side of the compiler to allow "code libraries", but it is not straight forward. You hit on the primary issue, variable "scope" which is a concept foreign to PICAXE at the moment. BASIC as a language is NOT the problem, PICAXE BASIC with the interpreter in-chip is the problem, however. This can be fixed, however, but would make the current PE simulator very complexed... today, it is simple because the chip interpreter is a simple state machine. When one considers the issues associated with external libraries, one can imagine that the state machine must be driven from the digested source code. This is the reason that most chip debugging tool are a marriage of hardware & software (ICE, etc.)

I echo your remark about RevEd regarding their 'current business model... and their main market.' In business (profit based), an investment in future technology is generally made only if the projected profit is sufficient to make the required return on the investment. Open Source hardware products have a more complex model since they can instantiate a design quickly and move through a shorter life-cycle and even a non-compatible hardware model... as seen with the various Arduinos. The Arduino GUI shields the software writer from the hardware by remapping most resources automatically... assuming one selects the correct board before hitting "compile & upload" :eek:

I do think speed (efficiency) has a bigger part in the market, however, as even some PICAXE'rs have resorted to compiled code to augment some projects... although, if memory serves me well, the project stuck in my head used PIC as the target architecture. I have seen several (more than "few" and less than "many") with the theme, "is PICAXE fast enough....". But mainly, if one needs to do complex integer math, then speed (instruction cycle-time) is critical. Instruction cycle speed, I would think, is not critical in the classroom. From a hobby point-of-view, many Arduino projects are actually slowed-down to allow for extended battery time which somewhat backs up your assertion.

- Ray
 
Last edited:

chipwich

Member
Wow. I just came across this great thread discussing the interplay between PICAXE and arduino. This is something I've thought about and watched for quite a while. As someone who was building with PICAXE, moved to arduino, and then has moved back to PICAXE, I thought I'd leave my comments and observations here. They are, of course, worth exactly what you're paying for them. 8^)

Both PICAXE and arduino are very capable platforms great for doing many many things. I moved *back* to PICAXE after playing with arduino, specifically because of the simplicity of the system. I can easily teach this to a 7 year old, and still build great projects. But trying to start off the education with object-oriented java, and floating point is not just overkill, it's actually a hurdle to teaching the basics. And sometimes a reduced instruction set speeds up project development since you don't have to refer to class library docs for everything. There's something incredibly gratifying about the simplicity of a full system using just an 8-pin DIP, 2 resistors, and a 3 pin header.

The nature of business is that things are always changing and companies need to adapt in order to stay profitable. I see the conversation in this thread discussing how the PICAXE could be changed to allow technical competitiveness with arduino for more complex projects (code libraries, assembler, variable scope, etc.). But I think this is a difficult path, since the open-source arduino is quite advanced, and altering PICAXE functionality requires engineers that cost money. If Rev-Ed wanted to support a platform with code-libraries, and variable scope, they needn't develop it, but could simply start supporting the arduino explicitly. After all, their biggest strength (as I see it) is that they've built a reputation for excellent community support. From their manuals, forums, and project galleries, to their educational support, and requests for input on how to improve the things, they are about as customer-friendly a company as I've ever seen in any industry. And services and support seem to be the underpinnings of successful companies in the open-source space.

So I see an ecosystem where PICAXE and arduino are complementary, rather than in competition. And I'd hope that should they desire it, Rev-Ed could find a way to profit from both platforms, as their quality of service would certainly also benefit arduino users.
 

mrburnette

Senior Member
<...>

But trying to start off the education with object-oriented java, and floating point is not just overkill, it's actually a hurdle to teaching the basics. And sometimes a reduced instruction set speeds up project development since you don't have to refer to class library docs for everything. There's something incredibly gratifying about the simplicity of a full system using just an 8-pin DIP, 2 resistors, and a 3 pin header.
<...>
Post #1 in this thread shows that the similarities in language are very close, mainly a wee-bit of additional structure and some syntax changes in the Arduino code. The setup() and loop() structure should represent a very simple concept even to a beginner: some things must be done only once and then some code is repeated... for example, children are taught during their automobile learning rules to do a mental checklist before cranking the automobile: adjust seats, adjust mirrors, buckle seat belt, etc. Once on the highway, there is a completely different pattern of repeatable rules: check the rear view mirror often, observe traffic signals, signal intention to change lanes, etc. Even BASIC programmers create initialization routines, some inline and some as subroutines, but things done before the Main: part of the code.

@chipwich: I personally do not understand your comment about Java. Just because the GUI requires it does not mean one needs to understand it any more than one is required to understand Microsoft C compiler to use the PE environment. Floating point is only used if you use require it as it is a library that is automatically linked. You can use the compiler day in for years without having to know that 'float' exists. Certainly, "float" cannot be as cumbersome as the faux methods of using integers to mimic float on the PICAXE.

If one thinks the "A..." is simply too complex to teach basic electronics, then perhaps a read here would be enlightening:
iarduino Prof. N. Mitsunaga in Japan has created a remarkable client-server product that is very much like the PICAXE PE debugger except works directly with every port on the physical hardware... NOT a simulation. The ability to script the software or even automatically invoke a script at power-up is a side benefit of this C simulator. Because every port on an UNO can be monitored and manipulated, this free public software represents a unique opportunity to learn electronics using the ATmega328P-PU chip ($1.99 U.S. qty 25 Newark).

My opinion. Belated addition: One should use what they are comfortable using. Some of us in this forum are into many different areas of microelectronics and use many different hardware devices. Others are only comfortable using the PICAXE. Neither approach should be seen as oppressive of the other. Be comfortable in your own skin. If you are uncomfortable branching out, don't branch out if you are in uC's as a hobby. If you are into uC's as a job function, obviously your options may be limited to the whimsey of your bosses. The PICAXE is just a PIC with proprietary firmware; the Arduino is an ATmega with open-source bootloader. Ultimately, if you are flashing a light, they are both great at doing that.

- Ray
 
Last edited:

graynomad

Senior Member
But trying to start off the education with object-oriented java, and floating point
Where does "object-oriented java" come into the picture, and why do you have to use floating point?
 

mrburnette

Senior Member
Where does "object-oriented java" come into the picture, and why do you have to use floating point?
Perhaps folks get confused with the volume of information and the numerous sources of same. There are official sources, official forum sources, playground sources, and then the huge other sources... plus Fauxduio (the name I use for my clones) clones. It can be overwhelming for beginners. Because the underpinnings of the GUI are rich in customization and enhancements, some may think that such knowledge is necessary... which, obviously is not true.

Floating point in C requires extra thought during output formatting and in working with integer variables that receive floating point results. A weebit confusing perhaps. Certainly NOT a day-one topic for a beginner. Beginners are best served with simple tutorials (and there are an abundance) such as this classic: ladyada

With any hobby, one should be cautious about jumping in deep water too soon... especially after just eating :eek:
Not a member here has probably survived not hearing their Momma tell them to not swim after eating, don't run with scissors, look before you walk, and for my British friends... Mind the Gap.

- Ray
 

graynomad

Senior Member
I've spent 25+ years working with embedded C and I can't recall a single time I've used floating point, so it's not necessary to foist it on a beginner.

some may think that such knowledge is necessary... which, obviously is not true.
Correct, I think Arduino don't do a very good job of explaining what's what.

I agree that the sheer amount of stuff available for Arduino will put many people off, personally I hate having too many options, just how many bloody tooth brushes do we need on the supermarket shelf for example :)

Picaxe has fewer options but in this context that's a good thing I think. And the Picaxe documentation is very good, unlike the Arduino "documentation" which is pretty pathetic.
 

Paix

Senior Member
Too many of us will remember that the choice of breakfast cereals was, Corn Flakes, Puffed Wheat, Porridge, Shredded Wheat or Wheatabix. Then came Frosties and Sugar Puffs along with the toys in the box. The last of which happily seem to have abated of late. Nowadays looking for breakfast cereal in a supermarket with a child must be a nightmare.

I was once pulled out of a sweet shop for not being able to make up my mind in good time. It only happened the once though; lesson learned.
 

chipwich

Member
Perhaps folks get confused with the volume of information and the numerous sources of same. There are official sources, official forum sources, playground sources, and then the huge other sources... plus Fauxduio (the name I use for my clones) clones. It can be overwhelming for beginners. Because the underpinnings of the GUI are rich in customization and enhancements, some may think that such knowledge is necessary... which, obviously is not true.
I think this accurately sums up a fundamental problem in teaching computers/electronics these days. There are just too many choices. Once upon a time BASIC was a defacto standard, and anyone learning to program could get a rudimentary (but portable) knowledge of programming just by spending a few hours with one of the interpreted BASIC editors that were part of the early home computers.

But try doing that today. There are so many languages, and so many variations on programming environments, that it's difficult to know where to begin.


I wasn't clear in my comments on on Floating Point and OO code, so let me try and restate my thoughts:

The PICAXE has only a few primitive data types: bits, bytes, and words. This inherently places constraints on how I write code; I have far less flexibility as compared to other languages where complex floats, strings arrays, and double precision are the norm. But I *like* this, because it brings me back to those early days of computing when I knew what was happening in almost every single byte of the computer during run-time. Sure, I can have a 32-bit word or a 2D array of bytes, but I must write the code for these types; and this is exactly why I think this is why the PICAXE is such a good educational tool.

Today's software environments are so abstracted from the hardware, that it's possible to build very advanced designs without ever really understanding what is actually going on in the silicon. The PICAXE provides an excellent and remarkably well thought out system which directly connects with the fundamentals of digital computing.
 

mrburnette

Senior Member
<...>
Today's software environments are so abstracted from the hardware, that it's possible to build very advanced designs without ever really understanding what is actually going on in the silicon. The PICAXE provides an excellent and remarkably well thought out system which directly connects with the fundamentals of digital computing.
Yes, I agree... "abstraction" is correct. It is a two-edged sword. One edge, the "hardware abstraction" allows for the concentration effort in problem solving to be focused on the software-logic and less on the hardware specifics. The second edge, however, is a lack (reduced requirement) to know hardware specifics for the underlying chip. I grew up in the hardware side and found myself learning the software side so I could evolve my own MLT (maintenance level test) routines... I wrote these in hand-coded machine instructions. Later, I learned Cobol. Then in college, I learned Fortran and took on the repair of a donated IBM 1602 with two language decks: Fortran and BASIC- The year was 1977. The next year, my professor allowed me to play around with a 68000 CPU in a box with switches for address and data and LEDs for the data lines. I was hooked.

BUT while my path was rewarding, there are other paths that provide satisfactions to users of today's designs; the artists often just want to make something happen and abstraction is a godsend to them. Many students just want to get through the introductory courses, abstraction is their friend. Students in grad school just want a tool to tailor to a process... abstraction is their friend.

Abstraction is here. Some students will explore the deeper levels, some will go on to design and evolve those circuits. Some, however will be happy at level 7 of the OSI stack! As an old timer, I try to be cautious that I do not impose my path on others... there are many right paths. We all must provide our wisdom but young and old generally oppose us when we push.

- Ray
 

IronJungle

Senior Member
A bit (get it, "bit") off the Arduino v PICAXE topic, but I didn't want to start a new thread.....

I have done some TI MSP430 work as well. I will spare showing the PICAXE code compare because it would be so simple and boring. Here is the code for the TI MSP430 to simply blink two LEDs.

Of course, this doesn't mean one uC is better than the other for all applications but from a programming point of view, the PICAXE is *way* easier to pick up.

Code:
#include  <msp430g2231.h>

void main(void)
{
  WDTCTL = WDTPW + WDTHOLD;                 // Stop watchdog timer
  P1DIR |= 0x01;                            // Set P1.0 to output direction
  P1DIR |= 0x40;							// Set P1.6 to output direction

  for (;;)
  {
    volatile unsigned int i;
    volatile unsigned int j;

    P1OUT ^= 0x01;                          // Toggle P1.0 using exclusive-OR
    P1OUT ^= 0x40;							// Toggle P1.6

	j = 50000
	i = 20000;                              // Delay
	do (j--);
	    do (i--);
	    while (i != 0);	
	while (j != 0);

  }
}
 
Last edited:

graynomad

Senior Member
Why are half the lines duplicated as comments? It just makes the code look longer than it is.

do (i--);

AFAIK that's not even valid code.

i = 20000;
...
while (i != 0);

This is an endless loop, not a delay.

Am I missing something, is 430 C vastly different to other Cs?
 

IronJungle

Senior Member
>Why are half the lines duplicated as comments?
This was a formatting error from the cut and paste (I guess). I corrected my post.

>do (i--);
>AFAIK that's not even valid code.
It is valid. I means reduce the value of the variable "i" by "1" and store that value in "i".
The BASIC statement may look like: i = i - 1

>while (i != 0);
This statement tests the value of i vs. 0 as a condition to continue the 'while loop'

>This is an endless loop, not a delay.
No... It's acts as a delay. Larger values of i or j would result in a longer delay.
The endless loop is created with the line "for (;; )" (and terminated with "}"). Means do this loop until hell freezes over.

>Am I missing something, is 430 C vastly different to other Cs?
I think so. The MSP430 C is different , but not vastly different. It is focused on uC applications and not GUI, etc.
 

hippy

Senior Member
do (i--);
while (i != 0);


Looks like it's valid C code but I'm not sure it works in the way it looks like it does. I suspect the "(i--);" is a statement rather than related to the "do", actually an assignment, the result of which gets discarded, decrementing "i" is actually a side effect.

That's one to save for Halloween!
 

Paix

Senior Member
I guess that:
Do ( i-- ) equates to test i and then decrement, as opposed to
Do ( --i ) which would indicate that the value of i was to be decremented before being tested.
in either case I would expect the loop to fail when the result of the expression ( ) tested as zero.
 

IronJungle

Senior Member
I can tell you that for 100% certain the code works. The MSP430 that I programmed this for drives some LED "eyes" in a Halloween skull.
 

graynomad

Senior Member
I was commenting on the original version with half the code commented out which I think was this but I didn't keep a copy

Code:
j = 50000;
i = 20000;                              // Delay
//	do (j--);
	    do (i--);
	    while (i != 0);	
//	while (j != 0);
As such the new version is totally different, but still has problems.

do (i--);

This is not valid code, at least not with GCC. The correct format for a do loop is

do
statement
while (test);
Note that there are no ()'s after the do.

In the posted code there is essentially no while condition because the do lines had ; at the end, that means the whiles are stand alone lines of code which is not valid either.

while (i != 0);

Is valid as such but only after a do block, which is not the case in the above code mostly because of the extra ;'s as I mentioned.

Under GCC (gnu99) the code still doesn't compile. Here's a version that does

Code:
do {
   j--;
   do {
      i--;
   } while (i != 0);
} while (j != 0);
Or to be more concise

Code:
do {
   do {} while (--i);
} while (--j);
Or just for fun

Code:
do{do;while(--i);}while(--j);
Who said C was cryptic :)

Note also that the volatile keyword doesn't do any harm here but it's not required.

If you say your code compiles and does as declared in the 430 environment I believe you, it just a bit strange and not standard C or at least not standard GNU c99 C.
 
Top