Comparing Prop1 to Microchip® PIC32MX795F512
redheadedrod
Posts: 78
I am curious how the Prop1 stacks up to the Microchip® PIC32MX795F512
I have an application that has a premade board available based on this microprocessor. It is in an Arduino formfactor as shown here:
http://digilentinc.com/Products/Detail.cfm?NavPath=2,719,895&Prod=CHIPKIT-MAX32
This is used as the basis for a CAN based system by adding another board as shown here:
http://digilentinc.com/Products/Detail.cfm?NavPath=2,719,943&Prod=CHIPKIT-NETWORK-SHIELD
I am considering getting them for testing purposes but how does this stack up to the Propeller for speed and capability?
These two boards are used in the Open XC Platform but I would like to make a more cost effective version that would possibly be propeller based. I know from another thread that the propeller can easily handle a 500k baud CAN network but just curious at this point how it stacks up. It MIGHT be easier for me to use this other setup since it is already done but since I plan to do multiple installations it might be in my best interest to try duplicating this with a Propeller setup unless the Microchip is loads faster than the Propeller.
Theoretically I should be able to use the Network Shield listed above with the Propeller version of an Arduino compatible host board to play with it.
Rodney
I have an application that has a premade board available based on this microprocessor. It is in an Arduino formfactor as shown here:
http://digilentinc.com/Products/Detail.cfm?NavPath=2,719,895&Prod=CHIPKIT-MAX32
This is used as the basis for a CAN based system by adding another board as shown here:
http://digilentinc.com/Products/Detail.cfm?NavPath=2,719,943&Prod=CHIPKIT-NETWORK-SHIELD
I am considering getting them for testing purposes but how does this stack up to the Propeller for speed and capability?
These two boards are used in the Open XC Platform but I would like to make a more cost effective version that would possibly be propeller based. I know from another thread that the propeller can easily handle a 500k baud CAN network but just curious at this point how it stacks up. It MIGHT be easier for me to use this other setup since it is already done but since I plan to do multiple installations it might be in my best interest to try duplicating this with a Propeller setup unless the Microchip is loads faster than the Propeller.
Theoretically I should be able to use the Network Shield listed above with the Propeller version of an Arduino compatible host board to play with it.
Rodney
Comments
If you can get by with:
32K Program and data space
A slow processor by modern standards.
Some semblance of UART/SPI/I2C, USB, ADC, etc concocoted in software.
Then the Prop may well be a suitable candidate. Especially if you have some weird nonstandard real-time real-world interfacing to do.
Given the extreme simplicity of Propeller development it may well be the best choice in these circumstances.
If you need any one of:
USB 2.0 + PHY
10/100 Ethernet MAC with MII/RMII Interfaces
Approaching 512K program space
Approaching 128K working data space
16 channels of 10-bit ADC
Hardware Real-Time Clock and Calendar
A real hardware watch dog
A whole bunch UART/SPI/I2C
Then the Prop may well not cut it and the PIC may be usable in your design.
The PIC may well be overkill in the former case and may not even be usable for some "bit-twiddling" I/O.
After weighing up the basic fit of features of these devices, and others, for the application one can rule out some options and move on to comparing the remaining devices. There are costs, development costs, manufacturing complexity etc etc etc. to take into consideration.
The data sheets are out there and you know your application best. We can only offer hand waving advice.
Your post seems to be more concerned with using dev boards and modules rather than actual chips so this makes any comparisons even harder.
Which part of your design do you want to replace with Props? All of it? Some interface or other?
Sounds like you already have the application code written so you know what resources it requires.
They appear to be intruding into Propeller territory...
Hope Prop2 comes soon...
This will be mostly for entertainment purposes and some developmental work. Due to the nature of how a PC works I choose NOT to use it for mission critical stuff...
I will be replacing some of the functions in my truck with computers such as the dash cluster and the HVAC controls. I will be installing an ARM based low power computer in the over head console and will be installing one into the Dash Cluster. The over head unit will have a 7" touch screen attached and it will be used to control the HVAC system, make system wide chances and may be used to do some other stuff as well. I am looking to install Android on it and use some Android features.
The Dash Cluster will have 2 flat screen monitors overlaid over the original cluster to display the information digitally which will allow me many new options. I am not totally yanking the cluster because I want to be able to reverse the install back if I decide to in the future.
Both of the ARM boards I am using have SPI interfaces and CAN interfaces. For the dash all of the displays are either read from the CAN bus or are direct lines from the BCM. So I need an interface that can read the very slow CAN data (1kBaud). All of the cluster bulbs are driven directly from the BCM so I need to have a digital detection of these on and off conditions.
For the over head console stuff some of the items are communicated via CAN and others are directly controlled. So for the HVAC system I am considering using a Propeller solution to replace the currently controller setup which has a CAN bus and some direct controls to drive solenoids and actuators. These will be controlled by the ARM board but the actual work being done by Propellers. I can then also include some temp sensors and do a pseudo auto temperature control system since the unit in my truck is manually controlled currently.
This is the current plan anyhow. The PIC32 is a new chip to me and It looked like from the specs it would do the job better than a Propeller but then again the Propeller can have its memory expanded and wasn't sure with the 8 core system if it would be in the same ball park or not.
I have nothing currently coded but I have plans.. Just not enough time at the moment.
I guess what I am curious about with this is if it would be possible to get the same performance out of a Propeller in a similar setup as to the one mentioned using the PIC32. Because I hope to integrate the computers into the system seamlessly I am still searching out my options. I am not really attached to anything at this point but the Propeller has been my preferred micro controller at this point even though I have not even powered up a Propeller chip yet and only have gotten about a quarter of the way through the programming guide.
I just know I will likely have 3 different layers of computers in my truck.
PC mostly for entertainment but also for development and to load software on the other devices when necissary.
ARM based boards either running Linux or Android. These will drive screens and HMI devices.
Micro controller Devices. At the moment I believe the Propeller is the way to go. I will be either supplementing or replacing some OEM components doing simple things with Micro Controllers. Those same micro controllers can access multiple IO lines to manipulate switches/solenoids or read in sensors.
Rodney
start here: Introduction to TACHYON Forth (links to files)
http://forums.parallax.com/showthread.php/141061-TACHYON-a-very-fast-and-compact-Forth-SDFS-TELNET-FTP-WEB-servers-EMAIL/page1
http://forums.parallax.com/showthread.php/157792-Interactively-test-WS2812-NeoPixel-LEDs-with-Tachyon-and-serial-terminal
Dropbox files and binaries (latest)
1. you get to know a quite different programming paradigm - always good for a SW professional ;-)
2. Peter has build a very compact and very capable system (there is a WebServer already) and soon I expect it to support some kind of wireless as well. (bluetooth is already there)
so you can access it with a Tablet or SmartPhone and soon via WLAN as well - might be an alternative to wires for the GUI.
3. it is quite fast compared to SPIN and much easier than PASM - but still with the PASM option should you need it.
4. SD file system is seamless for logging, extended config, etc. very simple to use.
5. etc. ...
I played with forth 20 years ago for about 2-3 weeks so I am sure I don't remember anything...
The SD card extension sounds interesting...
Are you saying this is faster than Spin? Faster than compliled C/C++?
I am likely going to plan to use C/C++ to practice but I am not totally against another language.
But I do plan to learn spin first so I know how to handle these things.
Does Forth fully support everything that Spin or C/C++ does? If I read right Parallax is moving away from spin and to C/C++.
Sounds like I am not going to get a real good idea the difference unless I buy the Pic32 setup and get it up and running then try to do the same with a Propeller and go from there. I am expecting the above mentioned Pic32 setup is way over kill for the project and that a Propeller properly setup will work just fine but guess there is no way to know without trying.
Rodney
Especially in the prototyping phase it is very easy to enter commands, and code sequences on the prompt and see the result.
and this while the background processes are running.
And if you are satisfied you just make a definition (word) out of it and the system has grown a little.
just have a look at: Introduction to TACHYON Forth (links to files)
Full access to counters / timers / IO from the command prompt.
just download it and give it a try ... only PropellerTool is needed to load the Image or the Tachyon.spin source code
A definition is similar to an object I assume?
When I say object I mean like a C++ object. Haven't gotten far enough into the spin book to know how those objects really work. I have an idea but too busy at the moment playing with Assembly Language and Databases in my classes this semester so I haven't had time.
Rodney
It may well make use of bytecodes or some such under the hood but that's still interpreted in my book. There may well be ways to compile Forth source to native binary executables, I have no idea really, but I'm sure that is not what is happening with the Propeller Forths.
Often the "heavy lifting" is done by defining words in assembly language. Things like I/O or stuff that needs performance.
A Forth definition is not an object like a C++ class/object. It is simply a definition of some functionality that takes it's parameters from whatever is on the stack at the time and delivers it's results back to the top of stack. Except for I/O and such like. More like a function.
Spin has objects. A Spin source file is sort of like a C++ class definition. The file name is akin to a class name and the PUB functions within the file are akin to methods. One can instantiate multiple instances of a Spin object. Such instances will have their own separate private data as defined in the VAR sections but the data in DAT sections is shared between all instances.
Unlike C++ there is no idea of inheritance in Spin objects. Spin objects are not data types that can be passed around/copied etc as variables as in proper object oriented languages.
Great for interactive development and debugging.
All the major blocks, that need to be really fast are coded in assembler, but the user doesn't need to care.
For him those is just embedded funtionality he/she can use.
Like SPI, SD, PWM,Filesystem, Ethernet, WebServer, FTP-Server etc.
And if you really need a special really fast driver then you can easily code it in PASM and use it. Like Peter has shown for the new LED driver.
And as you can do in SPIN as well.
Just that Tachyon is faster than Spin and INTERACTIVE ...
a definition or WORD as it is called in Forth is like a subroutine or function, that can take as many parameters as it likes from the stack
and leave as many results as it likes on the stack, when it is done.
So no need for explicitly passing arguments.
This makes WORD definitions quite simple. You just specify which other words to call in a sequence.
A word or 'program' so is just a sequence of other words - which kind of make a sentence.
It took me a while to get used to this. But it is actually like defining new words in a language, that you can then use to say s.th. meaningful.
You define your own problem specific vocabulary, and then you can very easily say, what needs to be said.
Sometimes really looking like a sentence.
In the beginning it can be a little hard to get used to the explicit handling of the stack.
But when you define the words bottom up. And nicely factored, then you will not see much of the stack handling.
If you want to write some kind of spagetti-code then you will be in trouble ...
http://forums.parallax.com/showthread.php/156364-Speed-of-PropForth-vs-Spin?p=1277237&viewfull=1#post1277237