It's really nothing big. There are about 22 instructions which read S and write D (as opposed to modify D). These are basically unary operations dressed up as MOV's. Because we had plenty of 'D,S' opcode space, they were made more flexible, with two operands. What I'm going to do is make the assembler accommodate the case of only ONE operand, so that if you want to do an INCPAT on a single register, you can just do 'INCPAT D', instead of 'INCPAT D,D'. I probably just spent more time explaining it than it will take to accomplish. It's just a little enhancement to make PASM more writable and readable.
Interesting. I have been working on and off (since you published the last instruction set update) with my P2 debugger - the disassembler part - and discovered that there is also a third operand possible with the new instruction set. eg GETBYTE D,S,#0..3
However, I think the new set is a lot easier and more regular.
I will leave the couple of extra instructions and SERDES until you are ready for some fresh air
What are atomic instructions?… those that execute in one cycle?
I've got to stop using that term, I think. I meant to say any instruction that does something without other state dependencies. For example, COGINIT used to need you to do a SETCOG instruction to set the cog number. This created a state dependency that was unfriendly to multi-tasking code. Now COGINIT has a 3-bit immediate field to declare the cog number. This now makes starting a cog an 'atomic' operation, whereas before you needed to set something else up with another instruction.
Atomic sounds close enough. Usually it means non-interruptable, or at the same time.
For example, on thing like counters, having atomic control of both counters in one opcode cycle, can mean not missing any external edge events, or knowing both counters do tag the same previous event.
Interesting. I have been working on and off (since you published the last instruction set update) with my P2 debugger - the disassembler part - and discovered that there is also a third operand possible with the new instruction set. eg GETBYTE D,S,#0..3
Based on the bit-encoding for the three-operand instructions, I see it as just a clever way of using a single mnemonic for a set of similar instructions (i.e. instead of GETBYTE0, GETBYTE1, etc.).
Apologies well in advance if this has been covered in this 140+ page thread, but will it be possible to dump 3 or 4 bytes into a counter and as the TV commercial said "Set it and forget it" to have the counter bit bang that data out to a pin?
The MIDI world would be able to make great use of this feature. Right now I have an application on the Prop I which works albeit with a bunch of code to handle 4 streams of mostly 3 byte MIDI messages. It would be fantastic to just dump that data to the counter and make it a UART.
Right now no need in my applications for processing incoming MIDI messages but at worse I have the assembly code to handle that already.
A few weeks ago, Chip added a UART like feature to the P2 verilog that could send/receive 8 bit or 32 bit values with start and stop bits, and an optional 4 bit address.
Right now, he is looking into a SERDES where besides the features above, it would be possible to send/receive synchronously without start/stop bits, with internal or external clock, and possibly with a variable number of bits. How much of this makes it into the VERILOG is unknown. There was a VERY long SERDES thread, that Chip is digesting, and he is currently deciding what he can implement without delaying the P2.
Apologies well in advance if this has been covered in this 140+ page thread, but will it be possible to dump 3 or 4 bytes into a counter and as the TV commercial said "Set it and forget it" to have the counter bit bang that data out to a pin?
The MIDI world would be able to make great use of this feature. Right now I have an application on the Prop I which works albeit with a bunch of code to handle 4 streams of mostly 3 byte MIDI messages. It would be fantastic to just dump that data to the counter and make it a UART.
Right now no need in my applications for processing incoming MIDI messages but at worse I have the assembly code to handle that already.
A few weeks ago, Chip added a UART like feature to the P2 verilog that could send/receive 8 bit or 32 bit values with start and stop bits, and an optional 4 bit address.
Right now, he is looking into a SERDES where besides the features above, it would be possible to send/receive synchronously without start/stop bits, with internal or external clock, and possibly with a variable number of bits. How much of this makes it into the VERILOG is unknown. There was a VERY long SERDES thread, that Chip is digesting, and he is currently deciding what he can implement without delaying the P2.
How much of this makes it into the VERILOG is unknown. There was a VERY long SERDES thread, that Chip is digesting, and he is currently deciding what he can implement without delaying the P2.
Topical regarding this, is the new 200MHz Microchip PIC32MZEC
For link speeds they claim :
* 50 MHz Serial Quad Interface (SQI)
* Six UART modules (25 Mbps): Supports LIN 1.2 and IrDA protocols
* Six 4-wire SPI modules (50 Mbps) [these include i2s Audio option]
* SQI configurable as an additional SPI module (50 MHz)
As discussed before, that makes 50MHz(+) HW support (where HW manages bit-level stuff, and SW manages bytes/words) a sensible target.
and on general peripherals they have
* 12-bit, 28 MSPS, 48-channel ADC module ( 6 S+H )
* CAN, UART, I2C, PMP, EBI, SQI & Analog Comparators
* SPI/I2S interfaces for audio processing and playback
* Hi-Speed USB 2.0 Device/Host/OTG
* 10/100 Mbps Ethernet MAC with MII and RMII interface
Microchip claim "Pricing starts at $6.68 each in 10,000-unit quantities", which I guess is for the 'smallest' 64pin, 1024kF 512kR part. ( Not your grandfathers PIC16C54!! )
That PIC looks like an awfully nice industrial chip, though I'll stick with propeller.
I have a question about the MIDI - I see why someone might want the 3 bit routine, but isn't MIDI really slow (like 32 kilobaud) that can even be driven in a higher level language like spin or c? Even with multithreading, it should be possible to read a couple MIDI lines and process them in real time using one or part of one P2 cog, I think. I guess I don't see why that functionality needs to be an assembly or built into hardware accommodation. I do think I get the need for SERDEC after getting a little education about it on this forum.
Topical regarding this, is the new 200MHz Microchip PIC32MZEC
For link speeds they claim :
* 50 MHz Serial Quad Interface (SQI)
* Six UART modules (25 Mbps): Supports LIN 1.2 and IrDA protocols
* Six 4-wire SPI modules (50 Mbps) [these include i2s Audio option]
* SQI configurable as an additional SPI module (50 MHz)
As discussed before, that makes 50MHz(+) HW support (where HW manages bit-level stuff, and SW manages bytes/words) a sensible target.
and on general peripherals they have
* 12-bit, 28 MSPS, 48-channel ADC module ( 6 S+H )
* CAN, UART, I2C, PMP, EBI, SQI & Analog Comparators
* SPI/I2S interfaces for audio processing and playback
* Hi-Speed USB 2.0 Device/Host/OTG
* 10/100 Mbps Ethernet MAC with MII and RMII interface
Microchip claim "Pricing starts at $6.68 each in 10,000-unit quantities", which I guess is for the 'smallest' 64pin, 1024kF 512kR part. ( Not your grandfathers PIC16C54!! )
Of course - the main point was the serial interface choices, and speeds. P2 should at least match this.
25MBd UARTS and 50MHz QSPI for example.
Being able to connect one of these to a P2, over a QuadSPI at 50MHz, would be nice
If you like more cores, the NXP LPC4370 has 3 : 1 x M4 and 2 x M0, but comes in BGA only.
Priced under the PIC32MZEC, but has no flash, just the 282 kB SRAM
If you like more cores, the NXP LPC4370 has 3 : 1 x M4 and 2 x M0, but comes in BGA only.
Priced under the PIC32MZEC, but has no flash, just the 282 kB SRAM
I sat through that webminar - sounds like an interesting chip, but hate the BGA packaging.
I asked, there may be hope for an LQFP-100 package, which is available on lower end LPC43xx packages, but those have half the ram.
They ignored my question about how their "SPIFI" (QSPI) cache works, so I am betting its only a FIFO or single-line direct mapped cache. They mumbled about how they are not disclosing their proprietary information on the chat... very different from Chip, eh?
I have been trying to avoid BGA, still working myself up to the prop's TQFP-128 .4mm package.
Topical regarding this, is the new 200MHz Microchip PIC32MZEC
For link speeds they claim :
* 50 MHz Serial Quad Interface (SQI)
* Six UART modules (25 Mbps): Supports LIN 1.2 and IrDA protocols
* Six 4-wire SPI modules (50 Mbps) [these include i2s Audio option]
* SQI configurable as an additional SPI module (50 MHz)
As discussed before, that makes 50MHz(+) HW support (where HW manages bit-level stuff, and SW manages bytes/words) a sensible target.
and on general peripherals they have
* 12-bit, 28 MSPS, 48-channel ADC module ( 6 S+H )
* CAN, UART, I2C, PMP, EBI, SQI & Analog Comparators
* SPI/I2S interfaces for audio processing and playback
* Hi-Speed USB 2.0 Device/Host/OTG
* 10/100 Mbps Ethernet MAC with MII and RMII interface
Just curious...
How many of those ports can it use at any one time?
A lot of other microcontrollers where the manufacturers brag about what their chip can do, a lot of the stuff is 'overlapping' with regards to pins or control circuitry/registers, so that only a small subset can be used.
Just curious...
How many of those ports can it use at any one time?
A lot of other microcontrollers where the manufacturers brag about what their chip can do, a lot of the stuff is 'overlapping' with regards to pins or control circuitry/registers, so that only a small subset can be used.
The data mentions Peripheral Pin Select (PPS), which seems to have a 4 bit field, which would cover quite a bit of re-mapping.
(but not as freely mapped as a Prop)
In many of these bigger parts, they are available in BGA packages with 256 pins, sometimes more. Definitely not aimed at the hobbyist market, but I have seen Ethernet, 16 bit parallel interface to SDRAM, an LCD controller capable of driving even VGA, and various other parts all running simultaneously. On the other end there are now chipscale packages which are incredibly small with around 100 pins, like the M7 in the new Apple products, with everything running at once, and with hardware support, DMA, lots of spare cycles for a 100 MHz ARM CPU.
In many of these bigger parts, they are available in BGA packages with 256 pins, sometimes more. Definitely not aimed at the hobbyist market,...
Parts on this scale generally are not aimed at the hobbyist market, and the same is true of the P2 to some extent. On the other hand, they are overkill for many common applications - sub $10 prices notwithstanding.
Topical regarding this, is the new 200MHz Microchip PIC32MZEC ...
Microchip claim "Pricing starts at $6.68 each in 10,000-unit quantities", which I guess is for the 'smallest' 64pin, 1024kF 512kR part. ( Not your grandfathers PIC16C54!! )
And, following up on that, is there any way to start a COG up without resetting it? I could imagine a COG stopping itself to save power, then having another COG start it back up again (from the next instruction after the COGSTOP). I suppose you could do something similar by using WAITPEQ on PortD, but I have to imagine that halting a COG altogether would be more energy-efficient.
This is similar to an idea I'd pondered earlier. I guess that while, yes, waitpeq, waitcnt, etc. save power they probably don't reduce power consumption to that of a completely dormant cog. Whether that difference is really worth fretting over in our "green" era is another question, though.
This is similar to an idea I'd pondered earlier. I'm guess that while, yes, waitpeq, waitcnt, etc. save power they probably don't reduce power consumption to that of a completely dormant cog. Whether that difference is really worth fretting over in our "green" era is another question, though.
To go below WAITxx, you need to start gating clocks on the fly - which is a black art in itself, and not synthesis-friendly.
Certainly unused COGs should be 'off', and maybe giving user access to the same global enable (I'm guessing related to Reset-exit) could be useful, but that may not quite be on a on-the-fly basis.
Another way to save power, is to allow variable clock dividers, and those are becoming quite common on small uC.
To go below WAITxx, you need to start gating clocks on the fly - which is a black art in itself, and not synthesis-friendly.
Certainly unused COGs should be 'off', and maybe giving user access to the same global enable (I'm guessing related to Reset-exit) could be useful, but that may not quite be on a on-the-fly basis.
Yes, I know, jmg: it's not a piece of cake in hardware. What I had considered went even further with the idea, too; after thinking about it some, I quickly realized that it's not practical to implement now - and may never be.
However, power consumption is something to be paid close attention nowadays. Anything that can be done to help there is worth at least considering.
Comments
However, I think the new set is a lot easier and more regular.
I will leave the couple of extra instructions and SERDES until you are ready for some fresh air
I've got to stop using that term, I think. I meant to say any instruction that does something without other state dependencies. For example, COGINIT used to need you to do a SETCOG instruction to set the cog number. This created a state dependency that was unfriendly to multi-tasking code. Now COGINIT has a 3-bit immediate field to declare the cog number. This now makes starting a cog an 'atomic' operation, whereas before you needed to set something else up with another instruction.
Atomic sounds close enough. Usually it means non-interruptable, or at the same time.
For example, on thing like counters, having atomic control of both counters in one opcode cycle, can mean not missing any external edge events, or knowing both counters do tag the same previous event.
Based on the bit-encoding for the three-operand instructions, I see it as just a clever way of using a single mnemonic for a set of similar instructions (i.e. instead of GETBYTE0, GETBYTE1, etc.).
What's the deal with the "3-bit immediate field" to select the COG? Does that mean we won't be seeing more than 8 COGs in any future Propeller?
The MIDI world would be able to make great use of this feature. Right now I have an application on the Prop I which works albeit with a bunch of code to handle 4 streams of mostly 3 byte MIDI messages. It would be fantastic to just dump that data to the counter and make it a UART.
Right now no need in my applications for processing incoming MIDI messages but at worse I have the assembly code to handle that already.
Right now, he is looking into a SERDES where besides the features above, it would be possible to send/receive synchronously without start/stop bits, with internal or external clock, and possibly with a variable number of bits. How much of this makes it into the VERILOG is unknown. There was a VERY long SERDES thread, that Chip is digesting, and he is currently deciding what he can implement without delaying the P2.
FANTASTIC! Thanks Bill!
Topical regarding this, is the new 200MHz Microchip PIC32MZEC
For link speeds they claim :
* 50 MHz Serial Quad Interface (SQI)
* Six UART modules (25 Mbps): Supports LIN 1.2 and IrDA protocols
* Six 4-wire SPI modules (50 Mbps) [these include i2s Audio option]
* SQI configurable as an additional SPI module (50 MHz)
As discussed before, that makes 50MHz(+) HW support (where HW manages bit-level stuff, and SW manages bytes/words) a sensible target.
and on general peripherals they have
* 12-bit, 28 MSPS, 48-channel ADC module ( 6 S+H )
* CAN, UART, I2C, PMP, EBI, SQI & Analog Comparators
* SPI/I2S interfaces for audio processing and playback
* Hi-Speed USB 2.0 Device/Host/OTG
* 10/100 Mbps Ethernet MAC with MII and RMII interface
Microchip claim "Pricing starts at $6.68 each in 10,000-unit quantities", which I guess is for the 'smallest' 64pin, 1024kF 512kR part. ( Not your grandfathers PIC16C54!! )
I have a question about the MIDI - I see why someone might want the 3 bit routine, but isn't MIDI really slow (like 32 kilobaud) that can even be driven in a higher level language like spin or c? Even with multithreading, it should be possible to read a couple MIDI lines and process them in real time using one or part of one P2 cog, I think. I guess I don't see why that functionality needs to be an assembly or built into hardware accommodation. I do think I get the need for SERDEC after getting a little education about it on this forum.
Mind you, it only has one 200Mhz core
Of course
25MBd UARTS and 50MHz QSPI for example.
Being able to connect one of these to a P2, over a QuadSPI at 50MHz, would be nice
If you like more cores, the NXP LPC4370 has 3 : 1 x M4 and 2 x M0, but comes in BGA only.
Priced under the PIC32MZEC, but has no flash, just the 282 kB SRAM
I could not agree more!
I think chip said that the P2 UARTs can run at clkfreq/3, hopefully the SERDES will match that or better...
QSPI @ clkfreq/4 is possible using software only on a P2, clkfreq/2 may be possible using the counters to generate the clock
I sat through that webminar - sounds like an interesting chip, but hate the BGA packaging.
I asked, there may be hope for an LQFP-100 package, which is available on lower end LPC43xx packages, but those have half the ram.
They ignored my question about how their "SPIFI" (QSPI) cache works, so I am betting its only a FIFO or single-line direct mapped cache. They mumbled about how they are not disclosing their proprietary information on the chat... very different from Chip, eh?
I have been trying to avoid BGA, still working myself up to the prop's TQFP-128 .4mm package.
Just curious...
How many of those ports can it use at any one time?
A lot of other microcontrollers where the manufacturers brag about what their chip can do, a lot of the stuff is 'overlapping' with regards to pins or control circuitry/registers, so that only a small subset can be used.
The data mentions Peripheral Pin Select (PPS), which seems to have a 4 bit field, which would cover quite a bit of re-mapping.
(but not as freely mapped as a Prop)
In many of these bigger parts, they are available in BGA packages with 256 pins, sometimes more. Definitely not aimed at the hobbyist market, but I have seen Ethernet, 16 bit parallel interface to SDRAM, an LCD controller capable of driving even VGA, and various other parts all running simultaneously. On the other end there are now chipscale packages which are incredibly small with around 100 pins, like the M7 in the new Apple products, with everything running at once, and with hardware support, DMA, lots of spare cycles for a 100 MHz ARM CPU.
To go below WAITxx, you need to start gating clocks on the fly - which is a black art in itself, and not synthesis-friendly.
Certainly unused COGs should be 'off', and maybe giving user access to the same global enable (I'm guessing related to Reset-exit) could be useful, but that may not quite be on a on-the-fly basis.
Another way to save power, is to allow variable clock dividers, and those are becoming quite common on small uC.
True, and notice this errata applies to their (A3) release silicon.
However, power consumption is something to be paid close attention nowadays. Anything that can be done to help there is worth at least considering.