From the POV of reception, what do SPI and serial async have in common? Almost nothing. Just a shift register. What does a shift register (or two) cost in terms of silicon real estate? Almost nothing.
While a universal serial receiver would be a great goal conceptually, in a practical sense it leverages almost no common circuitry. So why make them one block schematically? Why not provide a separate UART, which Chip has already done, and a simple SPI?
You can, but keep in mind that 'simple shifter' also needs read and write queue buffering, a length counter, and a single register space mapping.
That's why it is easier to 'turn off' the Async Start/Stop bits, but keep everything else common.
Hey, the info about catching the start bit, then testing it again at 1/2 bit period is a great idea. I will change our shifters to do that. In two state bits, I was only using 3 states, so that empty state will now get used, as this adds one state to the machine.
Getting more common on SPI, is a similar 'noise-avoidance on the CLK' idea, whereby SPI slaves check for MOD 8 clocks, before acting on the data.
That way, single random injected spikes (aka bonus clock edges), are rejected.
If the P2 can read the RxBitCounter in slave mode, Sw can check for MOD 8 (or MOD 16) etc clocks.
Mostly I agree with [else] options listed, but the detail above I'm less clear on.
Checking how many bits have gone is useful (certainly TX_Done is needed for things like RS485) but the shift register itself is usually buffered invisibly, and so not shift-visible.
Making it shift visible costs another register map, for little gain in information.
What could be done, is to make the Length register read/write, so write defines the (usually fixed) bit-length load, and read reads back the shifted bit down counter, which is counting down during shifts. (& reloads with length when done )
In SPI these values are same size, but get a little trickier in Async, as a 9 bit uart has at least 11 counts, but maybe read here could get state bits and some, but not all, bit counter bits ?
'Done' would have a unique value, as would 'waiting on start', but unless the field was expanded, full granular tracking of Async would not be possible.
Maybe there is room to expand on read, without bumping the register space ?
jmg
Sure it can be my poor eye's sight, but I just read Chip's last documents and saw no reference to an effective use for the WZ side effects on SERINA or SERINB.
Perhaps it can be used, if not yet clogged anyway, to select between effectively reading the serializer or your intended status register, without bumping the register space.
Please, correct me if I'd been driven thru a mistake, by not completely understanding the whole situation you devised.
The video isn't a binary shift register anymore, it outputs color data via DACs with a lookup table.
Oh no. The Prop I video was useful for so many other things. So no DVI-D either, I guess.
In that case, with the loss of the digital video serializer, I'm no longer sitting on the fence about a general-purpose SERDES. I think one is needed. Or else figure out a way to modify the video circuitry to do the SER part again. The DES part is going to be complicated, though.
Sure it can be my poor eye's sight, but I just read Chip's last documents and saw no reference to an effective use for the WZ side effects on SERINA or SERINB.
Perhaps it can be used, if not yet clogged anyway, to select between effectively reading the serializer or your intended status register, without bumping the register space.
Whilst you could use gymnastics to overlay reads, my example in #153 shows why reading the shifter is not a good idea.
On a slave, you get no useful info at all - much smarter to read the bitcounter in both cases, if you want to track where the shift is up to. The counter-read also allows noise rejection checks, and is unambiguous.
Originally I thought that the counters could be used to provide the clocks to the serialiser. Is this possible and is it simpler?
Here is an idea...
We use CNTRA to provide the transmitter clock and CNTRB to provide the receiver clock. This way we have total control and can generate any frequency based on the internal clock.
Now, we output those counters to 2 pins (we can use external pins P0-P91 or the internal pins P92-95 or P96-P127) - correct???
This means we can bring out the clock(s) if required, and use one common clock if required.
Do the internal pins have the capability of inversion, or do the counter output have the possibility of inversion? If not, then we would need to be able to set which edge to use in the serialiser and deserialiser.
Now all we have to do is specify which pin(s) the serialiser and deserialiser get their input clocks from (which can be the internal P92-P127 or external P0-P91) and which pins the input and output serial data is on. We can invert the serial data by configuring the pins directly can't we?
If the above works, then all the clocking is taken care of within the existing hardware.
Now we only need two 32bit shift registers. We should be able to read and write to both of these registers. They do not need to be buffered/latched etc. We can clear them or preset them or whatever. One would be for input and one would be output.
Lets take this a little further...
We need two, one for input and one for output. What if they were identical, both capable of input and/or output? This means that we have two identical 32bit shift registers A & B. We can use one for transmit and one for receive. Or if we wanted, two for receive only or two for transmit only. Perhaps even a cascade option (we could do this using the internal pins). And by using an internal pin, we can define the state being shifted in for the transmitter.
Whilst you could use gymnastics to overlay reads, my example in #153 shows why reading the shifter is not a good idea.
On a slave, you get no useful info at all - much smarter to read the bitcounter in both cases, if you want to track where the shift is up to. The counter-read also allows noise rejection checks, and is unambiguous.
jmg
Sure, you are totaly right in your considerations!
I'd tried to find some way to discriminate between two possible sources of data to be read, using a single basic hardware address.
Since my english typing skills are very poor, doing it tends to be slower than some lazy and handicapped worm.
Then, I didn't saw your post till I ended my own typing.
I have totally lost the story on the serial I/O ideas for the PII.
I thought the idea was that ideally there would be some serial input and output shifters (SERDES) implemented with some simple support logic, such that many different protocols could be created with a little software support and much faster than bit-banging the bits. ...all this talk ... makes me think we are edging toward the world of dedicated hardware peripherals in a most un-proplike manner.
You're not alone, Heater. The serial stuff, among much else, makes me too wonder if we're not gradually drifting away from the Propeller concept. Or rather, to put it another way, the original Propeller model in practice has been found wanting.
[QUOTE=Cluso99;1210536 USB is actually 2 pins (both inputs or both outputs). They are normally inverted, and is a special case when the same polarity. This would require external gating. [/QUOTE]
One of my tricks is to set up a counter in a feedback mode, point Apin at the pin I want to invert, and take the inverted signal from FBpin. (I usually use a counter from my startup cog and set it up with a couple of lines of SPIN)
I've had good results making pseudo-RS485 this way. Any reason it wouldn't work for this? (With code for the special case.. of course)
Following on from my last post, here is an example circuit. There would be two of them, SerialA & SerialB.
Note I have included the MUX to select the clock from CTRA or CTRB, and optional inverters on both the inputs and outputs.
The counter shown is the existing CTRA or CTRB.
In addition to the read/write of the 32bit shift register, a 32bit configuration register would be included as follows
(copied and modified from Chip's SERIAL docs)
Before transmitting or receiving data, SFRA/SFRB must be configured:
SETSFRA/B D - Set SFRA configuration to %KK_CCCCCCC_E_xxxx_TT_DDDDDDD_RR_SSSSSSS
%E = shift register mode
%0 = shift register disabled
%1 = shift register enabled
%KK = clock mode
%00 = clock from CTRA output
%01 = clock from CTRB output
%10 = clock pin enabled (non-inverted)
%11 = clock pin enabled (inverted)
%CCCCCCC = CLK pin, 0..127
%TT = transmitter mode
%00 = transmitter output set "0" (ie disabled)
%01 = transmitter output set "1" (ie disabled)
%10 = transmitter output pin enabled (non-inverted)
%11 = transmitter output pin disabled (inverted)
%DDDDDDD = TX pin, 0..127
%RR = receiver mode
%00 = receive pin set "0" (will clock 0's into shift register on clock)
%01 = receive pin set "1" (will clock 1's into shift register on clock)
%10 = receiver pin enabled (non-inverted)
%11 = receiver pin enabled (inverted)
%SSSSSSS = RX pin, 0..127
DDDDDDD = transmit pin P0-127 (PIN_TX)
SSSSSSS = receive pin P0-127 (PIN_RX)
TT = 00 output disabled
DD = 01 DDDDDD refers to the output function of the register and SSSSSSSSS refers to the input register
One of my tricks is to set up a counter in a feedback mode, point Apin at the pin I want to invert, and take the inverted signal from FBpin. (I usually use a counter from my startup cog and set it up with a couple of lines of SPIN)
I've had good results making pseudo-RS485 this way. Any reason it wouldn't work for this? (With code for the special case.. of course)
Nice although I am not sure what delays this incurs. However, Chip has said the pin modes can be driven as differential so this would also do this to. Of course we have to handle the special case, but it is just a couple of bits for SE0/SE1? and ACK IIRC.
I don't think any trend in other uC devices should be cause to do it in P2. I'm not saying do it differently on principle, but I am saying the differences between the devices make this a very minor league consideration.
The idea of basic silicon functionality to assist with various tasks is a great one, but there are trade-offs. The P1 video generator circuit was simple, and we were able to output all kinds of things besides video, not to mention lots of different video. However, we also ended up with a lot of video core code and trade-offs too. Not to mention crappy PAL. The trade-offs in baud rate, bits, clocking smell a little like the accuracy issues P1 had with PAL. If so, it would be good to refine the circuit enough to avoid that.
In P2, more functionality went to the silicon, so now it does video and not so many other things. But, it still requires plenty of software help to get things done. IMHO, a better balance, though having the simple VGA mode of P1 really was cool. We can do that other ways, and there are new features to accomplish that task. IMHO, this isn't outside the Propeller philosophy, so long as it's really not a dedicated peripheral and software plays the role it traditionally has.
IMHO, the balance here is to make this serial something fall somewhere between what the P1 video generator did and what the P2 video generator will do. Just enough to avoid the, "Dang, if we had only done this, PAL would be perfect!" scenario.
Given it's intent is a general purpose serializer, the idea of using software to get the various protocols done makes perfect sense. Personally, I would go as far as possible without ever allowing the silicon to lock up for any reason, leaving the software to cover that kind of ground.
In other uC devices, they don't have the multi-core, nor do they have the redundant features a P2 will have. Keeping things simple makes a lot of sense. Those other devices have the separate clock because they do not have lots of other options and or exercising those options may well consume most of the device, not anywhere near the same consideration on P2.
I trust Chip to not over complicate it, leaving the feature general purpose enough to be used in creative ways like we did the P1 video generators. I also think that general purpose design will highlight right where a better sweet spot will be for the next chip release after P2, which maybe won't take the same amount of time... (lessons learned about process, synth tools, reusing smart I/O done on P2, etc...)
Above all, keep the silicon deterministic and free from lockups. Those things should be the domain of software. People get smarter over time, silicon that is too dedicated purpose gets more limiting over time.
Before this slope gets any slipperier, let's dial back a bit. We've got 160 MIPS at our disposal. Why do we even need a hardware SERDES? 10 MBaud Manchester should be possible in software, as well as fast SPI. Using a hardware UART for RS232-style comms is just nuts, given that eight or more done in software would handily fit in one cog. Chip came up with an elegant high-speed UART for Prop-to-Prop communication, but it seems to have opened Pandora's box. Do we even need it? I will miss the P1's video VGA mode. But with eight times the P1's speed, maybe not.
Anyway, I would gladly trade any kind of SERDES for as many counters and different counter modes as could be crammed into a cog.
Or rather, to put it another way, the original Propeller model in practice has been found wanting.
Why would you couch this in such negative terms? What product is perfect? What responsible manufacturer doesn't strive to improve or differentiate his/her products?
We've got 160 MIPS at our disposal. Why do we even need a hardware SERDES? 10 MBaud Manchester should be possible in software, as well as fast SPI.
It is because you have 160 MIPS that you need hardware support. 10MHz is slow, by modern link standards.
See my thread titled Prop 2 Serial support for FTDI Fast Serial mode - that can run at 50MHz, duplex
A COG represents a large investment in silicon, it is wasteful to use all that to flip bits.
A COG should be running software, not wasted (slowly) emulating a flip-flop or shifter.
Note a simple serial block, will allow lower CPU clock speeds, to save a lot of power.
I've never bought into the notion that any task, no matter how seemingly trivial, is "wasteful" of the Prop's resources. This is especially true now, with the advent of multitasking. The cogs are designed to be universal, software-driven peripherals whose architecture borders on microcode. People say they want a universal SERDES -- and I thought for awhile that I did, too -- but no one has really defined what that means in terms of the variety of word lengths (how about zero insertion/deletion for SDLC?) and synchronization. Why not add mod/demod (e.g. FM0, FM1, Manchester) while we're at it? At some point, it gets to be like pulling a thread on a sweater.
What I still are missing in counters module are simple FREQUENCY measure input counter. (self resettable in time measure period elapsed)
That needs many times to control real world things
What I still are missing in counters module are simple FREQUENCY measure input counter. (self resettable in time measure period elapsed)
Huh? The Prop1 does that easy peasy. Just setup edge counting on a Cog counter and sample the counter at fixed interval. Or, bit banging it on a Cog isn't bad either.
I've never bought into the notion that any task, no matter how seemingly trivial, is "wasteful" of the Prop's resources. This is especially true now, with the advent of multitasking. The cogs are designed to be universal, software-driven peripherals whose architecture borders on microcode.
Sure, if you ignore speed issues for a moment, COG resource is essentially free, until you run out of it wiggling bits, then it becomes very expensive indeed.
Given the hard ceiling on COG Code size, I'd rather see all that opcode-engine silicon doing real work, not pretending to be a FF.
Muilti-tasking just puts more pressure on COG ceiling, as users can now pack more into one COG.
What I still are missing in counters module are simple FREQUENCY measure input counter. (self resettable in time measure period elapsed)
That needs many times to control real world things
Yes, I've mentioned reciprocal counters before to Chip, hopefully the new Counters will support this.
The resource needed is not complex, just edge capture (which I think is in there?), and atomic control of both counters. (That's mostly a register mapping detail )
I'd consider it important for users to exercise the new counters, before the tapeout, but there is only one Chip.
Oh boy. If I were Chip wading by way through threads like this I would soon lose my mind. How does Chip keep his cool and focus?
Hope we can avoid ending up with a bunch of half baked over complex solutions that have to be carried forward into any future Prop developments.
It already disturbs me how huge the Prop II instruction set has become.
Or do I worry too much?
What I still are missing in counters module are simple FREQUENCY measure input counter. (self resettable in time measure period elapsed)
That needs many times to control real world things
The Prop2 counters do that. They can measure frequency or period.
Oh boy. If I were Chip wading by way through threads like this I would soon lose my mind. How does Chip keep his cool and focus?
Hope we can avoid ending up with a bunch of half baked over complex solutions that have to be carried forward into any future Prop developments.
It already disturbs me how huge the Prop II instruction set has become.
Or do I worry too much?
No problems. I just caught up on this thread. I'm too tired now to address every question. Thanks for thinking more about this.
All day I've been implementing the new RDSTK and WRSTK instructions which r/w the stack with SPA/SPB expressions, just like PTRA/PTRB for hub memory. I think it will take through tomorrow to get this done. It was very hard, at first, until I charted out all the possible juxtapositions of stack read and write instructions in the pipeline and how they might clobber each other. I've got it now so that most reads are tucked into stage 3, keeping things at 1 clock cycle. Now I know what to do to finish it, but it's very tedious to code. I'm going to have to spend a few days expanding the test suite after this is implemented.
About this serializer... don't worry about the implementation details. Just think of how it should act. That's the harder part.
Might the following instruction folding be prudent? This would save 3 complete instruction opcodes for some future use.
I have noted the instruction restrictions to make this work (removes the NR option on a few instructions).
The CMPS & SUBS instructions have different C settings/results, as do CMPSX & SUBSX.
I moved waitvid to be in the same group as waitcnt/waitpeq/waitpne - there seems no valid reason for waitcnt to use NR as this can be achieved with waitcnt target,#0
-opc-- zcri cccc opcode- operand
-------------------------------------
110000 ---- ---- <spare>
110001 ---- ---- <spare>
-------------------------------------
110101 --0- ---- cmps D,[#]S \\ C=signed(D<S)
110101 --1- ---- subs D,[#]S // C=signed overflow NR no longer valid
-------------------------------------
110111 --0- ---- cmpsx D,[#]S \\ C=signed(D<S+C)
110111 --1- ---- subsx D,[#]S // C=signed overflow NR no longer valid
-------------------------------------
-------------------------------------
111100 000- ---- tjz D,[#]S
111100 010- ---- tjzd D,[#]S
111100 100- ---- tjnz D,[#]S
111100 110- ---- tjnzd D,[#]S
111100 001- ---- ijz D,[#]S || NR no longer valid
111100 011- ---- ijzd D,[#]S || NR no longer valid
111100 101- ---- ijnz D,[#]S || NR no longer valid
111100 111- ---- ijnzd D,[#]S || NR no longer valid
-------------------------------------
111101 000- ---- jp D,[#]S
111101 010- ---- jpd D,[#]S
111101 100- ---- jnp D,[#]S
111101 110- ---- jnpd D,[#]S
111101 001- ---- djz D,[#]S || NR no longer valid
111101 011- ---- djzd D,[#]S || NR no longer valid
111101 101- ---- djnz D,[#]S || NR no longer valid
111101 111- ---- djnzd D,[#]S || NR no longer valid
-------------------------------------
111110 ---- ---- <spare>
-------------------------------------
111111 000- ---- waitvid D,[#]S
111111 0-1- ---- waitcnt D,[#]S || NR no longer valid
111111 1-0- ---- waitpeq D,[#]S
111111 1-1- ---- waitpne D,[#]S
-------------------------------------
Might the following instruction folding be prudent? This would save 3 complete instruction opcodes for some future use.
I have noted the instruction restrictions to make this work (removes the NR option on a few instructions).
The CMPS & SUBS instructions have different C settings/results, as do CMPSX & SUBSX.
I moved waitvid to be in the same group as waitcnt/waitpeq/waitpne - there seems no valid reason for waitcnt to use NR as this can be achieved with waitcnt target,#0
-opc-- zcri cccc opcode- operand
-------------------------------------
110000 ---- ---- <spare>
110001 ---- ---- <spare>
-------------------------------------
110101 --0- ---- cmps D,[#]S \\ C=signed(D<S)
110101 --1- ---- subs D,[#]S // C=signed overflow NR no longer valid
-------------------------------------
110111 --0- ---- cmpsx D,[#]S \\ C=signed(D<S+C)
110111 --1- ---- subsx D,[#]S // C=signed overflow NR no longer valid
-------------------------------------
-------------------------------------
111100 000- ---- tjz D,[#]S
111100 010- ---- tjzd D,[#]S
111100 100- ---- tjnz D,[#]S
111100 110- ---- tjnzd D,[#]S
111100 001- ---- ijz D,[#]S || NR no longer valid
111100 011- ---- ijzd D,[#]S || NR no longer valid
111100 101- ---- ijnz D,[#]S || NR no longer valid
111100 111- ---- ijnzd D,[#]S || NR no longer valid
-------------------------------------
111101 000- ---- jp D,[#]S
111101 010- ---- jpd D,[#]S
111101 100- ---- jnp D,[#]S
111101 110- ---- jnpd D,[#]S
111101 001- ---- djz D,[#]S || NR no longer valid
111101 011- ---- djzd D,[#]S || NR no longer valid
111101 101- ---- djnz D,[#]S || NR no longer valid
111101 111- ---- djnzd D,[#]S || NR no longer valid
-------------------------------------
111110 ---- ---- <spare>
-------------------------------------
111111 000- ---- waitvid D,[#]S
111111 0-1- ---- waitcnt D,[#]S || NR no longer valid
111111 1-0- ---- waitpeq D,[#]S
111111 1-1- ---- waitpne D,[#]S
-------------------------------------
As it is now, you can use NR with the IJZ/IJZD/IJNZ/IJNZD to jump if D = -1, or not. DJZ/DJZD/DJNZ/DJNZD NR will jump if D = 1, or not. Those cases may not find much use, I know.
If it turns out we need more D,S instructions, I'll probably use your map.
Comments
You can, but keep in mind that 'simple shifter' also needs read and write queue buffering, a length counter, and a single register space mapping.
That's why it is easier to 'turn off' the Async Start/Stop bits, but keep everything else common.
Getting more common on SPI, is a similar 'noise-avoidance on the CLK' idea, whereby SPI slaves check for MOD 8 clocks, before acting on the data.
That way, single random injected spikes (aka bonus clock edges), are rejected.
If the P2 can read the RxBitCounter in slave mode, Sw can check for MOD 8 (or MOD 16) etc clocks.
An example of such a SPI slave is here
http://www.onsemi.com/pub_link/Collateral/NCV7720-D.PDF
with ten half bridge pin drivers, this is a flexible looking automotive expander.
jmg
Sure it can be my poor eye's sight, but I just read Chip's last documents and saw no reference to an effective use for the WZ side effects on SERINA or SERINB.
Perhaps it can be used, if not yet clogged anyway, to select between effectively reading the serializer or your intended status register, without bumping the register space.
Please, correct me if I'd been driven thru a mistake, by not completely understanding the whole situation you devised.
Yanomani
In that case, with the loss of the digital video serializer, I'm no longer sitting on the fence about a general-purpose SERDES. I think one is needed. Or else figure out a way to modify the video circuitry to do the SER part again. The DES part is going to be complicated, though.
-Phil
Whilst you could use gymnastics to overlay reads, my example in #153 shows why reading the shifter is not a good idea.
On a slave, you get no useful info at all - much smarter to read the bitcounter in both cases, if you want to track where the shift is up to. The counter-read also allows noise rejection checks, and is unambiguous.
Originally I thought that the counters could be used to provide the clocks to the serialiser. Is this possible and is it simpler?
Here is an idea...
We use CNTRA to provide the transmitter clock and CNTRB to provide the receiver clock. This way we have total control and can generate any frequency based on the internal clock.
Now, we output those counters to 2 pins (we can use external pins P0-P91 or the internal pins P92-95 or P96-P127) - correct???
This means we can bring out the clock(s) if required, and use one common clock if required.
Do the internal pins have the capability of inversion, or do the counter output have the possibility of inversion? If not, then we would need to be able to set which edge to use in the serialiser and deserialiser.
Now all we have to do is specify which pin(s) the serialiser and deserialiser get their input clocks from (which can be the internal P92-P127 or external P0-P91) and which pins the input and output serial data is on. We can invert the serial data by configuring the pins directly can't we?
If the above works, then all the clocking is taken care of within the existing hardware.
Now we only need two 32bit shift registers. We should be able to read and write to both of these registers. They do not need to be buffered/latched etc. We can clear them or preset them or whatever. One would be for input and one would be output.
Lets take this a little further...
We need two, one for input and one for output. What if they were identical, both capable of input and/or output? This means that we have two identical 32bit shift registers A & B. We can use one for transmit and one for receive. Or if we wanted, two for receive only or two for transmit only. Perhaps even a cascade option (we could do this using the internal pins). And by using an internal pin, we can define the state being shifted in for the transmitter.
jmg
Sure, you are totaly right in your considerations!
I'd tried to find some way to discriminate between two possible sources of data to be read, using a single basic hardware address.
Since my english typing skills are very poor, doing it tends to be slower than some lazy and handicapped worm.
Then, I didn't saw your post till I ended my own typing.
Yanomani
Certainly almost anything is possible, but I'd call this rather a waste of the new, expanded counters.
[ Still waiting on full docs there ? ]
The general trend, in even small uC is to have separate Baud rate clocks, rather than consume timers, and that should be followed in P2.
Now that P2 COGs can multi thread, I'd say it is even more likely code in there will need both Serial and timers.
USB is actually 2 pins (both inputs or both outputs). They are normally inverted, and is a special case when the same polarity. This would require external gating.
[/QUOTE]
One of my tricks is to set up a counter in a feedback mode, point Apin at the pin I want to invert, and take the inverted signal from FBpin. (I usually use a counter from my startup cog and set it up with a couple of lines of SPIN)
I've had good results making pseudo-RS485 this way. Any reason it wouldn't work for this? (With code for the special case.. of course)
Note I have included the MUX to select the clock from CTRA or CTRB, and optional inverters on both the inputs and outputs.
The counter shown is the existing CTRA or CTRB.
In addition to the read/write of the 32bit shift register, a 32bit configuration register would be included as follows
(copied and modified from Chip's SERIAL docs)
Before transmitting or receiving data, SFRA/SFRB must be configured: SETSFRA/B D - Set SFRA configuration to %KK_CCCCCCC_E_xxxx_TT_DDDDDDD_RR_SSSSSSS %E = shift register mode %0 = shift register disabled %1 = shift register enabled %KK = clock mode %00 = clock from CTRA output %01 = clock from CTRB output %10 = clock pin enabled (non-inverted) %11 = clock pin enabled (inverted) %CCCCCCC = CLK pin, 0..127 %TT = transmitter mode %00 = transmitter output set "0" (ie disabled) %01 = transmitter output set "1" (ie disabled) %10 = transmitter output pin enabled (non-inverted) %11 = transmitter output pin disabled (inverted) %DDDDDDD = TX pin, 0..127 %RR = receiver mode %00 = receive pin set "0" (will clock 0's into shift register on clock) %01 = receive pin set "1" (will clock 1's into shift register on clock) %10 = receiver pin enabled (non-inverted) %11 = receiver pin enabled (inverted) %SSSSSSS = RX pin, 0..127xxxxxx-xxxx-xxxx-DDooooooo-SSiiiiiii
%xxxxxx_xxxxx_xxxx_TTDDDDDDD_RRSSSSSSS
DDDDDDD = transmit pin P0-127 (PIN_TX)
SSSSSSS = receive pin P0-127 (PIN_RX)
TT = 00 output disabled
DD = 01 DDDDDD refers to the output function of the register and SSSSSSSSS refers to the input register
The idea of basic silicon functionality to assist with various tasks is a great one, but there are trade-offs. The P1 video generator circuit was simple, and we were able to output all kinds of things besides video, not to mention lots of different video. However, we also ended up with a lot of video core code and trade-offs too. Not to mention crappy PAL. The trade-offs in baud rate, bits, clocking smell a little like the accuracy issues P1 had with PAL. If so, it would be good to refine the circuit enough to avoid that.
In P2, more functionality went to the silicon, so now it does video and not so many other things. But, it still requires plenty of software help to get things done. IMHO, a better balance, though having the simple VGA mode of P1 really was cool. We can do that other ways, and there are new features to accomplish that task. IMHO, this isn't outside the Propeller philosophy, so long as it's really not a dedicated peripheral and software plays the role it traditionally has.
IMHO, the balance here is to make this serial something fall somewhere between what the P1 video generator did and what the P2 video generator will do. Just enough to avoid the, "Dang, if we had only done this, PAL would be perfect!" scenario.
Given it's intent is a general purpose serializer, the idea of using software to get the various protocols done makes perfect sense. Personally, I would go as far as possible without ever allowing the silicon to lock up for any reason, leaving the software to cover that kind of ground.
In other uC devices, they don't have the multi-core, nor do they have the redundant features a P2 will have. Keeping things simple makes a lot of sense. Those other devices have the separate clock because they do not have lots of other options and or exercising those options may well consume most of the device, not anywhere near the same consideration on P2.
I trust Chip to not over complicate it, leaving the feature general purpose enough to be used in creative ways like we did the P1 video generators. I also think that general purpose design will highlight right where a better sweet spot will be for the next chip release after P2, which maybe won't take the same amount of time... (lessons learned about process, synth tools, reusing smart I/O done on P2, etc...)
Above all, keep the silicon deterministic and free from lockups. Those things should be the domain of software. People get smarter over time, silicon that is too dedicated purpose gets more limiting over time.
Before this slope gets any slipperier, let's dial back a bit. We've got 160 MIPS at our disposal. Why do we even need a hardware SERDES? 10 MBaud Manchester should be possible in software, as well as fast SPI. Using a hardware UART for RS232-style comms is just nuts, given that eight or more done in software would handily fit in one cog. Chip came up with an elegant high-speed UART for Prop-to-Prop communication, but it seems to have opened Pandora's box. Do we even need it? I will miss the P1's video VGA mode. But with eight times the P1's speed, maybe not.
Anyway, I would gladly trade any kind of SERDES for as many counters and different counter modes as could be crammed into a cog.
-Phil
Why would you couch this in such negative terms? What product is perfect? What responsible manufacturer doesn't strive to improve or differentiate his/her products?
Has the entry point for the Prop2 monitor changed?
I don't seem to be able to get at it anymore with $70c ?
I'm using PST as a terminal and I get no response?
Have I missed something?
Cheers
Brian
I just tried entering the Prop2 monitor @ $700 instead of $70c and it worked!
Is this correct?
Cheers
Brian
It is because you have 160 MIPS that you need hardware support. 10MHz is slow, by modern link standards.
See my thread titled Prop 2 Serial support for FTDI Fast Serial mode - that can run at 50MHz, duplex
A COG represents a large investment in silicon, it is wasteful to use all that to flip bits.
A COG should be running software, not wasted (slowly) emulating a flip-flop or shifter.
Note a simple serial block, will allow lower CPU clock speeds, to save a lot of power.
Chip has improved the P2 counters (a lot) , I believe. ( the info is just a little slow coming out ... )
[Which is also why I think using Counters as Baud clocks is too wasteful, ( not to mention the jitter) ]
I've never bought into the notion that any task, no matter how seemingly trivial, is "wasteful" of the Prop's resources. This is especially true now, with the advent of multitasking. The cogs are designed to be universal, software-driven peripherals whose architecture borders on microcode. People say they want a universal SERDES -- and I thought for awhile that I did, too -- but no one has really defined what that means in terms of the variety of word lengths (how about zero insertion/deletion for SDLC?) and synchronization. Why not add mod/demod (e.g. FM0, FM1, Manchester) while we're at it? At some point, it gets to be like pulling a thread on a sweater.
-Phil
What I still are missing in counters module are simple FREQUENCY measure input counter. (self resettable in time measure period elapsed)
That needs many times to control real world things
Huh? The Prop1 does that easy peasy. Just setup edge counting on a Cog counter and sample the counter at fixed interval. Or, bit banging it on a Cog isn't bad either.
Where half way there with the GETPHZA and GETPHZB instructions.
Sure, if you ignore speed issues for a moment, COG resource is essentially free, until you run out of it wiggling bits, then it becomes very expensive indeed.
Given the hard ceiling on COG Code size, I'd rather see all that opcode-engine silicon doing real work, not pretending to be a FF.
Muilti-tasking just puts more pressure on COG ceiling, as users can now pack more into one COG.
Yes, I've mentioned reciprocal counters before to Chip, hopefully the new Counters will support this.
The resource needed is not complex, just edge capture (which I think is in there?), and atomic control of both counters. (That's mostly a register mapping detail )
I'd consider it important for users to exercise the new counters, before the tapeout, but there is only one Chip.
Hope we can avoid ending up with a bunch of half baked over complex solutions that have to be carried forward into any future Prop developments.
It already disturbs me how huge the Prop II instruction set has become.
Or do I worry too much?
That's right. It's at $700 now.
The Prop2 counters do that. They can measure frequency or period.
No problems. I just caught up on this thread. I'm too tired now to address every question. Thanks for thinking more about this.
All day I've been implementing the new RDSTK and WRSTK instructions which r/w the stack with SPA/SPB expressions, just like PTRA/PTRB for hub memory. I think it will take through tomorrow to get this done. It was very hard, at first, until I charted out all the possible juxtapositions of stack read and write instructions in the pipeline and how they might clobber each other. I've got it now so that most reads are tucked into stage 3, keeping things at 1 clock cycle. Now I know what to do to finish it, but it's very tedious to code. I'm going to have to spend a few days expanding the test suite after this is implemented.
About this serializer... don't worry about the implementation details. Just think of how it should act. That's the harder part.
http://forums.parallax.com/showthread.php/150588-Big-update-for-DE2-115-and-DE0-Nano-users-w-add-on-boards?p=1211021&viewfull=1#post1211021
Might the following instruction folding be prudent? This would save 3 complete instruction opcodes for some future use.
I have noted the instruction restrictions to make this work (removes the NR option on a few instructions).
The CMPS & SUBS instructions have different C settings/results, as do CMPSX & SUBSX.
I moved waitvid to be in the same group as waitcnt/waitpeq/waitpne - there seems no valid reason for waitcnt to use NR as this can be achieved with waitcnt target,#0
As it is now, you can use NR with the IJZ/IJZD/IJNZ/IJNZD to jump if D = -1, or not. DJZ/DJZD/DJNZ/DJNZD NR will jump if D = 1, or not. Those cases may not find much use, I know.
If it turns out we need more D,S instructions, I'll probably use your map.