returning to propeller
bozo
Posts: 70
well, I was enticed by digilent's max32 board with the pic32mx in an arduino-friendly layout supported by a cross-platform compiler, so I bought a couple of units to play with -
but after two weeks I have decided to pull the plug on this piece of rubbish, and return to the propeller
here's why, being as objective as I can be:
(a) the header pin arrangement is pathetic - in the arduino layout, there is a set of pins that aren't separated from the others by a multiple of 0.1", that means you can't easily make up a 'shield' on a piece of veroboard and plug it in - FAIL.
(b) the cross platform compiler (MPIDE) is geared towards reusing arduino code (sketches) on the pic32, and not towards anyone who wants to make full use of all the functionality on the pic32 - that is, there is no easy way to access or configure a lot of the really nice things on the pic - FAIL (maybe it will come in time)
(c) so I gave up on MPIDE and used MPLAB-X, a beta version of microchip's MPLAB that can run under OSX (or linux, or windows) ... it looks fine, except that it is still beta and there's no way on earth I can get it to detect my pickit3, ... and it seems that I'm not the only one in this situation. FAIL. ... but that's what you can expect with beta releases ...
(d) so I ran MPLAB under parallels - works fine, but I still need to use the pickit3 to program the max32. - PASS
(e) because there are so many PIC devices, there's a ton of include files to wrap your head around when writing your first code ... I literally spent half a day trying to work out where a certain definition was 'buried' ... I eventually found it in an include file inside an include file inside an include file. This is way unproductive. Probably this is OK if you spend your whole life writing PIC code, but not for me I'm afraid. FAIL
(f) I hate programming with interrupts, having been spoilt by the propeller. I should have known this would irritate me. FAIL
(g) to get the ADCs to work is a nightmare. Hundreds of configuration options. Dozens of configuration commands. Another whole learning curve thanks to the complexity of the chip. Not really a FAIL, but just IRRITATING.
(h) you have to use an external programming tool (pickit) to program the chip ... more expense ... sure you also need an external tool (prop plug/clip) for the propeller but it's way simpler, cheaper, doesn't need firmware downloads, ...
(i) and the straw that broke the camel's back: I left my board running for an hour doing nothing but flipping bits on various ports and reading an analog input ... when I returned to reprogram it, the pickit could no longer talk to it, or reprogram it, or read/verify, or clear memory ... i.e. bricked. I'd bought two of these boards so I tried everything out on the spare and it worked ok ... at least that proved my pickit was OK. But my faith in the development board was TOTALLY destroyed.
As most of you know, there's a fair amount of investment required when skilling up on a new platform. The hardware. Learning new tools. New instruction sets. New ways of doing things. Despite my investment of a couple of weeks of my time and almost a couple of hundred bucks, I have come to the point where I no longer wish to continue the investment.
I know I am going to cop flack from diehard PIC developers, but I don't care.
Everything I need to do can be done with the propeller (and some ADC chips) simpler, faster, and better than with the alternatives.
That's all the reason I need. Welcome back to the workbench Propeller. I have missed you.
but after two weeks I have decided to pull the plug on this piece of rubbish, and return to the propeller
here's why, being as objective as I can be:
(a) the header pin arrangement is pathetic - in the arduino layout, there is a set of pins that aren't separated from the others by a multiple of 0.1", that means you can't easily make up a 'shield' on a piece of veroboard and plug it in - FAIL.
(b) the cross platform compiler (MPIDE) is geared towards reusing arduino code (sketches) on the pic32, and not towards anyone who wants to make full use of all the functionality on the pic32 - that is, there is no easy way to access or configure a lot of the really nice things on the pic - FAIL (maybe it will come in time)
(c) so I gave up on MPIDE and used MPLAB-X, a beta version of microchip's MPLAB that can run under OSX (or linux, or windows) ... it looks fine, except that it is still beta and there's no way on earth I can get it to detect my pickit3, ... and it seems that I'm not the only one in this situation. FAIL. ... but that's what you can expect with beta releases ...
(d) so I ran MPLAB under parallels - works fine, but I still need to use the pickit3 to program the max32. - PASS
(e) because there are so many PIC devices, there's a ton of include files to wrap your head around when writing your first code ... I literally spent half a day trying to work out where a certain definition was 'buried' ... I eventually found it in an include file inside an include file inside an include file. This is way unproductive. Probably this is OK if you spend your whole life writing PIC code, but not for me I'm afraid. FAIL
(f) I hate programming with interrupts, having been spoilt by the propeller. I should have known this would irritate me. FAIL
(g) to get the ADCs to work is a nightmare. Hundreds of configuration options. Dozens of configuration commands. Another whole learning curve thanks to the complexity of the chip. Not really a FAIL, but just IRRITATING.
(h) you have to use an external programming tool (pickit) to program the chip ... more expense ... sure you also need an external tool (prop plug/clip) for the propeller but it's way simpler, cheaper, doesn't need firmware downloads, ...
(i) and the straw that broke the camel's back: I left my board running for an hour doing nothing but flipping bits on various ports and reading an analog input ... when I returned to reprogram it, the pickit could no longer talk to it, or reprogram it, or read/verify, or clear memory ... i.e. bricked. I'd bought two of these boards so I tried everything out on the spare and it worked ok ... at least that proved my pickit was OK. But my faith in the development board was TOTALLY destroyed.
As most of you know, there's a fair amount of investment required when skilling up on a new platform. The hardware. Learning new tools. New instruction sets. New ways of doing things. Despite my investment of a couple of weeks of my time and almost a couple of hundred bucks, I have come to the point where I no longer wish to continue the investment.
I know I am going to cop flack from diehard PIC developers, but I don't care.
Everything I need to do can be done with the propeller (and some ADC chips) simpler, faster, and better than with the alternatives.
That's all the reason I need. Welcome back to the workbench Propeller. I have missed you.
Comments
The Arduino PCB designer made a little mistake and got the spacing between two of the connectors wrong. For some reason, they've never corrected it. All the Arduino shields fit OK, of course.
The MIPS core in the PIC32 is superb - hardware multiply and divide, very fast I/O, and lots of other features. The PIC32 is a complex device, but it has a lot in it. It's faster than the Propeller for most applications, has more available memory, more I/O, and costs less. It's quite an easy device to use, primarily because of the extensive peripheral libraries that are provided.
Leon: Why are you so down on the prop? You seem to think everything else is sooo much better. Perhaps its just all the freebies they send you. Sometimes you have some great ideas, but usually it resorts to "other" chips are better. Get a life and go live on the "other" forums.
You buy an Arduino compatible platform and complain that it has this Arduino shield layout for the headers? And that it has that simplified, C like, language of the Arduino?
Then you switch to the normal Microchip C with MPLAB and complain that now is all not as simple as before. You choose a PIC32 with all this powerful peripherals included (ADCs with 1MSample for example) and complain that they must be configured with all this register bits...
beeing objective is something different for me...
I like the Propeller and it is my favorite microcontroller, but many PIC24/32 or ARMs beat the Propeller performance and cost wise in most real world applications. On the other hand the Propeller can do some things that no other uC can do and I like the lightweight IDE and programming language and so many things more...
One of the disadvantages of the Propeller is: It is hard to go back to a normal uC if you have to.
Leon Italians may be a bit strange when they elect their president, but sometimes they can also be quite clever!
The special spacing between the Arduino headers has a very good reason and is one of the better design decisions of the Arduino. Not sure how many Shield have only survived because of that idea, which makes it impossible to insert a shield in a wrong way (rotated or slightly displaced).
Andy
I like the Propeller, and often recommend it for applications to which it is suited on other forums. I get the occasional freeby from NXP for running the LPC2000 group, and other companies are very liberal with samples. Why should that influence me?
Which of those those statements of mine about the advantages of the PIC32 were wrong? Andy seems to agree with me!
Many are the demoboards from other companies that litter the path that has ultimately led me to the Propeller.
Welcome back!
It's very easy to get the PIC32 to get input from switches, flash LEDs and write text to a debug port:
/*********************************************************************************** PIC32MX Starter Kit Example Code - PORT Input Output *********************************************************************************** * FileName: port_io.c * Dependencies: None * *************************************************************************** * Description: * The example code demonstrates simple switch input methods and * methods for configuring pins as outputs. * * * *************************************************************************************/ // Adds support for PIC32 Peripheral library functions and macros #include <plib.h> // Configuration Bits #pragma config FNOSC = PRIPLL // Oscillator Selection #pragma config FPLLIDIV = DIV_2 // PLL Input Divider (PIC32 Starter Kit: use divide by 2 only) #pragma config FPLLMUL = MUL_20 // PLL Multiplier #pragma config FPLLODIV = DIV_1 // PLL Output Divider #pragma config FPBDIV = DIV_1 // Peripheral Clock divisor #pragma config FWDTEN = OFF // Watchdog Timer #pragma config WDTPS = PS1 // Watchdog Timer Postscale #pragma config FCKSM = CSDCMD // Clock Switching & Fail Safe Clock Monitor #pragma config OSCIOFNC = OFF // CLKO Enable #pragma config POSCMOD = XT // Primary Oscillator #pragma config IESO = OFF // Internal/External Switch-over #pragma config FSOSCEN = OFF // Secondary Oscillator Enable #pragma config CP = OFF // Code Protect #pragma config BWP = OFF // Boot Flash Write Protect #pragma config PWP = OFF // Program Flash Write Protect #pragma config ICESEL = ICS_PGx2 // ICE/ICD Comm Channel Select #pragma config DEBUG = OFF // Debugger Disabled for Starter Kit // The following is used by the main application #define SYS_FREQ (80000000) // IOPORT bit masks can be found in ports.h #define CONFIG (CN_ON) #define PINS (CN16_ENABLE) #define PULLUPS (CN15_PULLUP_ENABLE | CN16_PULLUP_ENABLE) #define INTERRUPT (CHANGE_INT_ON | CHANGE_INT_PRI_2) unsigned int dummy; // port_io application code int main(void) { unsigned int last_sw_state = 1; // Configure the device for maximum performance, but do not change the PBDIV clock divisor. // Given the options, this function will change the program Flash wait states, // RAM wait state and enable prefetch cache, but will not change the PBDIV. // The PBDIV value is already set via the pragma FPBDIV option above. SYSTEMConfig(SYS_FREQ, SYS_CFG_WAIT_STATES | SYS_CFG_PCACHE); // configure IOPORTS PORTD.RD0, RD1 as outputs // could also use mPORTDSetPinsDigitalOut(BIT_6 | BIT_7); PORTSetPinsDigitalOut(IOPORT_D, BIT_0 | BIT_1); // initialize the port pins states = output low PORTClearBits(IOPORT_D, BIT_0 | BIT_1); // PORTD.RD6, RD7 as inputs // could also use mPORTDSetPinsDigitalIn(BIT_6 | BIT_7); PORTSetPinsDigitalIn(IOPORT_D, BIT_6 | BIT_7); // configure the Change Notice Feature // Note: It is recommended to disable vectored interrupts prior to // configuring the change notice module, (if they are enabled). // The user must read one or more IOPORTs to clear any IO pin // change notice mismatch condition, then clear the change notice // interrupt flag before re-enabling the vector interrupts. // Enable change notice, enable discrete pins and weak pullups mCNOpen(CONFIG, PINS, PULLUPS); // Read the port to clear any mismatch on change notice pins dummy = mPORTDRead(); // Clear change notice interrupt flag ConfigIntCN(INTERRUPT); // Ok now to enable multi-vector interrupts INTEnableSystemMultiVectoredInt(); //Initialize the DB_UTILS IO channel DBINIT(); // Display a message DBPRINTF("Welcome to the PIC32 PORT input/output example. \n"); DBPRINTF("The build date and time is ... (" __DATE__ "," __TIME__ ")\n"); DBPRINTF("Press SW1 to toggle LED1, press SW2 to toggle LED2 \n"); // loop here polling for SW1, SW2 is handled by Change Notice Interrupt while(1) { if(PORTDbits.RD6 == 0) // 0 = switch is pressed { PORTSetBits(IOPORT_D, BIT_0); // RED LED = on (same as LATDSET = 0x0001) if(last_sw_state == 1) // display a message only when switch changes state { DBPRINTF("Switch SW1 has been pressed. \n"); last_sw_state = 0; } } else // 1 = switch is not pressed { PORTClearBits(IOPORT_D, BIT_0); // RED LED = off (same as LATDCLR = 0x0001) if(last_sw_state == 0) // display a message only when switch changes state { DBPRINTF("Switch SW1 has been released. \n"); last_sw_state = 1; } } }; } /****************************************************************************** * Change Notice Interrupt Service Routine * * Note: Switch debouncing is not performed. * Code comes here if SW2 (CN16) PORTD.RD7 is pressed or released. * The user must read the IOPORT to clear the IO pin change notice mismatch * condition first, then clear the change notice interrupt flag. ******************************************************************************/ void __ISR(_CHANGE_NOTICE_VECTOR, ipl2) ChangeNotice_Handler(void) { // Step #1 - always clear the mismatch condition first dummy = PORTReadBits(IOPORT_D, BIT_7); // Step #2 - then clear the interrupt flag mCNClearIntFlag(); // Step #3 - process the switches if(dummy == BIT_7) { PORTClearBits(IOPORT_D, BIT_1); // turn off LED2 DBPRINTF("Switch SW2 has been released. \n"); } else { PORTSetBits(IOPORT_D, BIT_1); // turn on LED2 DBPRINTF("Switch SW2 has been pressed. \n"); } // additional processing here... }The above C program is supplied with for use with the the little Microchip PIC32 Starter Kit. I downloaded it, compiled it with MPLAB and the free C32 compiler, and plugged my board into the USB port on the laptop. It worked immediately in the debugger without any problems. It's running at 80 MIPS, BTW. Dhrystone 2.1 performance is 1.56 DMIPS/MHz, which is a lot better than the ARM7 and the ARM9.keep the questions coming
best regards
Stefan
http://forums.parallax.com/showthread.php?132220-quot-Buggy-quot-resistive-touch-buttons-on-QuickStart
They should have used a capacitive technique, but that might have precluded using those I/Os for other purposes.
There is always this offset header from sparkfun that is supposed to work: http://www.sparkfun.com/products/9374
I've often looked at the Arduino boards and wondered why nobody corrected that error. I suppose once a mistake becomes a standard, the world is stuck with it. Still, you'd think they'd have caught it on the very first prototype boards.
The propeller is such a wonderfully easy to use platform that I prefer it, even on designs that only need a single cog or two. Only thing I wish is that Parallax made a "propeller lite", in a smaller package with half as many IO pins, half as many cores, and a built-in eeprom for small projects. I could see a whole family of products (Prop Lite, Prop I, and Prop II) to address different needs, all with the same development tools.
I knew there was some good reason for it...
The girl is the programmer.
The motorcycle is the processor
SPIN is the training wheels.
And, by the way, I will never give my advise to order the steak rare, medium rare or medium. So, I am happy to have all the propeller hats around me and be in this crowd. And I normally do not write such a statement. But I also recommend not to order a steak well done!
ErNa
Eh?
My first uC experience was a PIC :-(
16F84 in asm... memory page hassles
and that poor tired single (W)orking register..LoL
And so S..L..O..W 4mhz/4 = 1mips
I know there are PICs that are much better than that
old 8bit slowpoke but the experience left a bad taste
and I have never warmed to the others.
AVRs are nice to work with, you do have the interrupt
hassles but I am used to them. ARM is powerful but
certainly not as fun as playing with a Prop.
For personal projects I like uCs that are available as DIP
parts. So I use Prop and AVR for my simple little projects.
They are simple because my hardware skills are so limited.
I'm 95% software and 5% hardware.... I need to take some
classes or something.
There is no reason to not use several types of uC.... you can
even use them in the same project. That's often the only way
to do something properly.
I wish someone who thought out-of-the-box like Chip was running
a really large operation like TI or Microchip. Imagine the goodies that would flow
from such a setup.
I say use the best uC for the job. Sometimes the fact that you really
enjoy working with a certain uC makes it the best one for you to use...
but not the best for someone else.
Leon says: "No company has the best product! One chooses the best MCU for a particular application"
Absolutely true for a professional, or "power amateur". However, we all operate under various constraints, be it our skill, scope of acceptable solutions, dollars, geography, etc...
IMHO, some thought given to the context of a statement might considerably reduce the friction we so often see on this topic.
There is also the very real challenge of determining just was is "well suited". Had many of us given the conventional wisdom any real weight, a whole lot of stuff currently being done on Props, simply wouldn't be, and we are here to do stuff on Props, meaning that needs to be factored into the discussion in the form of a "yes, the prop can do it" bias, or what is the point exactly?
I hear the forums at embedded.com are appropriate for that.
Carry on, PH