It doesn't really matter, but I think I'd prefer cnt instead of ct:
Getcnt
Setcnt=Setcnt1 (alternate syntax for addct as we're more setting than adding)
Waitcnt=Waitcnt1
Should this chip be called something other than "Propeller 2"? It seems like it is diverging from P1 in many ways and claiming they are the same architecture may be misleading.
Interesting idea.
There is some merit in a "family name" and for existing examples we have
from ST
STM32
STM8
32b and 8b MCU families
and from Silabs
EFM32xx
EFM8
32b and 8b MCU families
Atmel had AVR32 added to AVR8, but the AVR32 has rather faded in the ARM
Microchip like to call all of their many variant cores PICxxx
No one expects too much compatibility across cores, but some vendors do try to have a common IDE/Debug and follow at least some library rules.
That said, Prop2 may be too close to Prop1 - alternatives ?
Does Prop16 confuse people to thinking it is a 16b CPU ?
Prop512 leaves users to infer it is a 32b device, and is certainly clearly now different from Prop1
P16X32 may be ok on an order form, but no one can say that easily.
So to reiterate what I said earlier about the outputs that they should be AND'ed rather than OR'd to allow any cog to pull a pin low without being blocked due to the fact that chip-enables and serial transmit and I2C and 1-Wire etc are all active low lines. The typical approach in P1 was to dedicate a cog to PASM for say the SD card and other cogs would pass commands and data via "mailboxes" to that cog. However even with P1 using Tachyon it was more effective to allow any cog to handle the device directly since the high-level routines were common and Tachyon code is fast. In many cases however the problem with this simple and efficient direct approach was the blocking effect of the OR'ed pins. One way around that was to make sure the active low outputs had pull-ups on them so they would at least idle high when released by a cog. Having AND'ed outputs solves all that and it still works the same way for any cog that wants to use an output except it "blocks" low.
As for chip naming I can't see why it should be called something different since it clearly has the Propeller architecture characterized by eight or more independent cogs with 9-bit local source and destination address combined into conditional instructions connected to a common hub memory. Sure it has been enhanced to the hilt with interrupts and FIFOs and streamers and a Cordic solver etc etc but it still has these basic characteristics which distinguish it from all others.
It doesn't really matter, but I think I'd prefer cnt instead of ct:
Getcnt
Setcnt=Setcnt1 (alternate syntax for addct as we're more setting than adding)
Waitcnt=Waitcnt1
What was wrong with waitcnt, waitcnt2, and waitcnt3? Why is it necessary to contract "cnt" to "ct"?
When we number the counters, we could make this generic: not waitcnt, waitct1, waitct2... but waitct0, waitct1,waitct2.
And I would very much like to see camel-type coding, so there should be case sensitivity.
WaitCn0, WaitCn1, ... etc.
When writing code, I always do camelcoding, but it is not supported by the tools. It is just much easier to read and to detect certain patterns.
If you need it, type your stuff in camel-type, and you won't know any difference, and newbies to coding won't be freaked out when a like looks right and doesn't work.
If you need it, type your stuff in camel-type, and you won't know any difference, and newbies to coding won't be freaked out when a like looks right and doesn't work.
I do so currently, but I like to be checked by machines ;-)
i HAD AlWays assumED assEMBlers hadn't ENFORCED case or any sort OF CamelCode or other text FORMaTTing restraints.
In MOST languages, even THINGS like CamelCase is a coding standard-or-convention rather than an enforced_way to do_things. The only thing might be case sensitivity or insensitivity.
Surely making it as friendly to new users as possible would be the best way to go?
What "feature" are you referring to that will be unfriendly to new users?
CT?
Clock Tick register (system and user)
The Propeller2 has a 32-bit system clock tick register referred to as CT. It is incremented with each "tick" of the system clock and can be read into a COG user register with the GETCT instruction. The instruction below gets the current value of CT and places it into my_timer which would have been set up elsewhere with a RES or LONG.
getct my_timer
The Propeller2 also has 3 32-bit user clock tick registers referred to as CT1, CT2 and CT3. They can be used as counters and timers for various purposes in your program. As the programmer, you need to set aside a register to use as CT1, CT2 or CT3. In this example, we will used my_timer from above. Before you can use any of the user timers, you need to register it with the COG and provide an new value for when it will expire. This is done with the ADDCT1, ADDCT2 or ADDCT3 instructions depending on which timer you are working with. The instruction below registers CT1 with the COG and sets the trigger value to 500 ticks from what it currently holds:
addct1 my_timer,#500
With the WAIT and POLL instructions, you can have a program wait for a user counter to expire (WAITCT1, WAITCT2, WAITCT3) or poll a timer to see if it has expired (POLLLCT1, POLLCT2, POLLCT3). In these instructions, the 1,2 and 3 indicate which user timer you want to use.
You can also set up the COG to have any or all timers cause interrupts when they expire by registering them as one of the interrupt triggers, SETINT1, SETINT2 or SETINT3. For more details on this, you need to read about setting up CT interrupts.
I don't see how having similar instructions dealing with counter refer to the first counter as CNT and the other two counter as CT1 and CT2 is any friendlier.
If you were referring to some other aspects as being unfriendly (forcing camelCase?), then I agree with you 100%
And I would very much like to see camel-type coding, so there should be case sensitivity.
WaitCn0, WaitCn1, ... etc.
You are in luck!
That is already supported, on a user choice basis.
All the Assemblers I've used are case agnostic, but I've fixed a couple that took that a little too far, and forced all symbols to UPPER in the Debug files.
ie a good assembler is case tolerant, and preserves case in the Debug files.
General Assembler documentation convention is to have the reserved words in UPPER, but with syntax highlighting editors, even that is not as important as it was, as long as the documents use Bold or similar on reserved words.
last week i bought a DE0-Nano on ebay (for a good price:)
I play around with it and do some programming examples, it all works.
For the first prop2 test i used the "DE0_Nano_Bare_Prop2_v3.jic" with USB-Serial-Prog like shown
in "DE0_Nano_Bare_Prop2_Hookup" - no problems.
Now i would like to use my self made DAC:
Do i have to use the "DE0_Nano_Prop2_v3.jic" image ?
PNut finds no more Propeller 2 with this image or do i have to use other Prog-Pins ?
I also try out GPIO_211/212/0 _IN_0 instead of GPIO_3/5/7.
I'm a little bit confused. What is the exact difference between those both Nano-Images ?
last week i bought a DE0-Nano on ebay (for a good price:)
I play around with it and do some programming examples, it all works.
For the first prop2 test i used the "DE0_Nano_Bare_Prop2_v3.jic" with USB-Serial-Prog like shown
in "DE0_Nano_Bare_Prop2_Hookup" - no problems.
Now i would like to use my self made DAC:
Do i have to use the "DE0_Nano_Prop2_v3.jic" image ?
PNut finds no more Propeller 2 with this image or do i have to use other Prog-Pins ?
I also try out GPIO_211/212/0 _IN_0 instead of GPIO_3/5/7.
I'm a little bit confused. What is the exact difference between those both Nano-Images ?
Thanks in advance
Tharkun, That is quite an impressive breadboard build you have there, I hope we can find a way for you to use it.
I don't know if you have the attached. It is the schematic for the add-on board and should (maybe) help explain the pin mappings from the Nano to the add-on board.
The bare nano image has the programming pins on 62/63 as indicated in the picture. The add-on board has the prop-plug on its own connector but I'm not sure where those map to.
Just Ctl-M to compile and go to memory map and if you don't get any errors, Ctl-M to go back to listing. Error will leave you in listing mode (to fix them! )
addit: I thought PNUT used to detect file changes. You could edit some place else and when you went back to PNUT, it asked if you wanted the file reloaded but it doesn't appear to do that.
You can open your source in PNUT and then go edit it in something else and when you are done there, save it, switch pack to PNUT and do Ctl-O (Open File) and just hit return to open the same file again except with your changes.
When you hit a Ctrl-M PNut will reload the file before assembling it. So you can edit a file outside of PNut, and then hit Ctrl-M twice to assemble and go back to the file view.
If Chip would add a command-line option to compile and another one to load the generated bin, then we can use our favorite editors and just shell out to PNUT for those two needs.
Comments
Getcnt
Setcnt=Setcnt1 (alternate syntax for addct as we're more setting than adding)
Waitcnt=Waitcnt1
That alias was suggested before, and it does make code easier to port.
That was considered, but Chip prefers names <= 7 for tab-align reasons, Waitcnt1 is > 7.
That has some merit, but you are moving further away from Prop1 code porting.
Interesting idea.
There is some merit in a "family name" and for existing examples we have
from ST
STM32
STM8
32b and 8b MCU families
and from Silabs
EFM32xx
EFM8
32b and 8b MCU families
Atmel had AVR32 added to AVR8, but the AVR32 has rather faded in the ARM
Microchip like to call all of their many variant cores PICxxx
No one expects too much compatibility across cores, but some vendors do try to have a common IDE/Debug and follow at least some library rules.
That said, Prop2 may be too close to Prop1 - alternatives ?
Does Prop16 confuse people to thinking it is a 16b CPU ?
Prop512 leaves users to infer it is a 32b device, and is certainly clearly now different from Prop1
P16X32 may be ok on an order form, but no one can say that easily.
As for chip naming I can't see why it should be called something different since it clearly has the Propeller architecture characterized by eight or more independent cogs with 9-bit local source and destination address combined into conditional instructions connected to a common hub memory. Sure it has been enhanced to the hilt with interrupts and FIFOs and streamers and a Cordic solver etc etc but it still has these basic characteristics which distinguish it from all others.
I think this could be a part of them smart pins. As far as known pullup/pulldown is in there and maybe some inverting would be possible also.
So it can stay with the current OR, but you just invert the pin!
This would allow to decide pin for pin what you need.
Enjoy!
Mike
Really!
And I would very much like to see camel-type coding, so there should be case sensitivity.
WaitCn0, WaitCn1, ... etc.
When writing code, I always do camelcoding, but it is not supported by the tools. It is just much easier to read and to detect certain patterns.
If you need it, type your stuff in camel-type, and you won't know any difference, and newbies to coding won't be freaked out when a like looks right and doesn't work.
I do so currently, but I like to be checked by machines ;-)
In MOST languages, even THINGS like CamelCase is a coding standard-or-convention rather than an enforced_way to do_things. The only thing might be case sensitivity or insensitivity.
What "feature" are you referring to that will be unfriendly to new users?
CT?
Clock Tick register (system and user)
The Propeller2 has a 32-bit system clock tick register referred to as CT. It is incremented with each "tick" of the system clock and can be read into a COG user register with the GETCT instruction. The instruction below gets the current value of CT and places it into my_timer which would have been set up elsewhere with a RES or LONG. The Propeller2 also has 3 32-bit user clock tick registers referred to as CT1, CT2 and CT3. They can be used as counters and timers for various purposes in your program. As the programmer, you need to set aside a register to use as CT1, CT2 or CT3. In this example, we will used my_timer from above. Before you can use any of the user timers, you need to register it with the COG and provide an new value for when it will expire. This is done with the ADDCT1, ADDCT2 or ADDCT3 instructions depending on which timer you are working with. The instruction below registers CT1 with the COG and sets the trigger value to 500 ticks from what it currently holds: With the WAIT and POLL instructions, you can have a program wait for a user counter to expire (WAITCT1, WAITCT2, WAITCT3) or poll a timer to see if it has expired (POLLLCT1, POLLCT2, POLLCT3). In these instructions, the 1,2 and 3 indicate which user timer you want to use.
You can also set up the COG to have any or all timers cause interrupts when they expire by registering them as one of the interrupt triggers, SETINT1, SETINT2 or SETINT3. For more details on this, you need to read about setting up CT interrupts.
I don't see how having similar instructions dealing with counter refer to the first counter as CNT and the other two counter as CT1 and CT2 is any friendlier.
If you were referring to some other aspects as being unfriendly (forcing camelCase?), then I agree with you 100%
Remember, we are st bootstrap stage. Simple, lean, mean makes sense.
When we get on chip PASM, it probably will be simple, and a lot like pnut.
From there, we get gas, and open spin, etc...
Those can offer way more options, IMHO.
On P1 the CNT rolls over at some 50 seconds, but on the P2 it will roll over quite faster.
Enjoy!
Mike
You are in luck!
That is already supported, on a user choice basis.
All the Assemblers I've used are case agnostic, but I've fixed a couple that took that a little too far, and forced all symbols to UPPER in the Debug files.
ie a good assembler is case tolerant, and preserves case in the Debug files.
General Assembler documentation convention is to have the reserved words in UPPER, but with syntax highlighting editors, even that is not as important as it was, as long as the documents use Bold or similar on reserved words.
last week i bought a DE0-Nano on ebay (for a good price:)
I play around with it and do some programming examples, it all works.
For the first prop2 test i used the "DE0_Nano_Bare_Prop2_v3.jic" with USB-Serial-Prog like shown
in "DE0_Nano_Bare_Prop2_Hookup" - no problems.
Now i would like to use my self made DAC:
Do i have to use the "DE0_Nano_Prop2_v3.jic" image ?
PNut finds no more Propeller 2 with this image or do i have to use other Prog-Pins ?
I also try out GPIO_211/212/0 _IN_0 instead of GPIO_3/5/7.
I'm a little bit confused. What is the exact difference between those both Nano-Images ?
Thanks in advance
This existed in an older version of the P2, but it appears that the current version no longer has it.
If the clock rollover could be detected as an event, it would be possible to emulate a 64-bit counter.
It could certainly be simulated with one of the user CT counters but why use one of those if we can get it for (more) free with a standard event.
Tharkun, That is quite an impressive breadboard build you have there, I hope we can find a way for you to use it.
I don't know if you have the attached. It is the schematic for the add-on board and should (maybe) help explain the pin mappings from the Nano to the add-on board.
The bare nano image has the programming pins on 62/63 as indicated in the picture. The add-on board has the prop-plug on its own connector but I'm not sure where those map to.
Hopefully Chip can answer this for you.
Guess what I should do is edit in Prop Tool and then copy and paste to PNut, but that's kind of a pain...
Also, is it possible to compile without downloading?
Ctl-M will compile without a download.
Just Ctl-M to compile and go to memory map and if you don't get any errors, Ctl-M to go back to listing. Error will leave you in listing mode (to fix them!
addit: I thought PNUT used to detect file changes. You could edit some place else and when you went back to PNUT, it asked if you wanted the file reloaded but it doesn't appear to do that.
You can open your source in PNUT and then go edit it in something else and when you are done there, save it, switch pack to PNUT and do Ctl-O (Open File) and just hit return to open the same file again except with your changes.
Clunky but it works.
Pnut is just enough to bootstrap on. IMHO, that is wise at this early stage. A quick change can be done, which is what we need most.
When it gets more solid, more and better tool investments will make a lot of sense.
Guess that's pretty good... Thanks for the tip.