Purchasing Propellers
littletransistor
Posts: 25
Hey there,
I'm planning to purchase some Parallax Propellers, and also the programmer as well later this week.
About the crystals, should I need exactly 5MHz? I have a lot of 10MHz crystals and feel like using them instead.
Also, upon building my own Propeller board, with the EEPROM, so I can instantly 'burn' the code into the EEPROM without going through the settings of the I2C and others? The thing will just auto-detect the EEPROM upon connection? I'm a bit confused of the program code storage since I'm from the other micrcon world, called PIC microcontrollers.
Thanks.
I'm planning to purchase some Parallax Propellers, and also the programmer as well later this week.
About the crystals, should I need exactly 5MHz? I have a lot of 10MHz crystals and feel like using them instead.
Also, upon building my own Propeller board, with the EEPROM, so I can instantly 'burn' the code into the EEPROM without going through the settings of the I2C and others? The thing will just auto-detect the EEPROM upon connection? I'm a bit confused of the program code storage since I'm from the other micrcon world, called PIC microcontrollers.
Thanks.
Comments
You can program that to RAM for initial test/experiments and then build up from there.
I used a 10MHz crystal on there with a PLL8 setting. Now a days I use 6.5MHz xtals for 100MHz operation, but you really need a PCB and good decoupling capacitors for that.
As for the EEPROM, just connect it and it "just works".
Have fun.
I see. Well, does that allow more expansion space for more memory? Cause I'll be putting another empty slot next to the 24LC256 to increase the program code space.
Also, how difficult is the assembly in the Propeller? I worked with the PIC18F and 68HC11 assembly only. The PIC16F is very painful and I don't really enjoy that - bankswitching isn't fun and it's error-prone, in my opinion.
I see. Thanks.
By the way, there is not much Parallax Propellor development in colleges in the country I currently reside, Malaysia. I would be introducing the Propellors for the final year students, especially for those without much background on Microcontrollers.
I had students from Mechanical Engineering who had problems with complex interfacing which involves 8-bit platforms, and that is why I'm trying to introduce the Propeller to them.
Is it a good idea? Opinions?
Not sure about the memory expansion (EEPROM) but it must be doable. I'm sure I have heard of people using 64K EEPROMs or you could hang more devices off those pins as you suggest.
BEWARE, this will NOT magically increase the program code space. Not if you are working in regular Spin which is loaded to and run from 32K HUB RAM. The Prop Tool cannot create bigger Spin programs anyway.
Assembly language on the Propeller is very easy. Many, including myself, say that it is the most easy to learn and use assembly language having had much experience with many other processors. The instructions are very regular with few surprises.
The fact that you can program multiple independent activities in different COGs and not have to worry about interrupts and timing being upset is a key benifit here.
I belive the Propeller is an excellent introduction for students.
You might have to say more about the interfacing problems of your Mechanical Engineering students before we can comment on that.
But the Prop has been interfaced to all kinds of robots and machines, CNC mills for example.
Thanks. The 32K program memory space will be very, very sufficient for learning purposes.
I might introduce the Propeller to the students due to the simplicity of the Spin language provided.
The projects? We are not decided yet. It's just the start. I could provide examples, such as the general tachometer and some areas in mechatronics.
Also, the processor itself can be extended into other fields like Biomedical Instrumentation too, where this processor can do video output to a monitor. (example - user interface in a patient monitor)
Btw, could I mix ASM with Spin in this system, like the other popular microcontrollers in market?
The Prop has been used professionally for mechatronics in movies so that sounds like a great idea. Can't find any links for that just now.
Normally one does not mix assembly language with Spin in the usually understood way (inline asm).
Mostly one starts the PASM part of your objects running in a entirely new COG. It then runs in parallel with your Spin code and they communicate through some shared HUB RAM.
However there is a thread going on now about how to make one off calls to PASM functions from Spin. See here: http://forums.parallax.com/showthread.php?t=125599
Thanks for the help. I'll try building up a proto-board first. I have a lot of ideas for the propeller microcontroller.
At least it (temporarily) relieves the idea of having the RTOS or tightly timed interrupts in other single cores as I'm not pretty experienced in that. (As far as I know, only one lecturer in my college seems to know it best)
Btw, does the company integrates the A/D converters, and the SPI/I2C/UART hardware interfaces into the microcontroller in future? I noticed that the current propellers doesn't contain any of those right now. If they have, that will be something much greater than any low-end microcontrollers which in the market now.
No. And intentionally no. And not in the forthcoming Prop II either.
The fundamental idea of the Propeller is that it has no, or very little, special purpose hardware. Instead you have 8 processors. One or more of those is usually running your applications main or higher level logic. The others are then programmed to be whatever kind of peripheral interface you want. In this way the device is very flexible and designs can grow and evolve and change with out having to source a different chip for each hardware interface configuration.
So if you need a UART, just use a software UART running in a COG. If you need SPI or I2C just run a software implementation.
You will find many such interfaces already made, and free to use, in the Propeller Object Exchange (OBEX). In this way the Prop has been used to interface to PWM servos, SD card storage, and many other devices.
This has it's limits of course, implementing device logic in software is not as fast as real silicon so for example USB is a bit of a problem. But even that has been done.
When you get used to this "software defined silicon" you will never look back.
I see. Well, I wouldn't worry too much about this one since it has many other processors. In fact, I feel that the absence of those hardware makes it even more flexible and make the processor design more simplistic.
So, I bet in the OBEX, they have SPI/I2C drivers written already? So that I can just put it into one reserved core? Or I have to write these down as well? Thanks.
Exactly. And the fact you can do all of this without worrying about interrupts and real time operating systems is a huge bonus. Especially for those new to micro-controllers.
Yes. It's good to have a look through the OBEX before doing anything. Or ask here on the forum for any driver/interface functionality you may need. I find that pretty much anything I want to do has been done before:)
Don't forget the object examples supplied with the Propeller Tool. A good starting point.
In today's world, having to write self-modifying code certainly seems strange.
If you compare the Propeller though to older micro-coded RISC-like processors with hub memory serving as main memory, the Propeller really isn't much different. The RDxxxx/WRxxxx instructions get their hub address indirectly. In these older processors, the microcode came out of ROM, so the instructions couldn't be modified anyway.
I started learning programming when the idea of index registers was new and only a few computers had them. Self-modifying code was the norm. Often, when index registers began to be introduced, there was only one or maybe 3 and subroutines couldn't count on their availability, so self-modifying code was still the norm for a long time.
Question: Will the following work on the Propeller II?
movs :fetch, line nop :fetch mov tag, 0-0I'm wondering if the deeper pipeline on the P2 will mean that more NOP instructions will be needed between the movs and the mov. I suspect the answer might be no since I think Chip has said that register forwarding would be used to hide the pipeline in most cases. However, if that is the case, will the following code work on P2?Seems like forwarding could handle this case as well.
Also, could I program one core inside in ASM while the other is in SPIN?
Yes and NO.
You can never program COG core in SPIN as Spin are Interpreter (programed in PASM) of Byte code that runs from HUB.
You only Load that Interpreter to any COG and run SPIN code ---> BUT You can run more that one COG as Interpreter in parallel and other COG's as PASM code
http://www.parallax.com/portals/0/propellerqna/
If your purchase is for a college, you may want to send a message to Andy Lindsay to see what else he may recommend from an educational standpoint.
Andy Lindsay had given some great links of documents about the Propeller. Thanks too for this one.
Another great point is that the pins are not predefined to be a UART, etc. All 32 I/Os can be used by any cog for anything. However, P28 & 29 are usually for the EEPROM - BTW why not use the 24C512 as it is not much more in cost and you then have an extra 32KB which you can use for storage, not RAM. P30 & 31 are used for downloading code and this can also store in the EEPROM directly from PropTool. So we usually make P30 & 31 a serial interface.
VGA required 8 pins and 8 resistors, TV requires 3 pins and 3 resistors (unless you want aural in broadcast mode - don't ask me as I never used this) and I have a driver that uses 1pin and 1 resistor for monochrome and minimal footprint, PS2 keyboard or mouse requires 2 pins and 4 resistors but I have a driver that uses 1 pin and 3 resistors. SD (or microSD) uses 4 pins with preferably 4 pullups although it has been done with less pullups.
Someone once said that USB was impossible so some smart cookies proved them wrong again. We now have a non-compliant USB to Bluetooth using a $2 Bluetooth dongle, and some other devices.
We also have CPM running on a Z80 emulator written by heater. You need SRAM for this so there are a number of hardware designs, some using 2 props. This includes my RamBlade and TriBlade. Pullmoll has entered the fray and produced a number of Z80 emulations.
Since you are in the education section, you should look at Kye's work as he does this for his Uni. Also look at Hanno's 12 Blocks and his other products.
This should keep you amused for a while :smilewinkgrin: Don't forget, anything you don't understand, just ask.
Right now I do believe that (I hope I'm wrong here!) not one college/universities in Malaysia has ever used Parallax in the projects yet. Personally, I feel that the 8-core processor has many potentials.
Even for my personal projects, the flexibility of the Propeller has alread torn down the boundaries of the casual single-cores. Certain designs like multiplexing digits in seven-segment modules (in single-core, these use interrupts and have a possibility of complicating design and starving of the interrupt if it's poorly programmed) and keypad scanning (again, in single-core, debouncing is *always* an issue if software is only run) do give the best result when a Propeller is used.
I just bought a Parallax Propeller Book - by Harpit Singh Sandu, and the descriptions inside are very clear and good. I will try the projects once I got the chips and the programmer.
But just one question - I've searched around the Q&A - there is no index register or any pointer-related things in the PASM. Did the Propeller support that, and how could they implement arrays without these?
For example, a copy subroutine could be written as follows:
src long 0 dst long 0 cnt long 0 ' the caller would place the source address in COG RAM in 'src', the destination address ' in COG RAM in 'dst' and the number of words to transfer in 'cnt' and then call this ' subroutine MY_COPY movs :patch, src ' sets the source field of the instruction at :patch to src movd :patch, dst ' sets the destination field of the instruction at :patch to dst nop ' this is because a movd must be separated from the target instruction by at least ' one other instruction :loop :patch mov 0-0, 0-0 djnz cnt, #:loop MY_COPY_ret retsrc long 0 dst long 0 cnt long 0 ' the caller would place the source address in COG RAM in 'src', the destination address ' in COG RAM in 'dst' and the number of words to transfer in 'cnt' and then call this ' subroutine MY_COPY movs :patch, src ' sets the source field of the instruction at :patch to src movd :patch, dst ' sets the destination field of the instruction at :patch to dst nop ' this is because a movd must be separated from the target instruction by at least ' one other instruction :loop :patch mov 0-0, 0-0 ' the funny 0-0 syntax just indicates that these are placeholders ' that will be filled in by the code at runtime add :patch, inc_src_and_dst ' increment the source and destination fields djnz cnt, #:loop MY_COPY_ret ret inc_src_and_dst long (1<<9)|1There are a number of ways we access cog ram. But remember, all 512 (496 plus the registers) can be accessed directly within the instructions.
Heed the warning in the manual about accessing the registers. Some can only be accessed as source or destination registers...
mov temp,ina
mov ina,temp 'does not work as expected (see shaddow registers when you get more experienced)