Shop OBEX P1 Docs P2 Docs Learn Events
Propeller II update - BLOG - Page 79 — Parallax Forums

Propeller II update - BLOG

17677798182223

Comments

  • cgraceycgracey Posts: 14,133
    edited 2013-09-10 16:38
    KeithE wrote: »
    It's a little late but we've gotten custom sockets built by Aries (http://www.arieselec.com/) for low pin count (36-64 pins) WLBGAs and fpBGAs for about $400 each, and TTS (http://tts-grp.com/) for about 3X that. If you're using a standard package, then maybe one of them has an off-the-shelf product that would work.

    Thanks for the test socket pointers, Guys.
  • jmgjmg Posts: 15,155
    edited 2013-09-10 16:55
    cgracey wrote: »
    That AD7400 is a 2nd-order delta-sigma modulator which requires a complicated digital filter after it to produce 16-bit samples.

    I think the AD7400 could work, in counter mode, but does ideally need CLK and CLKEN signal connection to P2 counter.

    Actually 2 counters, as the MCLKOUT is somewhat variable, you would feed MCLKOUT to 2 Ctrs, and one would be always Enabled, the other is MDAT enabled. Now the counter ratio, is the voltage ratio.

    In use, you would wait for 2^16 MCLK edges, then read the other (gated) counter A reading rates ~152Hz
    HW capture of Enabled counter on the other Ctr overflow, would give values with no software overhead.


    Can the P2 do that ? ie External clock to 2 counters, and also CLKEN to one ?


    AD7400 says :
    A differential signal of 0 V results (ideally) in a stream of 1s and 0s at the MDAT output pin.
    This output is high 50% of the time and low 50% of the time.
    A differential input of 200 mV produces a stream of 1s and 0s that are high 81.25% of the time.
    A differential input of −200 mV produces a stream of 1s and 0s that are high 18.75% of the time.


    Addit: I see the MDAT changes after MCLK _/= and is stable when MCLK=L, so for Prop1 (and if P2 has no CLKEN), you could use a 1G57 universal Logic gate for
    GCLK = MDAT & !MCLK,
    and GCLK can feed any Prop Ctr.
  • DL7PNPDL7PNP Posts: 18
    edited 2013-09-10 17:21
    cgracey wrote: »
    That AD7400 is a 2nd-order delta-sigma modulator which requires a complicated digital filter after it to produce 16-bit samples.

    The Prop2 has simple 1st-order delta-sigma modulators which output 0's and 1's in proportion to the input signal level. for example, a Vsup/2 level would produce the stream: 010101010101.... which is 1/2. A GND level would produce 0000010000000100000001... which is 1/8. A Vsup level would produce 1111101111111011111110... which is 7/8. So, you only need to count 1's over some number of clocks to get a sample. If you count for 256 clocks, you'll get an 8-bit quality sample ranging from 0 to 256. If the input is between GND and Vsup (1/8 and 7/8), you'll get values from 32 to 224.

    Is it possible to let the counter count to 1024 or higher?
  • jmgjmg Posts: 15,155
    edited 2013-09-10 17:29
    DL7PNP wrote: »
    Is it possible to let the counter count to 1024 or higher?

    Sure.
    You can even run two time bases in SW - sample at say 2^16 (or less) for faster readout, using difference reading, and keep a slower total, perhaps over 0.5 second, for highest precision.
  • cgraceycgracey Posts: 14,133
    edited 2013-09-10 17:50
    jmg wrote: »
    I think the AD7400 could work, in counter mode, but does ideally need CLK and CLKEN signal connection to P2 counter.

    Actually 2 counters, as the MCLKOUT is somewhat variable, you would feed MCLKOUT to 2 Ctrs, and one would be always Enabled, the other is MDAT enabled. Now the counter ratio, is the voltage ratio.

    In use, you would wait for 2^16 MCLK edges, then read the other (gated) counter A reading rates ~152Hz
    HW capture of Enabled counter on the other Ctr overflow, would give values with no software overhead.


    Can the P2 do that ? ie External clock to 2 counters, and also CLKEN to one ?


    AD7400 says :
    A differential signal of 0 V results (ideally) in a stream of 1s and 0s at the MDAT output pin.
    This output is high 50% of the time and low 50% of the time.
    A differential input of 200 mV produces a stream of 1s and 0s that are high 81.25% of the time.
    A differential input of −200 mV produces a stream of 1s and 0s that are high 18.75% of the time.


    Addit: I see the MDAT changes after MCLK _/= and is stable when MCLK=L, so for Prop1 (and if P2 has no CLKEN), you could use a 1G57 universal Logic gate for
    GCLK = MDAT & !MCLK,
    and GCLK can feed any Prop Ctr.

    In reading the AD7400 datasheet, it mentions needing a special digital filter chip, which can be one of their products or an FPGA of your own. Those filters are huge and complicated, but tied to a 2nd-order delta-sigma converter you get high-bit-count results much faster than you can with a first-order setup.
  • localrogerlocalroger Posts: 3,451
    edited 2013-09-10 17:56
    Chip, do you have a seat of the pants blue-sky idea of what kind of absolute microvolt resolution we might be able to expect from the P2 ADC on relatively low sample rates such as 60 Hz or slower? I am interested in reading the output of a wheatstone bridge either directly or with a single-stage 3v3 instrumentation amp. My tests in that area with P1 weren't up to snuff and I'm not really an analog design guy.
  • cgraceycgracey Posts: 14,133
    edited 2013-09-10 17:58
    Here is a DAC with a 2nd-order modulator. Note that the analog section is big and the digital filter section (made of dense standard cells) is even bigger:

    DAC_layout.jpg


    I hired a 2nd-order delta-sigma ADC consultant for a day during the development of Prop2's ADC circuit, and it was quickly apparent to me that trying to implement such a thing on every pin would be impractical. So, we have simple first-order modulators.
    1024 x 853 - 293K
  • cgraceycgracey Posts: 14,133
    edited 2013-09-10 18:02
    localroger wrote: »
    Chip, do you have a seat of the pants blue-sky idea of what kind of absolute microvolt resolution we might be able to expect from the P2 ADC on relatively low sample rates such as 60 Hz or slower? I am interested in reading the output of a wheatstone bridge either directly or with a single-stage 3v3 instrumentation amp. My tests in that area with P1 weren't up to snuff and I'm not really an analog design guy.

    I really don't know, but I wouldn't be surprised if you could resolve microvolts, after noise is averaged away.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-09-10 18:22
    Chip,

    Do you have a description of what the loader needs to do to sign an image before loading it with the real P2 chip?

    Thanks,
    David
  • jmgjmg Posts: 15,155
    edited 2013-09-10 18:32
    cgracey wrote: »
    In reading the AD7400 datasheet, it mentions needing a special digital filter chip, which can be one of their products or an FPGA of your own. Those filters are huge and complicated, but tied to a 2nd-order delta-sigma converter you get high-bit-count results much faster than you can with a first-order setup.

    I think the Digital Filter is optional - as you say, you get more bits-per-second with a Filter design, but you can also use a basic counter, given they have a direct % modulation.

    With a filter, they say you can get 39KHz word (16b) rates, whilst a counter is 152Hz word rates.
    Filters do have a inter-word crosstalk, so do not multiplex well.

    Assuming someone did want to do such a filter in a COG, it would need
    CLK + DAT shifter, and the Counter version would need CLK, CLK+CLKEN.
    Can the P2 support both pathways ? ( CLK + DAT shifter or CLK, CLK+CLKEN Ctrs)
  • cgraceycgracey Posts: 14,133
    edited 2013-09-10 19:28
    David Betz wrote: »
    Chip,

    Do you have a description of what the loader needs to do to sign an image before loading it with the real P2 chip?

    Thanks,
    David

    You need to do an HMAC/SHA-256 on the loader's longs ranging from $000..$1F7 using the 128-bit security key, and place it in $1F8..$1FF.

    After downloading $200 longs, the booter computes its own HMAC/SHA-256 from the loader's longs in $000..$1F7 using the 128-bit security key. Then, it compares it to what you loaded for $1F8..$1FF. If the signatures match, the loader is run in cog0. If they didn't match and the security key is $00000000_00000000_00000000_00000000, the monitor runs. Else, the part waits for another reset.

    For the FPGA version of the Prop2, loader must contain $00000001's from $1F8..$1FF.

    I can get more info on the HMAC/SHA-256 procedure. I have it written in Delphi (Pascal), already.
  • pedwardpedward Posts: 1,642
    edited 2013-09-10 23:31
    Here's how to easily generate an SHA256-HMAC hash for signing your loader:

    openssl sha256 -mac HMAC -macopt hexkey:00000000000000000000000000000000 foo

    explanation:

    openssl (the program that contains all the good stuff)

    sha256 (the algorithm)

    -mac HMAC (tell it to generate a digest using the HMAC protocol)

    -macopt hexkey:00000000000000000000000000000000 (this is a hex value, all 128 bits of the secret key)

    foo (the file you want to calculate the hash for)
  • David BetzDavid Betz Posts: 14,511
    edited 2013-09-11 01:29
    pedward wrote: »
    Here's how to easily generate an SHA256-HMAC hash for signing your loader:

    openssl sha256 -mac HMAC -macopt hexkey:00000000000000000000000000000000 foo

    explanation:

    openssl (the program that contains all the good stuff)

    sha256 (the algorithm)

    -mac HMAC (tell it to generate a digest using the HMAC protocol)

    -macopt hexkey:00000000000000000000000000000000 (this is a hex value, all 128 bits of the secret key)

    foo (the file you want to calculate the hash for)
    Thanks! Is there a shortcut for chips that don't have a key programmed into them or do I have to use openssl with some default key? I guess this means that we need to distribute openssl with PropGCC or any program that will need to download to the P2. Has someone created executables for Windows, Linux, and Mac that we can add to our distributions? We'll have to provide RossH with this information as well so he can modify his Catalina loader.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-09-11 01:31
    cgracey wrote: »
    You need to do an HMAC/SHA-256 on the loader's longs ranging from $000..$1F7 using the 128-bit security key, and place it in $1F8..$1FF.

    After downloading $200 longs, the booter computes its own HMAC/SHA-256 from the loader's longs in $000..$1F7 using the 128-bit security key. Then, it compares it to what you loaded for $1F8..$1FF. If the signatures match, the loader is run in cog0. If they didn't match and the security key is $00000000_00000000_00000000_00000000, the monitor runs. Else, the part waits for another reset.

    For the FPGA version of the Prop2, loader must contain $00000001's from $1F8..$1FF.

    I can get more info on the HMAC/SHA-256 procedure. I have it written in Delphi (Pascal), already.
    Ah, if you have a Pascal implementation then I can probably convert that to C pretty easily so I can link it directly with propeller-load to avoid having to shell out to openssl.

    Thanks!
    David
  • Heater.Heater. Posts: 21,230
    edited 2013-09-11 01:35
    Presumably you would not use the opensll program but rather libssl which I guess enables you to do all of that stuff from within the loader program. libssl just becomes another dependency when building the loader.

    Hmm...does this signing business belong in the loader or a separate signing program? Or both or what?
  • David BetzDavid Betz Posts: 14,511
    edited 2013-09-11 03:51
    Heater. wrote: »
    Presumably you would not use the opensll program but rather libssl which I guess enables you to do all of that stuff from within the loader program. libssl just becomes another dependency when building the loader.

    Hmm...does this signing business belong in the loader or a separate signing program? Or both or what?
    I think the loader at least needs to be able to sign with the default key. We could use a separate program to sign with a real key.

    Edit: Also, good point about using libssl. If that is available for all three platforms it would certainly be the way to go for propeller-load and probably Catalina's payload program as well.
  • evanhevanh Posts: 15,319
    edited 2013-09-11 04:39
    Thankyou Chip and JMG. Some good ideas there. I'll buy an AD7401 instead - It takes a clock as an input. I'll be able to dictate the timings better that way. And what's more I think I'll have a play using a Prop1 Cog to bit bash it instead trying to fiddle the counters.


    Cheers,
    Evan
  • pedwardpedward Posts: 1,642
    edited 2013-09-11 08:57
    OpenSSL is a crypto library and frontend program available for all platforms.

    You can find out about OpenSSL here: http://www.openssl.org/

    Windows packages are here: http://gnuwin32.sourceforge.net/packages/openssl.htm

    OSX comes with an older version of OpenSSL, there are some instructions about updating that here: http://homes.cs.washington.edu/~aczeskis/openssl.html

    Most Linux distributions install OpenSSL by default, if not you generally only need to add the 'openssl', 'openssl-libs', and 'openssl-devel' packages for the full monty.

    When originally conceiving how the code signing and encryption might work from an end user perspective (developer), I imagined using a wizard program written in C with Qt to implement this.

    I might actually consider writing it in Python for ease of development and make it simpler for people to modify. In any outcome, the idea would be to have a signing program that could help manage keys and do all the heavy lifting, then the loader simply needs to write to flash. Since the loader doesn't need any crypto, because the chip does everything on bootup, it can be simple and focused at the specifics.

    The important part is to have a program that can generate a binary image to give to the loader, perhaps I'll put together a script that uses openssl today, so at least there's a simple and direct way of testing.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-09-11 09:00
    I'm not sure that a separate program will work well in a development environment. There is a "run" button in SimpleIDE that downloads a program to the chip and starts it running. We wouldn't want to have to write the generated program to a file and then run a Qt app to sign it on every download. I think it's important for the loader to be able to at least sign images with a default key during development. Signing with a real key for generating production images could be handled by this Qt app. Does that make sense?
  • cgraceycgracey Posts: 14,133
    edited 2013-09-11 10:53
    On a new Prop2 chip, the security bits are all cleared, so the initial 128-bit key needed for generating the signature is $00000000_00000000_00000000_00000000. On the FPGA, I changed the ROM so that it just looks for eight $00000001's in $1F8..$1FF, so that nobody had to deal with creating HMAC signatures. Once you have to HMAC/SHA-256 code written, it's just one call to sign your loader.

    Pedward figured all this out a year ago and wrote an initial Prop1 PASM implementation which I used as stock for making the Prop2 implementation. Many thanks for Pedward for getting all this stuff figured out. It was the right solution to a complicated problem which had hung around for a long time.
  • David BetzDavid Betz Posts: 14,511
    edited 2013-09-11 11:48
    cgracey wrote: »
    On a new Prop2 chip, the security bits are all cleared, so the initial 128-bit key needed for generating the signature is $00000000_00000000_00000000_00000000. On the FPGA, I changed the ROM so that it just looks for eight $00000001's in $1F8..$1FF, so that nobody had to deal with creating HMAC signatures. Once you have to HMAC/SHA-256 code written, it's just one call to sign your loader.

    Pedward figured all this out a year ago and wrote an initial Prop1 PASM implementation which I used as stock for making the Prop2 implementation. Many thanks for Pedward for getting all this stuff figured out. It was the right solution to a complicated problem which had hung around for a long time.
    Sounds like signing with the zero key should be easy if we link in libssl so that's what I'll plan to do in propeller-load. I'll leave signing with real keys to the Qt app.
  • Ken GraceyKen Gracey Posts: 7,387
    edited 2013-09-11 12:46
    Everybody here appreciates an inside look at what's going on in Parallax, so maybe you'd be interested in this message in my e-mail this morning. - Ken

    Screen Shot 2013-09-11 at 12.51.32 PM.png
  • mindrobotsmindrobots Posts: 6,506
    edited 2013-09-11 12:52
    WooHoo!!

    40 P8X32C's are headed to Rocklin!!!!

    Get NORAD to track Santa because he's somewhere over the Pacific today!! :lol:
  • potatoheadpotatohead Posts: 10,259
    edited 2013-09-11 12:54
    Ken, you are awesome. Fingers crossed!
  • Heater.Heater. Posts: 21,230
    edited 2013-09-11 13:01
    Eeee...I'm going to pee myself. The tension is too much.
  • jmgjmg Posts: 15,155
    edited 2013-09-11 13:02
    evanh wrote: »
    Thankyou Chip and JMG. Some good ideas there. I'll buy an AD7401 instead - It takes a clock as an input. I'll be able to dictate the timings better that way. And what's more I think I'll have a play using a Prop1 Cog to bit bash it instead trying to fiddle the counters.

    That variant would work better on a Prop1, but could be used with Counters with care.

    The fish-hook is the delay from clk to data change, is spec'd at more than one nominal Prop clk, and you do not want to ever be right on that change.

    However, the data is still stable during CLK=L, and the Prop 1 counter has Logic modes, so you can

    a) Generate 10MHz MCLK out, using a Binary NCO

    b) Use a LOGIC A & !B counter mode, !B is the MCLK pin, A is MDAT

    (I'm assuming a CLK out from a Prop, is always GATE legal in IP delay terms)

    That counter will increment when MDAT is high, 4 clocks at a time. (with 4 clk pauses)
    Run for some fixed time (eg SysCLK/2^19), and read the LOGIC mode counter and >> 2 for direct Logic value.
  • jmgjmg Posts: 15,155
    edited 2013-09-11 13:05
    Ken Gracey wrote: »
    Everybody here appreciates an inside look at what's going on in Parallax, so maybe you'd be interested in this message in my e-mail this morning. - Ken

    Hehe, no tracking number ?
    Could have raised all sorts of flags, at FedEX by crashing their tracking system !!

    ( It could already have landed, as I see the Date is two days ago, on Taiwan's side of the date line.)
  • mindrobotsmindrobots Posts: 6,506
    edited 2013-09-11 13:13
    Just checking.....

    We're not in the middle of the Walnut Harvest Festival or a Tortilla maker fair someplace, are we? There shouldn't be any distractions! :smile:
  • ColeyColey Posts: 1,108
    edited 2013-09-11 13:13
    Ken Gracey wrote: »
    Everybody here appreciates an inside look at what's going on in Parallax, so maybe you'd be interested in this message in my e-mail this morning. - Ken

    Screen Shot 2013-09-11 at 12.51.32 PM.png

    Fingers and toes crossed! Good luck Parallax, you guys deserve every success and thanks for sharing :smile:
  • K2K2 Posts: 691
    edited 2013-09-11 13:18
    Ken Gracey wrote: »
    Everybody here appreciates an inside look at what's going on in Parallax, so maybe you'd be interested in this message in my e-mail this morning. - Ken

    Many thanks for sharing such developments with us!

    Yup, thar be magic reindeer heddin' this way.
Sign In or Register to comment.