Shop Learn
P2 Smart Pins - Page 8 — Parallax Forums

P2 Smart Pins

15681011

Comments

  • Don't be. It's all looking great and useful Chip. Our games will begin soon enough!

  • jmgjmg Posts: 14,595
    cgracey wrote: »
    That's my understanding, too. I think jmg was thinking about some intra-cycle abort mechanism. It seems to me that the triangle PWM, as it stands, is all we need.
    Yes, deadband is natural from Triangle Wave, but Triangle Wave PWM still drives MOSFETS and MOSFETS can still need protection in such systems.

  • jmgjmg Posts: 14,595
    evanh wrote: »
    I'm pretty confident that doesn't matter. The two measurements run independently, and asynchronously to the signal, and give a separate result each. The two results are both as accurate as can be achieved respectively. One is more precise than the other depending on the pulse rate vs sample period.
    ?? I'm not sure what you are reading.

    Reciprocal Counting is simple:
    You measure some whole number of cycles, and time how long that whole number of cycles takes.

    Frequency = wCycles/wTime

    Those two measurements are certainly not independently, nor are they asynchronously to the signal , so both your assertions are incorrect.

    It is very important they run concurrently, otherwise you have no idea how many cycles wTime relates to, and they also must be Captures done synchronously to the signal, in order to know you have whole cycles.

    Plus, you need care to be sure the same edge is used, and at high frequencies SW alone is not enough to do that. HW support can be as simple as a FlipFlop, but something is needed & aperture effects need attention.

    Try some numbers on 'independent, and asynchronous' captures, and see how that goes.
  • evanhevanh Posts: 10,423
    edited 2016-02-04 21:32
    They are parallel circuits, measuring the same signal source, but still independent of each other and there is no choice but to be asynchronous to the signal. The signal has no clock of it's own. It's just another variant of oversampling really (That probably pre-dates the coining of digital sampling).

    Parallel flip-flops, one for each method of measure, is fine for capturing the same edge in parallel. If the edge rate is faster than the system clock then aliasing occurs and neither system works.

    There is always potential for a particular edge to fall on either side of the system clock sampling but that noise accumulates out over time. It doesn't matter if one circuit see it one way and the other circuit see it the other way for a particular sample. That's all within the normal sampling noise limits.
  • jmgjmg Posts: 14,595
    evanh wrote: »
    They are parallel circuits, measuring the same signal source, but still independent of each other and there is no choice but to be asynchronous to the signal. It's just another variant of oversampling really.

    Parallel flip-flops, one for each method of measure, is fine for capturing the same edge in parallel. If the edge rate is faster than the system clock then aliasing occurs and neither system works.
    Dual paths should ideally be avoided when crossing clock domains.

    However, I think this will not be an issue, as I expect all Smart pins have a Sampling FF per pin.
    (Some MCUs have two in series, that helps noise filtering, but does lower the change-rate)

    That means there is a single path across the clock domains, for a single pin.

    Chip may be able to confirm Pin sampling FF details ?

    (This FF is separate from the Capture trigger FF I mention.)


  • evanhevanh Posts: 10,423
    edited 2016-02-04 21:43
    There is no clock in the signal so there is no domain crossing.

    And even if there was a clock, like with ADC bitstreams, it is only an optional feature for power efficient/easy transfer. The signal is still analogue in nature so can be happily up-sampled.
  • jmgjmg Posts: 14,595
    evanh wrote: »
    There is no clock in the signal so there is no domain crossing.

    In the teaching I had, going from ASYNC to SYNC, certainly counts as clock domain crossing.
    Any time the edges are not same-clock aligned, you need care, a second clock wire is not a prerequisite to need that care, all it needs is for the edge to be derived from another clock, (or subject to uncertain delays).

  • evanhevanh Posts: 10,423
    UARTs are a different beast, there the individual bits are required 100%, it is not an analogue signal. A detail, presumably due to it being a digital data transfer, a UART is in fact trying to find a synchronous signal between the stop and start bits even though it has no embedded clock.
  • Those staggered green phosphor waveforms remind me of something else

    IMG_0192.jpg


  • cgraceycgracey Posts: 13,403
    edited 2016-02-05 04:35
    I found a bug that I'm fixing now.

    When a smart pin completes some task, it signifies by raising its IN signal and updating its 32-bit result value which can be read by the PINREAD instruction. The result value is conveyed four bits per clock and the system counter's three LSBs are used to mux the eight nibbles as they go out. The bug is that IN signals right away, while the result value starts coming up to 7 clocks later, while the cog needs to begin inputting on a certain 8th system counter value. This causes old values to be read right after IN goes high.

    To fix this, I'm going to add a fifth bit to the return value mechanism, so that the smart pin can signal right away when a new value is coming. This will save a net 28 flops in each smart pin and get result values back to cogs deterministically from IN rise, as the system counter won't be needed, anymore, to coordinate the messaging.
  • cgraceycgracey Posts: 13,403
    Tubular wrote: »
    Those staggered green phosphor waveforms remind me of something else

    IMG_0192.jpg


    Tubular, you were rather young in the Osborne days, weren't you?
  • re:green phosphor

    I still love mono green. My first PC was a IBM compatible Commodore PC 10 with one floppy drive (before color, affordable Hard Drives etc) with a green Mono screen. Yea, back in the good old days :)

    So we have a net of 28 flops in each smart pin available . What feature can we add now ? LOL
  • Rather young, yes indeed. Me and my brother had to beg dad to bring the O1 home at weekends so we could play 'tbreak' and program mbasic.

    Reflecting upon it, the portability of the O1 (being able to use it on weekends) played a huge role in getting us both into programming and engineering/computer science.

    The portability of the Osborne 1 also confused the Qantas air stewards, who declared "there is no way you are taking that sewing machine aboard this aircraft"
  • cgraceycgracey Posts: 13,403
    edited 2016-02-05 06:15
    re:green phosphor

    I still love mono green. My first PC was a IBM compatible Commodore PC 10 with one floppy drive (before color, affordable Hard Drives etc) with a green Mono screen. Yea, back in the good old days :)

    So we have a net of 28 flops in each smart pin available . What feature can we add now ? LOL

    My old Parallax friend/cofounder Lance told this story once, about budgeting:

    "I wanted to get a new TV, so a decided I'd spend $100. I got to the store and saw a really nice TV for $500. I realized that was too expensive, but I found another pretty good one for only $300. So, I bought that one and SAVED $200."
  • cgraceycgracey Posts: 13,403
    Tubular wrote: »
    Rather young, yes indeed. Me and my brother had to beg dad to bring the O1 home at weekends so we could play 'tbreak' and program mbasic.

    Reflecting upon it, the portability of the O1 (being able to use it on weekends) played a huge role in getting us both into programming and engineering/computer science.

    The portability of the Osborne 1 also confused the Qantas air stewards, who declared "there is no way you are taking that sewing machine aboard this aircraft"

    I learned the same way, but on an Apple ][ that my dad would bring home from work on the weekends. Boy, everything was so new and engrossing back then. There are still new frontiers, but it seems like it takes a long hike to get to them.
  • cgraceycgracey Posts: 13,403
    edited 2016-02-05 12:48
    Okay. I've got the smart pin reading problem solved by making those changes. It's rock-solid now and the smart pins shrunk by about 10 ALM's. This is a much better approach than using the system counter to coordinate transfers, since messages can now start on any clock, coincident with INA rising. This simplified both the smart pin side and the cog side.

    In order to keep the cog from hanging on potential continuously-overlapping new messages, since they now start asynchronously, the message sender in the smart pin skips any new message when the current message hasn't shifted out all the way at least once. This could have been a problem if you were measuring states that were occurring faster than the message sending, which takes 8 clocks. Meanwhile, the smart pin keeps resending the current message, so that the cog can get it whenever it's ready to. A new message can occur at any time and the smart pin just sets that 5th bit that signifies start-of-message, for one clock, in order to tell the cog to reset its nibble counter, so it will tack the current nibble onto the incoming 7, in order to get the whole 32-bit value. In case a smart pin is not configured and you try to read it, you will just get $00000000, because 8 clocks will elapse without getting that 5th-bit pulse, and the smart pin clears its nibble output when disabled.

    I don't know why I didn't anticipate this message/IN phase problem the first time around, but it's nailed now.

    For what it's worth, here is the Verilog in the smart pin than sends out messages:
    // message output
    
    reg [36:0] msg;
    
    wire msgr		=	msg[34:32] == 3'b111 && m_smart;			// restart-of-message flag with cancel
    
    wire [3:0] msgi		=	{msg[35], 3'b0} | msg[34:32] + 3'b001;			// message-sent flag and nibble counter
    
    wire [31:0] msgd	=	{msg[3:0], msg[31:8], msg[7:4] & {4{m_smart}}};		// data shifter with cancel
    
    always @(posedge clk)
    if (m_smart || msg[36] || (|msg[3:0]))							// update if smart pin mode or outputs not 0
    	msg		<=	msgi[3] && signal_	?	{1'b1, 4'b0, result_}	// start new message if current message sent
    							:	{msgr, msgi, msgd};	// update flags and shift data
    
    assign pin_msg		=	{msg[36], msg[3:0]};					// output start flag and message nibble
    

    m_smart = smart pin mode active
    signal_ = capture result_ for message output and raise IN to alert cog(s)
    result_ = 32-bit data to be captured and sent as message (repeatedly, until a new signal_ event)
  • SeairthSeairth Posts: 2,474
    edited 2016-02-05 12:44
    Tubular wrote: »
    Rather young, yes indeed. Me and my brother had to beg dad to bring the O1 home at weekends so we could play 'tbreak' and program mbasic.

    Reflecting upon it, the portability of the O1 (being able to use it on weekends) played a huge role in getting us both into programming and engineering/computer science.

    The portability of the Osborne 1 also confused the Qantas air stewards, who declared "there is no way you are taking that sewing machine aboard this aircraft"

    Ha! :) For me, it was the Kaypro II, which we always just referred to as "the luggable." It was turbo pascal that really got me started. This brings back an old memory...

    My dad had brought the luggable along when we were visiting family for Christmas (I'm guessing I was about 10 at the time). While we were there, I wrote my first real program, which simply output an increasing frequency on the speaker until you pressed the space bar. It would then print out the frequency. The idea was to press the space bar when you couldn't hear the sound any more. The entire family, young and old, took turns seeing what their hearing range was.
  • cgraceycgracey Posts: 13,403
    edited 2016-02-05 12:51
    All right. Now that the messaging problem is fixed, I was able to finish testing the measurement modes. What is left to test is the custom configurable modes and the serial modes.

    One thing that has me kind of wishing for a better way are the mnemonics and operand conventions for these smart pin instructions.

    Here is what we have:
    		pinmode	pm2,#14
    		pinsetx	#0,#14
    		pinsety	##$1_0000,#14
    		pinread	pinval,#14
    		pinack	#14
    

    Simple enough, but it's too bad that the pin number winds up all over the place, horizontally.

    It makes me think that swapping D and S, as far as source code goes, might be a good idea:
    		pinmode	#14,pm
    		pinsetx	#14,#0
    		pinsety	#14,##$1_0000
    		pinread	#14,pinval
    		pinack	#14
    

    That would be kind of confusing, though, for development tool makers and also the PINREAD instruction, as D-to-be-written would be on the right.

    Maybe the mnemonics could improve, too.
  • cgracey wrote: »
    All right. Now that the messaging problem is fixed, I was able to finish testing the measurement modes. What is left to test is the custom configurable modes and the serial modes.

    One thing that has me kind of wishing for a better way are the mnemonics and operand conventions for these smart pin instructions.

    Here is what we have:
    		pinmode	pm2,#14
    		pinsetx	#0,#14
    		pinsety	##$1_0000,#14
    		pinread	pinval,#14
    		pinack	#14
    

    Simple enough, but it's too bad that the pin number winds up all over the place, horizontally.

    It makes me think that swapping D and S, as far as source code goes, might be a good idea:
    		pinmode	#14,pm
    		pinsetx	#14,#0
    		pinsety	#14,##$1_0000
    		pinread	#14,pinval
    		pinack	#14
    

    That would be kind of confusing, though, for development tool makers and also the PINREAD instruction, as D-to-be-written would be on the right.

    Maybe the mnemonics could improve, too.

    This may not be too much of an concern if constants are used instead of literals:
    		pinmode	pm2, #DAC0
    		pinsetx	#0, #DAC0
    		pinsety	##$1_0000, #DAC0
    		pinread	pinval, #DAC0
    		pinack	#DAC0
    

    But don't ask for new mnemonics! You should know by now that there will be days (weeks?) of debate and no consensus!
  • mindrobotsmindrobots Posts: 6,506
    edited 2016-02-05 13:29
    #14 should be some meaningful constant in most cases instead of an immediate value which will make the alignment look totally different! :)

    In my mind, your second group works for all except 'pinread'. It each instruction, the D field should be the pin# because the pin is the destination of the MODE, SETX, SETY and ACK.

    For 'pinread #14,pinval' it is anomalous like wrbyte/wrword/wrlong. So it can be made analogous to them. It becomes

    wrpin #14,pinval

    where you are writing the value of the pin to memory sort of like you are writing from COG to HUB with the wrxxxx instructions.
  • cgraceycgracey Posts: 13,403
    mindrobots wrote: »
    #14 should be some meaningful constant in most cases instead of an immediate value which will make the alignment look totally different! :)

    In my mind, your second group works for all except 'pinread'. It each instruction, the D field should be the pin# because the pin is the destination of the MODE, SETX, SETY and ACK.

    For 'pinread #14,pinval' it is anomalous like wrbyte/wrword/wrlong. So it can be made analogous to them. It becomes

    wrpin #14,pinval

    where you are writing the value of the pin to memory sort of like you are writing from COG to HUB with the wrxxxx instructions.

    That would be a good way to do it, but a little tricky on the brain.

    Now, you were joking about the alignment, right?
  • ErNaErNa Posts: 1,494
    cgracey wrote: »
    All right.
    		pinmode	pm2,#14
    		pinsetx	#0,#14
    		pinsety	##$1_0000,#14
    		pinread	pinval,#14
    		pinack	#14
    

    Simple enough, but it's too bad that the pin number winds up all over the place, horizontally.

    It makes me think that swapping D and S, as far as source code goes, might be a good idea:
    		pinmode	#14,pm
    		pinsetx	#14,#0
    		pinsety	#14,##$1_0000
    		pinread	#14,pinval
    		pinack	#14
    

    That would be kind of confusing, though, for development tool makers and also the PINREAD instruction, as D-to-be-written would be on the right.

    Maybe the mnemonics could improve, too.

    This winding up problem I simply solve this way:
    		pinmode	pm2,        #14
    		pinsetx	#0,         #14
    		pinsety	##$1_0000,  #14
    		pinread	pinval,     #14
    		pinack	            #14
    
  • When this happens, I just center on the comma.

    Reversing D seems unwise.

  • rjo__rjo__ Posts: 2,115
                    pinmode	#14,pm
    		pinsetx	#14,#0
    		pinsety	#14,##$1_0000
    		pinread	#14,pinval
    		pinack	#14
    
    

    To me this is best... except the pinread... to be consistent with all other reads... it should be
    pinread pinval, #14
    
  • label		pinmode	      pm2,#14	'comment
    		pinsetx	       #0,#14
    		pinsety	##$1_0000,#14
    		pinread	   pinval,#14	'that other comment
    		pinack	          #14
    
  • I agree that is makes more sense that the pin number be the destination register, but I get the sense from Chip's original comment that a reversal of the fields wouldn't be at the bit-encoding level, just in the PASM instructions. If that's the case, I think it should be left as it is to stay consistent with the rest of the PASM instruction set. Other languages are free to do what they want.
  • jmgjmg Posts: 14,595
    cgracey wrote: »
    It makes me think that swapping D and S, as far as source code goes, might be a good idea:
    		pinmode	#14,pm
    		pinsetx	#14,#0
    		pinsety	#14,##$1_0000
    		pinread	#14,pinval
    		pinack	#14
    

    That makes sense, but you should list all pin access opcodes, and have them consistent across all that apply to pins.
    D & S have less meaning when not registers, and PIN is first in the name.

    cgracey wrote: »
    Maybe the mnemonics could improve, too.
    They all start with PIN, which seems sensible and makes them easy to find.
    In fact, all Pin-access mnemonics could follow that rule, for clarity.

    That just leaves the suffix part, of mode, setx, sety,read,ack
    Of those, mode,read,ack seem self-explaining, which only leaves setx, sety sounding like Graphics/pixel commands ?
    What would be clearer for those 2 ?


  • evanhevanh Posts: 10,423
    I'm a 68k kind of gal, myself, so D on the right for all instructions would suit me just fine. :P ... Seriously, though, I'm with Searith and Spud on reasoning. Consistency is more important than what is really only a perceived untidiness.
  • cgraceycgracey Posts: 13,403
    evanh wrote: »
    I'm a 68k kind of gal, myself, so D on the right for all instructions would suit me just fine. :P ... Seriously, though, I'm with Searith and Spud on reasoning. Consistency is more important than what is really only a perceived untidiness.

    I agree and the D,S. It should stay the same. Maybe the mnemonics could improve, though.
  • cgraceycgracey Posts: 13,403
    Okay! Testing is done.

    I found a few things to fix and tune up along the way, and it seems to all be in order now.

    Hopefully, I will get new FPGA files out tomorrow.

    Over the next few days, I will be working on the smart pin documentation. I'm anxious to see what you guys think of smart pins. At this early point, I see they can do a lot of things, but I don't have the usage experience, yet, to know quite how this reshapes the programming mindset that we are used to. It's a new frontier, of sorts.
Sign In or Register to comment.