Chip: Do you expect the binary instruction encodings to be in flux for a while? I'm wondering if I should wait for things to settle down before making any further changes to PropGCC.
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 forgot about the differential drive, even though I just about danced around the room when I first read it.. I checked, my trick has exactly 1 clock delay per the docs, and I just measured it to be exactly so in case I misread. Still works pretty good for a few kbaud pseudo-RS485 on prop1!
I'm off to see if i can tune this for correct deadtime for an H bridge! (and still have enough IPS for PID and feedback)
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?
"Such negative terms" methinks overstates what I actually said. Regardless, yes, no product is perfect - but twiddle enough and at some point it no longer becomes the same product.
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.
I was thinking more along the lines of a P2B later where you might want to add some more instructions while keeping opcode compatibility.
For the transmit part, I would envision something like the P1's video output. Make it possible to select among 1, 2, or 4 output pins. That should cover most serial protocols. The output data would interleave bits for the various pins. For example, for 8-bit clocked data output (2 pins), the value loaded into the shifter would look like this: 1<data7>0<data7>1<data6>0<data6> ... 1<data0>0<data0>, the 1s and 0s being the bit clock.
To go along with this scheme, a couple helper instructions are needed to spread the data bits. By that I mean to replicate the data bits pair-wise or quad-wise. For example, pair-wise replication would convert %00000000_110110010 to %1111001111_00001100. Then the clock bits could be merged in via and and or before the next waitser, or whatever. This would also make it easy to do Manchester encoding, since all you'd have to do after pair-wise replication is xor the data with $55555_55555 (or $aaaaa_aaaaa, I can't remember which) and send it as one-pin serial. For choosing between LSB-first and MSB-first, the rev instruction is your friend, i.e. no need to make shift direction a feature of the hardware.
The idea is to help the software, not replace it, in keeping with Prop principles. This provides the maximum flexibility for as-yet-unthought-of apps and techniques.
Jazzed, I'm not sure what you mean by "such complexity." Please elaborate. To me a "simple SERDES" would be a combination '595 and '165 with three pins for latch, serial data, and clock. But I'm not sure how useful that would be in this context.
Aye, there's the rub. There's nothing simple about a USART, especially on the receive side, and more especially if you want to make it "Universal" (that's what the "U" stands for). My approach is to add the absolute minimum of hardware required to help facilitate the "U" part in software.
Aye, there's the rub. There's nothing simple about a USART, especially on the receive side, and more especially if you want to make it "Universal" (that's what the "U" stands for). My approach is to add the absolute minimum of hardware required to help facilitate the "U" part in software.
I may have missed this somewhere: is the current UART receiver only active (i.e. looking for the STOP/START transition and sampling bits) as part of the SERINx instruction? Or is the receiver running asynchronously and SERINx simply waiting for the receiver to have filled an 8-bit buffer and entered the idle state (i.e. finished receiving 8 bits)?
Regardless, yes, no product is perfect - but twiddle enough and at some point it no longer becomes the same product.
Are the Chevy Volt and the Chevy Silverado the same product?
The twiddling is intentional. Don't you see that? That is what invested manufacturers do! To turn that into some kind of referendum on the P1 is ludicrous.
Are the Chevy Volt and the Chevy Silverado the same product?
The twiddling is intentional. Don't you see that? That is what invested manufacturers do! To turn that into some kind of referendum on the P1 is ludicrous.
So, if we add interrupts, hard peripherals, etc. - intentionally! - to P2 that still fits with the initial Propeller ideal?
Obviously, at some point they become the same "thing" in name only. Moreover, as can be seen all over the Parallax site, including these very forums, Propeller was as much a concept as a "product" - a different way to do micros.
Are the Chevy Volt and the Chevy Silverado the same product?
WTH anyway? You're the one who used the term 'product' ("What product is perfect?"). What I initially mentioned was the Propeller concept or model. So your question, besides being merely rhetorical, has no context here.
About this serializer... don't worry about the implementation details. Just think of how it should act. That's the harder part.
Agreed.
Expanding on the fully granular length (bit frame) as a split register : ie write sets frame, read gives how many bits have shifted, plus passes your 2 state bits in Async mode.
SW writes set Length, and SW reads check progress. This can now easily check via SW
* Waiting on Start
* Currently Receiving
* exact number of clocks, (on a slave) to catch noise errors in SPI (see ref earlier)
* Tx Done, or even Tx nearly done
* Rx Done, or even Rx nearly done
* Async frame error on Rx is used in some protocols, could be another bit ?
Structural change : Make these small (5 bit) Tx and Rx bit-frame counters separate.
Why ?
This now covers 1 or 2 stop bits, without needing any register bit, or special state, and allows TX to send exact BREAK, without disturbing Rx.
For small payloads, this should allow FT232H fast serial, a choice of with/without handshake.
The FT232H base frame is ~14 bits (FT.RX, P2.TX) now easily set.
It also allows SW to use the inter-char time, as signaling, or cadence.
The Prop can easily check each char timestamp, and Prop-Prop links, can modulate that via the TxFrame.
I've seen edge-modulation protocols, where more data is sent using fewer edges, usually thru some slow isolation barrier, and/or for EMC reasons.
Here a P2 serial block can support that, by change of the TxFrame. A 5 bit value can encode 4 bits in 16..32 widths.
and it is easy to explain, and widely generic: Each of Tx & Rx block is a [Baud Divider + Shifter + BitFrame]
Shifter is Sync or Async(as now) (with pin mapping as described earlier )
Async can include a clock (but still has Start bit / Stop bit states)
Separate bit-frame counter set fields should also be safer, as changes to Tx or Rx state settings, do not interact, and on duplex engines, that matters.
Buffers/queues need to be only large enough to allow 'gapless' streaming in all modes.
What I initially mentioned was the Propeller concept or model.
So you are more a Propeller philosopher than a Propeller user? Interesting, but not very fulfilling.
As a Propeller philosopher, are you defending or attacking the Propeller concept? I can't tell. The various posts you've made seem to be all over the place on this point.
I may have missed this somewhere: is the current UART receiver only active (i.e. looking for the STOP/START transition and sampling bits) as part of the SERINx instruction? Or is the receiver running asynchronously and SERINx simply waiting for the receiver to have filled an 8-bit buffer and entered the idle state (i.e. finished receiving 8 bits)?
It would need to be active once started, as the P2 SW has no way of knowing when a start bit may arrive.
That is what Chip's state engine does.
The core idea is to allow the P2 to be doing something else, whilst the low-level, simple HW, collects bits.
This should also work nicely with threads, a tiny code stub can check the serialiser, and write to a larger (usersize) buffer, that the slower main thread, can empty at its leisure.
So you are more a Propeller philosopher than a Propeller user? Interesting, but not very fulfilling.
So you are more of a clown than someone who wants to have a serious, adult discussion? Interesting, but not very productive.
As a Propeller philosopher, are you defending or attacking the Propeller concept? I can't tell. The various posts you've made seem to be all over the place on this point.
NO, they are not all over the place; in fact, they are quite consistent - once you've made the time and effort to read and understand what I've written.
So you are more of a clown than someone who wants to have a serious, adult discussion? Interesting, but not very productive.
NO, they are not all over the place; in fact, they are quite consistent - once you've made the time and effort to read and understand what I've written.
Ugh. And I thought that the P2 forum was immune to religious wars....
Aye, there's the rub. There's nothing simple about a USART, especially on the receive side, and more especially if you want to make it "Universal" (that's what the "U" stands for). My approach is to add the absolute minimum of hardware required to help facilitate the "U" part in software.
Chip has said the current implementation is simple. He even described the states. One good reason for this is it doesn't oversample and average, hence it can operate at full clock rate shifting on both send and receive, nor lock to subsequent transitions beyond the start bit. It really isn't much more than a simple shifter with internal clock (clock rate control probably being half the hardware), and some assumptions like number of bits per word and an idle level make the state machine relatively simple. Certainly simpler than I2C for example.
It just occurred to me SPI normally uses "chip select" for framing but as has been demonstrated by the FTDI High Speed Serial mode the Prop doesn't have to be that way as a slave itself. That suggests the length control from the UART could be used as a slave too. Eliminating the need for another pin assignment. That might restrict what can talk to it as a slave though.
Please do the same and move the argument over to the General Discussions area, where everyone goes for recreation.
I have no idea who you're directing this at. But on the off-chance that you've mistakenly taken me as an (the) object for your order, I'll simply remind you that my post was directly relevant to the topic of P2 development. That people can't bother themselves to read and understand what I wrote or, more importantly, to reply in a civil, grown-up fashion isn't my problem.
In the future, if you must give orders mixed with sideways disparagement, make sure you direct them at the appropriate person.
Comments
Actually, I am caught-up-in (and enjoying) the fast pace and excitement of this groups engineering efforts.
But I am wondering:
Or, is there Pointer and Counter registers, that the I/O uses to get/save data directly to/from memory (i.e., Serial DMA)?
--
Eldonb46
I forgot about the differential drive, even though I just about danced around the room when I first read it.. I checked, my trick has exactly 1 clock delay per the docs, and I just measured it to be exactly so in case I misread. Still works pretty good for a few kbaud pseudo-RS485 on prop1!
I'm off to see if i can tune this for correct deadtime for an H bridge! (and still have enough IPS for PID and feedback)
Wish I could afford to play here....
If Chip is able to produce a very simple SERDES (USART) then great.
If not, I can easily kludge up a fast SPI master with Chip's current UART definition by wasting another COG ... ugh.
To go along with this scheme, a couple helper instructions are needed to spread the data bits. By that I mean to replicate the data bits pair-wise or quad-wise. For example, pair-wise replication would convert %00000000_110110010 to %1111001111_00001100. Then the clock bits could be merged in via and and or before the next waitser, or whatever. This would also make it easy to do Manchester encoding, since all you'd have to do after pair-wise replication is xor the data with $55555_55555 (or $aaaaa_aaaaa, I can't remember which) and send it as one-pin serial. For choosing between LSB-first and MSB-first, the rev instruction is your friend, i.e. no need to make shift direction a feature of the hardware.
The idea is to help the software, not replace it, in keeping with Prop principles. This provides the maximum flexibility for as-yet-unthought-of apps and techniques.
-Phil
A simple SERDES would not be much more risky than the current UART solution and would provide much more return on effort.
-Phil
All we need is a simple USART.
-Phil
I'll take whatever Chip thinks is sufficient.
Are the Chevy Volt and the Chevy Silverado the same product?
The twiddling is intentional. Don't you see that? That is what invested manufacturers do! To turn that into some kind of referendum on the P1 is ludicrous.
Cool
This is probably not a good time to ask about Prop2 Counter documentation, but some FPGA test coverage in the field would seem a good idea ?
Obviously, at some point they become the same "thing" in name only. Moreover, as can be seen all over the Parallax site, including these very forums, Propeller was as much a concept as a "product" - a different way to do micros.
Yeah, real ludicrous.
Agreed.
Expanding on the fully granular length (bit frame) as a split register : ie write sets frame, read gives how many bits have shifted, plus passes your 2 state bits in Async mode.
SW writes set Length, and SW reads check progress. This can now easily check via SW
* Waiting on Start
* Currently Receiving
* exact number of clocks, (on a slave) to catch noise errors in SPI (see ref earlier)
* Tx Done, or even Tx nearly done
* Rx Done, or even Rx nearly done
* Async frame error on Rx is used in some protocols, could be another bit ?
Structural change : Make these small (5 bit) Tx and Rx bit-frame counters separate.
Why ?
This now covers 1 or 2 stop bits, without needing any register bit, or special state, and allows TX to send exact BREAK, without disturbing Rx.
For small payloads, this should allow FT232H fast serial, a choice of with/without handshake.
The FT232H base frame is ~14 bits (FT.RX, P2.TX) now easily set.
It also allows SW to use the inter-char time, as signaling, or cadence.
The Prop can easily check each char timestamp, and Prop-Prop links, can modulate that via the TxFrame.
I've seen edge-modulation protocols, where more data is sent using fewer edges, usually thru some slow isolation barrier, and/or for EMC reasons.
Here a P2 serial block can support that, by change of the TxFrame. A 5 bit value can encode 4 bits in 16..32 widths.
and it is easy to explain, and widely generic:
Each of Tx & Rx block is a [Baud Divider + Shifter + BitFrame]
Shifter is Sync or Async(as now) (with pin mapping as described earlier )
Async can include a clock (but still has Start bit / Stop bit states)
Separate bit-frame counter set fields should also be safer, as changes to Tx or Rx state settings, do not interact, and on duplex engines, that matters.
Buffers/queues need to be only large enough to allow 'gapless' streaming in all modes.
So you are more a Propeller philosopher than a Propeller user? Interesting, but not very fulfilling.
As a Propeller philosopher, are you defending or attacking the Propeller concept? I can't tell. The various posts you've made seem to be all over the place on this point.
It would need to be active once started, as the P2 SW has no way of knowing when a start bit may arrive.
That is what Chip's state engine does.
The core idea is to allow the P2 to be doing something else, whilst the low-level, simple HW, collects bits.
This should also work nicely with threads, a tiny code stub can check the serialiser, and write to a larger (usersize) buffer, that the slower main thread, can empty at its leisure.
NO, they are not all over the place; in fact, they are quite consistent - once you've made the time and effort to read and understand what I've written.
and attention.
Please do the same and move the argument over to the General Discussions area, where everyone goes for recreation.
Thanks
Rich
Chip has said the current implementation is simple. He even described the states. One good reason for this is it doesn't oversample and average, hence it can operate at full clock rate shifting on both send and receive, nor lock to subsequent transitions beyond the start bit. It really isn't much more than a simple shifter with internal clock (clock rate control probably being half the hardware), and some assumptions like number of bits per word and an idle level make the state machine relatively simple. Certainly simpler than I2C for example.
In the future, if you must give orders mixed with sideways disparagement, make sure you direct them at the appropriate person.