The bottom line is that there are a lot of quality microcontrollers out there. Any company that produces them will certainly consider including a feature if there are enough people out there who will pay money for it. That said, given a nice variety of design choices, it is a simple matter to choose the product that meets your needs. It doesn't really matter if some competitor has some other feature or capability or does something better. If another brand does something better for you, then by all means go out and buy the other brand.
I'm not particularly interested in how the microcontrollers I choose don't stack up to something else. The people who want those specific features should go to those products. I'm on this forum because 1) I want to know what great ideas people share about what they have achieved with propeller, 2) I want to help other people with their problems and 3) As a hobbyist, I like to ask for help from people with more expertise than me from time to time.
@jvrproductions
@4x5n
There have been some formal announcements in the last couple of months that Parallax is committed to having versions of "What's a Microcontroller?" for the Propeller as well as upgrading their educational offerings in general for the Propeller. If you haven't seen it yet, take a look at their new educational website which features projects done for the Stamps, Propeller, and Arduino. It will take some time, but I'm sure the rich library of translated tutorials will get upgraded as well.
Others,
This thread has reached the point where personal attacks have surfaced. If all parties involved would show a little restraint, we can continue. If not, the thread will become locked. Enough said?
I been to the learn site and it's better every time I go there it's a better then before. Do you know if there are any plans of gather the "lesson" together and make them available in book form? I realize it's to early for that as it's not complete yet. I sometimes feel like I'm the only one left in the world that prefers reading documentation, etc in paper book form vs a PDF on a computer screen! Getting a PDF printed and bound in single quantities is stupidly expensive and I've never pulled the trigger on doing it.
I'm not certain, but I believe the <learn.parallax.com> website is seen as a way to get this information in the hands of users as quickly as possible and serve as a way to refine the material over time until it's stable and polished enough to collect in PDF and book form. This is something Parallax has done before and seems to have worked well. All three media (on-line chapters, PDF, and paper book form) are useful to different people.
I'm not certain, but I believe the <learn.parallax.com> website is seen as a way to get this information in the hands of users as quickly as possible and serve as a way to refine the material over time until it's stable and polished enough to collect in PDF and book form. This is something Parallax has done before and seems to have worked well. All three media (on-line chapters, PDF, and paper book form) are useful to different people.
I'd like to make it clear that my wish for more "printed" books and documentation is a frustration of mine that goes way beyond the propeller and Parallax! It's also not a reflection on them. The sad reality is that more and more printed manuals are being replaced by PDFs and more and more the PDFs have to be downloaded from a website. :frown: I don't like it but it is what it is and I know a lot of people that prefer it this way.
One of the things I like about the PEK (Profession Education Kit) is the "lay flat" spiral bound book that comes with it!! At ~$100 it's in fact cheaper then the propboe board the learn site seems to be tailored to.
There are cetainly applications where the 50c processor is a better choice than the Propeller. There are also cases where the Prop is a better choice than the 50c processor. In fact, I can see where the Prop + 50c might be a really good combination. This would allow the Prop to use all 8 cogs for other things that it does best.
.
This thread has really jumped the track. Originally it was whining about the failings of Parallax to provide ..... For a chip this simple, does anyone really want a 500 page manual to design with it. How many of you out there really read all that s--t anyway? Only for power, pin outs, getting started and then as needed. IMHO, if ya wanna learn, just do it. If you do not like it, vote with your $$$.
Processor X fanboys, it is one thing to say "Hey, this may help you out and it is cheap and can do X!!" This has been done for a long time, and is really what distributed processing is all about. (Check out Caxton Fosters book on realtime programming for some of this). But most of us can generally decide if that is right for what our own project or product will need and can even figure out if the extra real estate and code development and configuration management costs and ...... associated with another intelligent device in the mix makes sense economically. Make your point and then move on.
Instead this thread which may actually contain some good ideas had been subverted into attempts at driving business to other than parallax makers (tacky at best since it is a parallax forum), driven down the debugging road, when that part of the discussion should have been forked off to another thread dedicated to debuggers and there pros/cons, etc. Beyond that, it has presented some interesting entertainment value. Of course I doubt uC will include the corn handling features as they may run to cross purposes with the companies drive on a lower power footprint.
Perhaps the moderators could have forked off the debug discussion and such to another thread.
On what devices have you found JTAG to be too slow? I've used it on lots of high-speed systems with various IDEs and JTAG interfaces and have found it to have no effect whatsoever on performance. Updating of registers and variables in the IDE when execution is halted or the device is single-stepped takes place instantaneously.
One advantage of getting old is the amount of experience that one accrues.
A pretty good answer was already given some time ago. Here is an excerpt:
On my desk right now are an ARM7 and a Prop. They are tied together by an SPI. Debugging of the ARM is via JTAG, and debugging of the Prop is via video from a single cog. The video connection allows me to monitor anything I specify, in real-time, real fast, without having to stop execution. JTAG, on the other hand, is strictly post-mortem. I have to stop execution to view anything meaningful. (Semi-hosting is a joke. It's far too slow, and dogs down the processor so badly that the results I DO get are completely artificial.)
Unfortunately for post-mortem inspection, the rest of the world doesn't stop. It is a ridiculous way to 'view' what is going on. The beauty of the Prop is that the cog providing diagnostic I/O is utterly transparent (to the point of invisibility) to the other operations on the chip, and yet can provide monitoring as fast as 32-bits per microsecond.
In fact the Prop is so effective as a debugging tool that I now use it to debug the ARM7. All the remaining bugs are in the ARM code, anyway.
The problems with JTAG are 1) that it is too slow and 2) if magically it were made fast, servicing it would burden the processor so much that the results would be artificial.
A spare COG, otoh, can 1) provide any one of several very fast links and 2) be completely transparent to the code being developed and to the processor(s) executing that code. You simply can't beat multiple processors.
Of course the nature of a project can vary across magnitudes of complexity and temporal precision. If all you are doing is reading an ADC and blinking a few lights...who really cares? Use a bug light for all it matters.
But if you are developing an OFDM modem, JTAG is just wasted gates and i/o pins.
At the risk of upsetting Heater may I suggest that in your retired state you really aren't dealing with the same sorts of problems that I am. Your various flavors of advice may be fine for individuals trying to re-purpose the keypad of a microwave oven, but are pretty much balderdash in other venues.
XMOS threads are equivalent to Propeller cogs (they are much faster, though) and if they were better for debugging than using a cog/thread, XMOS would have used one for debugging.
XMOS uses one core and multiple thread. This is not the same as many one-threaded cogs. A thread is executed on the same core and it interferes with other threads. A cog running debugger don't interfere with another cog.
If one buggy procedure hang one-core processor, what can a thread do on a hung processor? Then, special debug interfaces like jtag are much more useful in one core processors/microcontrollers. In the Propeller, you can debug an object using one or two.. or maybe more additional cogs, so any special debug interfaces are much less useful than in one-core processors.
Also, object-oriented Propeller program structure allows debugging one object at once.
So, if asked what I prefer in Prop2 - jtag interface or more ram - using the same silicon area - I choose more ram
I work every day with JTAG on FPGAs and some micros --- and I can say as on micros -- it give not so much help .. On FPGAs that is other thing as I in time of build VHDL program I can attach any signal I wish to it.
On micros it give boundary scan on PINs ---> that I can simple have on Propeller on any type of output not only JTAG.
To be possible to scan on micros other things that PINs --- needs additional programing (Any sort of debug program that runs on that micro).
So say me what can You with JTAG that I can't with singe cog programed for scaning all pins and some HUB variables that other COGs fill to give me all info I need for debugging --- And still I can use one COG as Monitor --> TV else VGA --- without need of additional hardware !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Great, but there is no JTAG on P1 or P2. We know this. Doesn't matter much whether or not it's great, does it, unless people want to go off and use other devices, which they are free to use.
Here we are using Propeller devices. Maybe we should start a debugging thread and go down that road. There are a lot of options on Propellers, ranging from a simple terminal, to cogs monitoring other cogs, viewport, PASD, etc...
Seems to me, having a "why the Prop frustrates" thread should be followed by solutions, or it's just an annoyance.
Here we are using Propeller devices. Maybe we should start a debugging thread and go down that road. There are a lot of options on Propellers, ranging from a simple terminal, to cogs monitoring other cogs, viewport, PASD, etc..
See my earlier post - the Prop 2 info says this :
Chip-To-Chip Communication
Each cog now also features high-speed serial transfer and receive hardware for chip-to-chip communication. The hardware requires three I/O pins (SO, SI, CLK).
so that will have more speed than Generic JTAG, and logically lead to using a second Prop 2 as a Debug-Host.
Anyone got a guess on when the first USB COG driver will appear for Prop 2 ?
Great, but there is no JTAG on P1 or P2. We know this. Doesn't matter much whether or not it's great, does it, unless people want to go off and use other devices, which they are free to use.
Here we are using Propeller devices. Maybe we should start a debugging thread and go down that road. There are a lot of options on Propellers, ranging from a simple terminal, to cogs monitoring other cogs, viewport, PASD, etc...
Seems to me, having a "why the Prop frustrates" thread should be followed by solutions, or it's just an annoyance.
Yes, there is no JTAG and there are no interrupts, debug flags or other hardware as in other microcontrollers (such as Renesas M16...). So you will always have to use one of the Cogs at the propeller and do some software debugging.
And yes there are many ways to debug somehow, but not a complete and comfortable one.
Simple Terminal: A lot of manual work required. Only spin.
PSTDebugLITE: Much better. But very large because all the string checkings/conversions are done on the chip. Only spin.
PASD: Pretty good. Unfortunately, a separate application. No built-in editor. PASM only.
Viewport: The best solution for spin until now. Still manual work required (vp.config, vp.share, ...). Sometimes very unstable. The editor is not as nice as in the PropTool (e.g. bad typeface). Spin only.
Desirable solution would be:
A mixture of PASD and viewport with the handsome editor with its block-group indicators from the PropTool. Directly click in the code set breakpoints and makes all necessary changes in the code for debugging. Right-click or drag and drop adding variables to the Watch window, as in other IDE's. In the watch window settings for displaying the variables are made (decimal, hex, char ...). A real IDE.
If it increases the stability I would leave out the single-step debugging.
Question is: who can and will/want make such a solution for how much money?
I personally would like to see the simulator expanded where needed and coupled into something like that for a complete virtual environment, sort of like where GEAR was going.
I personally would like to see the simulator expanded where needed and coupled into something like that for a complete virtual environment, sort of like where GEAR was going.
It will never hit full speed, but silicon-assisted simulation is a great way to KNOW you are interacting correctly, at least as speed allows.
Using these opcodes, you get a lot fo DEBUG choices
Table 18: Chip-To-Chip Communication Instructions Machine Code Mnemonic Operand Operation
000011_zc0_1_cccc_ddddddddd_000001001 SNDSER D
Sends a long (D) out of the special chip-to-chip serial port. Blocks until the long is sent. Use C flag to avoid blocking.
000011_zc1_1_cccc_ddddddddd_000001001 RCVSER D
Receives a long (D) in from the special chip-to-chip serial port. Blocks until the long is received. Use C flag to avoid blocking.
000011_zcn_1_cccc_ddddddddd_011101010 SETSER D/#n
Sets up the serial port I/O pins to use for SO, SI, and CLK given D or “n (0-63)”.
a) You can spit any single watch value from inside a loop, at a cost of 1 long in code, and the shift overhead in time. Place it right before a WAITxx opcode, and there may often be no time-cost.
b) Or you could do something along these lines
RCVSER #Adr_p3 ; Load Soft Opcode Line 3
RCVSER #Adr_p2 ; Load Soft Opcode Line 2
RCVSER #Adr_p1 ; Load Soft Opcode Line 1
Adr_p1 : <user opcode>
Adr_p2 : <getflags> ; Typically a GetFlags so the simulator can track the CC decisions, and 'feed' the correct next opcode
Adr_p3 : <user response> ; Typically a SNDSER WatchAddress, or a JMP -4 for fastest write only streaming
JMP #Loop
Self-modify code could work, with the caveat you avoid this nano-debug-stub area of ~7 longs.
This is slower than native code, but still likely to be way faster than any PC screen, > 1 MIP is doable ?
To sustain 1MIP, you need a > 100MBd link, which means the inner 'feeder' would better be another Prop 2, than a USB link
Trade off here is you get 100% silicon execution, but need a fast link.
c) or a variant of b) that only feeds Physical access opcodes to the target, and simulates all other operations.
Requires better Sim quality, as you no longer have 100% silicon execution, but you gain lower link bandwidth.
I like "silicon assisted" quite a lot actually! My motivation for a virtual simulation is for educational purposes, and to assist in developing lots of stuff that isn't necessarily I/O state dependent.
So much is going to be possible on that next instruction set! Agreed on potential scope of solutions.
I just got the prop, and ran through the quickstarts. I got some leds to flash. I also put "hello world" on the pst, and now I'm looking to learn more.
Except I hear there is no more. I'm suppose to come to the forums and ask questions. Okay.
Can someone explain better how to put programs in different cogs?
And how do I get them to share information with each other?
Also, how do I create a random number from 1-10?
Read information from a sensor?
Create multidimensional arrays?
BTW, I know very little C. Enough to know I don't like it.
There needs to be some sort of "cross-over" document to assist new users in taking advantage of the existing materials. It isn't obvious to a new person that these materials are compatible.
Time for KickStarts!! Has examples for most of the sensors Parallax sells plus servos, LCDs, etc.
The PEK mentioned above has lots of good info on SPIN and how to get multiple COGs going.
Nobody is going to force you to learn C. (or PropForth, or Basic)
Is there something in particular you are interested in?? Did you check out the examples that come with the Spin Tool? Did you go browsing through the Object Exchange (OBEX) yet?
Lots to do, too much to do, not enough time to do it all........hey, THAT'S what frustrates me about the Propeller!!! So much to do, so little Propeller time!!!
Comments
I'm not particularly interested in how the microcontrollers I choose don't stack up to something else. The people who want those specific features should go to those products. I'm on this forum because 1) I want to know what great ideas people share about what they have achieved with propeller, 2) I want to help other people with their problems and 3) As a hobbyist, I like to ask for help from people with more expertise than me from time to time.
I been to the learn site and it's better every time I go there it's a better then before. Do you know if there are any plans of gather the "lesson" together and make them available in book form? I realize it's to early for that as it's not complete yet. I sometimes feel like I'm the only one left in the world that prefers reading documentation, etc in paper book form vs a PDF on a computer screen! Getting a PDF printed and bound in single quantities is stupidly expensive and I've never pulled the trigger on doing it.
I'd like to make it clear that my wish for more "printed" books and documentation is a frustration of mine that goes way beyond the propeller and Parallax! It's also not a reflection on them. The sad reality is that more and more printed manuals are being replaced by PDFs and more and more the PDFs have to be downloaded from a website. :frown: I don't like it but it is what it is and I know a lot of people that prefer it this way.
One of the things I like about the PEK (Profession Education Kit) is the "lay flat" spiral bound book that comes with it!! At ~$100 it's in fact cheaper then the propboe board the learn site seems to be tailored to.
I'm reading from the internet, from downloaded PDFs, from ebooks all the time.
You still can't beat a good book on real paper.
UUHHHHHHHH, Yep....
This thread has really jumped the track. Originally it was whining about the failings of Parallax to provide ..... For a chip this simple, does anyone really want a 500 page manual to design with it. How many of you out there really read all that s--t anyway? Only for power, pin outs, getting started and then as needed. IMHO, if ya wanna learn, just do it. If you do not like it, vote with your $$$.
Processor X fanboys, it is one thing to say "Hey, this may help you out and it is cheap and can do X!!" This has been done for a long time, and is really what distributed processing is all about. (Check out Caxton Fosters book on realtime programming for some of this). But most of us can generally decide if that is right for what our own project or product will need and can even figure out if the extra real estate and code development and configuration management costs and ...... associated with another intelligent device in the mix makes sense economically. Make your point and then move on.
Instead this thread which may actually contain some good ideas had been subverted into attempts at driving business to other than parallax makers (tacky at best since it is a parallax forum), driven down the debugging road, when that part of the discussion should have been forked off to another thread dedicated to debuggers and there pros/cons, etc. Beyond that, it has presented some interesting entertainment value. Of course I doubt uC will include the corn handling features as they may run to cross purposes with the companies drive on a lower power footprint.
Perhaps the moderators could have forked off the debug discussion and such to another thread.
FF
Yeah,
Kinda hard to pull the workstation into the "reading room".
FF
Sorry got ahead of myself on that one having posted of the thread jumping the track. My bad......
A pretty good answer was already given some time ago. Here is an excerpt:
The problems with JTAG are 1) that it is too slow and 2) if magically it were made fast, servicing it would burden the processor so much that the results would be artificial.
A spare COG, otoh, can 1) provide any one of several very fast links and 2) be completely transparent to the code being developed and to the processor(s) executing that code. You simply can't beat multiple processors.
Of course the nature of a project can vary across magnitudes of complexity and temporal precision. If all you are doing is reading an ADC and blinking a few lights...who really cares? Use a bug light for all it matters.
But if you are developing an OFDM modem, JTAG is just wasted gates and i/o pins.
At the risk of upsetting Heater may I suggest that in your retired state you really aren't dealing with the same sorts of problems that I am. Your various flavors of advice may be fine for individuals trying to re-purpose the keypad of a microwave oven, but are pretty much balderdash in other venues.
http://www.xmos.com/news/01-may-2012/xmos-simplifies-audio-system-design-real-time-debugging-tools
XMOS threads are equivalent to Propeller cogs (they are much faster, though) and if they were better for debugging than using a cog/thread, XMOS would have used one for debugging.
Altera has their SignalTap which also uses JTAG:
http://www.altera.com/literature/an/an323.pdf
If one buggy procedure hang one-core processor, what can a thread do on a hung processor? Then, special debug interfaces like jtag are much more useful in one core processors/microcontrollers. In the Propeller, you can debug an object using one or two.. or maybe more additional cogs, so any special debug interfaces are much less useful than in one-core processors.
Also, object-oriented Propeller program structure allows debugging one object at once.
So, if asked what I prefer in Prop2 - jtag interface or more ram - using the same silicon area - I choose more ram
JTAG can be used to debug multi-core and multi-chip systems, such as a single-multi-core device, an array of processors, or several FPGAs.
The extra hardware required for JTAG is quite minimal, far less than devoting a whole cog to the debugging function.
I work every day with JTAG on FPGAs and some micros --- and I can say as on micros -- it give not so much help .. On FPGAs that is other thing as I in time of build VHDL program I can attach any signal I wish to it.
On micros it give boundary scan on PINs ---> that I can simple have on Propeller on any type of output not only JTAG.
To be possible to scan on micros other things that PINs --- needs additional programing (Any sort of debug program that runs on that micro).
So say me what can You with JTAG that I can't with singe cog programed for scaning all pins and some HUB variables that other COGs fill to give me all info I need for debugging --- And still I can use one COG as Monitor --> TV else VGA --- without need of additional hardware !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
It's very fast.
No extra programming is required.
No additional hardware is required.
Easy to use.
No waste of resources.
Most 32-bit MCUs and FPGAs use it.
It can be used with entire systems with multiple MCUs and FPGAs for board-level testing.
Most engineers are familiar with it,
Why doesn't Parallax have a document on debugging techniques?
Exact!
Debugging with terminal is time-consuming and awkward.
Here we are using Propeller devices. Maybe we should start a debugging thread and go down that road. There are a lot of options on Propellers, ranging from a simple terminal, to cogs monitoring other cogs, viewport, PASD, etc...
Seems to me, having a "why the Prop frustrates" thread should be followed by solutions, or it's just an annoyance.
See my earlier post - the Prop 2 info says this :
Chip-To-Chip Communication
Each cog now also features high-speed serial transfer and receive hardware for chip-to-chip communication. The hardware requires three I/O pins (SO, SI, CLK).
so that will have more speed than Generic JTAG, and logically lead to using a second Prop 2 as a Debug-Host.
Anyone got a guess on when the first USB COG driver will appear for Prop 2 ?
Maybe some programmers in Parallax are writing it right now
Yes, there is no JTAG and there are no interrupts, debug flags or other hardware as in other microcontrollers (such as Renesas M16...). So you will always have to use one of the Cogs at the propeller and do some software debugging.
And yes there are many ways to debug somehow, but not a complete and comfortable one.
Simple Terminal: A lot of manual work required. Only spin.
PSTDebugLITE: Much better. But very large because all the string checkings/conversions are done on the chip. Only spin.
PASD: Pretty good. Unfortunately, a separate application. No built-in editor. PASM only.
Viewport: The best solution for spin until now. Still manual work required (vp.config, vp.share, ...). Sometimes very unstable. The editor is not as nice as in the PropTool (e.g. bad typeface). Spin only.
Desirable solution would be:
A mixture of PASD and viewport with the handsome editor with its block-group indicators from the PropTool. Directly click in the code set breakpoints and makes all necessary changes in the code for debugging. Right-click or drag and drop adding variables to the Watch window, as in other IDE's. In the watch window settings for displaying the variables are made (decimal, hex, char ...). A real IDE.
If it increases the stability I would leave out the single-step debugging.
Question is: who can and will/want make such a solution for how much money?
It will never hit full speed, but silicon-assisted simulation is a great way to KNOW you are interacting correctly, at least as speed allows.
Using these opcodes, you get a lot fo DEBUG choices
a) You can spit any single watch value from inside a loop, at a cost of 1 long in code, and the shift overhead in time. Place it right before a WAITxx opcode, and there may often be no time-cost.
b) Or you could do something along these lines
RCVSER #Adr_p3 ; Load Soft Opcode Line 3 RCVSER #Adr_p2 ; Load Soft Opcode Line 2 RCVSER #Adr_p1 ; Load Soft Opcode Line 1 Adr_p1 : <user opcode> Adr_p2 : <getflags> ; Typically a GetFlags so the simulator can track the CC decisions, and 'feed' the correct next opcode Adr_p3 : <user response> ; Typically a SNDSER WatchAddress, or a JMP -4 for fastest write only streaming JMP #LoopSelf-modify code could work, with the caveat you avoid this nano-debug-stub area of ~7 longs.
This is slower than native code, but still likely to be way faster than any PC screen, > 1 MIP is doable ?
To sustain 1MIP, you need a > 100MBd link, which means the inner 'feeder' would better be another Prop 2, than a USB link
Trade off here is you get 100% silicon execution, but need a fast link.
c) or a variant of b) that only feeds Physical access opcodes to the target, and simulates all other operations.
Requires better Sim quality, as you no longer have 100% silicon execution, but you gain lower link bandwidth.
I see plenty of scope for solutions....
-browz
Is that a 'Guardian Angels' beret you wear?
-browz
I like "silicon assisted" quite a lot actually! My motivation for a virtual simulation is for educational purposes, and to assist in developing lots of stuff that isn't necessarily I/O state dependent.
So much is going to be possible on that next instruction set! Agreed on potential scope of solutions.
Except I hear there is no more. I'm suppose to come to the forums and ask questions. Okay.
Can someone explain better how to put programs in different cogs?
And how do I get them to share information with each other?
Also, how do I create a random number from 1-10?
Read information from a sensor?
Create multidimensional arrays?
BTW, I know very little C. Enough to know I don't like it.
LIES!
http://www.parallax.com/Portals/0/Downloads/docs/prod/prop/PEKitLabs-v1.2.pdf
And the source code:
http://www.parallax.com/Portals/0/Downloads/docs/prod/prop/SourceCodePEKitLabsFundamentalsv1.2.zip
OBC
The PEK mentioned above has lots of good info on SPIN and how to get multiple COGs going.
Nobody is going to force you to learn C. (or PropForth, or Basic)
Is there something in particular you are interested in?? Did you check out the examples that come with the Spin Tool? Did you go browsing through the Object Exchange (OBEX) yet?
Lots to do, too much to do, not enough time to do it all........hey, THAT'S what frustrates me about the Propeller!!! So much to do, so little Propeller time!!!