On Mon, 12/28/15, Anthony Sorace wrote:
> And yes, I’d be interested in seeing your
> slides, although you’ve already given me
> enough to keep my busy for a bit.
Anthony,
I've put the slides up in the directory at:
http://cs.drexel.edu/~bls96/plan9/
The class met one night a week and we have
> Excellent. I had suspected that statement was too restrictive, but hadn't
> seen the errata or gotten around to checking on a scope. I'll update that
> today.
New versions posted. spiclock() now rounds the divisor up to the smallest
even number that results is a clock rate less than or equal
1. This could work, although if you add “if things break, try again with
different algo”, you get 5.
2. While a good cipher, seems like something that might get us stuck in the
future.
3. This seems a bit complicated, and is in essence 5 performed over a fixed
cipher.
4. makes sense. I don’t
> but http://raspberrypi.org/documentation/hardware/raspberrypi/spi/README.md
> has an erratum suggesting "power of 2" should be "multiple of 2". I have
> been using a default divisor of 250 for a 1MHz clock, and that's the frequency
> I see on my oscilloscope.
Excellent. I had suspected that st
On 29 December 2015 at 18:34, Charles Forsyth
wrote:
> extension of the protocol to the occasional new protocol.
Sorry, that second "protocol" was supposed to be algorithm or technique.
On 25 December 2015 at 03:03, wrote:
>
> the functionality that is desired is to be able to "negotiate" the
> cipher suits and record layer protocol versions.
I could never work up much enthusiasm for TLS because it is needlessly big
and complex, but still got important things wrong.
I never sa
Thanks, Brian - that all looks very useful to make the pi more amenable
to hardware tinkering.
One small suggested amendment: your spiclock() says this -
/*
* According the Broadcom docs, the divisor has to
* be a power of 2. This code rounds up so that the
* resulting clock is the highest va
