Others are suggesting power supplies, but I think you can just use a voltage divider from a 5V supply. Like maybe a 2.7K resistor followed by a 5.6K to ground?

It needs to be regulated, because the microcontroller draws varying amounts of current. But a simple regulator is just a three-legged IC and a capacitor.

Ah okay, I didn't realize that.

Just some technical info in this if anyone trips over this thread, consider the following diagram of a voltage divider:

http://pcbheaven.com/wikipages/images/voltagedivider_1235725...

The Rload and R2 are parallel resistors really so if Rload is really low which it is generally if it's doing anything then it will effectively shrink the R2 resistance (Rload || R2) and therefore voltage. Then whatever is connected as Rload won't get enough volts + current.

You can fix this to some degree by using very low values of R1 and R2 but then they start to sink lots of current as they are in series across the power supply and get hot so this becomes an efficiency problem. If you're really unlucky the magic smoke comes out or you touch one and burn your fingers emitting a nice bacon smell.

You can fix all of this with a single NPN transistor and a zener diode pretty easily but you might as well use a regulator IC then.

Analogue electronics is fun even if it does burn and explode in your face occasionally! My shit blows up all the time: http://i.imgur.com/GZBKblt.jpg

You really don't want to do that imo.

This is really cool. One cautionary thing though. I think that because of breadboard capacitance if you try any sort of high frequency stuff on the breadboard (like >= 10MHz) you'll get all sorts of weird effects. (This is just a breadboard problem that occurs at high frequencies, not an ARM problem).

I'm just an amateur in this area, so if someone who is more knowledgeable could confirm or deny with I wrote above that would be great.

1. Others estimate higher max frequency. This one's on the high side of estimates:

http://dangerousprototypes.com/2011/12/05/breadboard-limitat... [might have to ask EE friends about transmission line termination at those frequencies]

2. See also this video (and comments on video) where they measure:

https://www.youtube.com/watch?v=6GIscUsnlM0

That shouldn't encumber most people though. How many people who don't already know that have the skills to seriously compete with ARM? Probably none.

Historically, it hasn't really taken "serious competition" to invite threats. There's a reason that the best-known open-source ARM implementation explicitly only targets ARMv2 (which dates from the days when the "A" stood for "Acorn") [1].

That said, people who just want to play with ARM-based hardware can get pretty far by leaning on the GNU support and third-party documentation (there are some Game Boy Advance documents that cover the ARMv4 instruction set, for example).

[1]: http://opencores.org/project,amber

Well you can just read the reviews to see that the Durrett text isn't well regarded while others like Chung's are. And the criticism about a probability space not being a sample space is correct, but I think it's clear what Tao meant there, namely that the sample space would be a part of a probability space.

Thanks

The Amazon UK reviews of Chung's book lead me to A Probability Path by Sidney Resnick which appears to be aimed at non-mathematicians. I have invested (speaking as a renegade physicist lacking a systematic exploration of measure theory).

The sample space is not the probability space. The probability space has a sample space though, which is what the Wikipedia definition says, but not what Tao literally said. I think it is pretty clear what Tao meant though.

Is rust as complicated as it seems to me? I know ML derived languages well so I'm not a stranger to functional programming. And I'm a pretty competent C programmer, but it seems like Rust is about as complicated as C++, which I find offputting.

No, it's definitely nowhere near C++-complicated: there's usually one way to do things, no legacy cruft. There's no multiple inheritance nor large type hierarchies. Things tend to "just work" (once you get the code to compile) instead of silently biting you (I haven't found any gotchas or footguns within the safe Rust yet).

It does seem strange, because:

- It has constructs which aren't present in C/C++ in the exact form, like traits or pattern matching (maybe it'd be easier if they were called templates and switch, but they're not quite the same thing, so a different name is good). There's a lot of Rust-specific jargon for things that aren't as complicated as they seem.

- Some constructs (e.g. enums and empty structs) look like C's, but again aren't quite the same.

- It has powerful generics and macros, so people who want to write really clever code, can.

> - It has powerful generics and macros, so people who want to write really clever code, can.

To take a cue from the article: how do you write a generic max() function for an arbitrary number of arguments?

Someone had commented this in a response on the site.

   macro_rules! max {
        ($e: expr) => { $e };
        ($e: expr, $($rest: tt)*) => { max($e, max!($($rest)*)) }
   }

It depends on how you define "complicated." For example, Rust and C++ both have "move semantics," but Rust's is "A move is a memcpy, which the optimizer may or may not elide" and C++'s is http://stackoverflow.com/a/3109981/24817 rvalue references and copy/move constructors and all sorts of other things.

There are three major kinds of backgrounds that Rust programmers come from: functional, systems, scripting.

The functional crowd instantly groks Rust's pattern matching, first-class functions, and expression-based-ness. But they miss some more complex, stronger type system features.

The systems crowd instantly groks Rust's low-level features, but struggles sometimes with the compiler being so strict.

The scripting crowd instantly groks our tooling, and the functional-ish things, but struggles with the low-level.

So really, everyone has a different definition of what "complex" is, because it's based on what you're familiar with. Some people find map to be more complex than for, some people think the exact opposite.

All generalizations are false.

> All generalizations are false.

I believe this sentence is a paradox.

It's not a paradox. It's just false. Compare "all sentences are lies".

It's close enough to true to be useful, but it's false when you treat the word "all" literally.

Heh, the three kinds of backgrounds sounds like the perfect description of what I've found in the Rust community (being of the functional variety myself). However, once I understood ownership and lifetimes, I felt like the whole world opened up. I'm still waiting for more ecosystem and community before I start to use it more seriously, but I'm chomping at the bit for that to happen.

The borrow stuff is what seems to confuse or seem complicated. But if you take this guiding rule: Memory safety, no GC -- a lot of the rules just make sense and in many cases they simply couldn't be another way. And after dealing with complicated multithreaded code in C, I prefer the borrow checker. Let me know up-front where I messed up. In nearly every case where someone is saying the borrow checker is making life hard, it's often because in C, they'd have had a bug. The exceptions mainly seem to be limitations in Rust's checker.

Like any type system, there are programs that are valid that cannot be expressed. This can frustrate people when they can see that their program is OK under the current configuration of it, but there's no easy way to represent that as a guarantee. (Same annoyance dynamic-languages users might feel about static typing.)

FWIW, I prefer ML-ish derived languages, am a mediocre C programmer, and Rust seemed easy enough to learn to the point I enjoyed using it.

It's both less and more complicated than it seems. The borrowing system is quite complicated and it will take time before you can internalize it so that you can trust your code to compile on the first try. However, Rust is the good kind of complex in that when it surprises you, it tends to do so with a compiler error. It's very unlike C++ in that even when you're not a 100% sure of what's going on, the code tends to be quite robust.

Note that for any large C++ codebase, you still have to reason about things like borrows (or equivalent/similar concepts), just that the language doesn't explicitly talk about them. Rust just makes it all explicit from the get-go.

And actually, borrowing isn't really complicated, just _different_.

C++ is the only language I've used, where a collection of completely reasonable decisions led to the situation that "if (a == b)" worked fine, but "if (b == a)" crashed the program due to a failed assertion.

And we weren't even using any templates!

I fail to see how reasonable decisions lead to the situation where a == b works "fine" while b == a effectively crashes the program. Could you elaborate what the reasonable decisions were?

Yeah, this sounds more like a and b are different types but somebody messed up overriding equality operators. I wouldn't blame the language for that.

That's possible in any language that doesn't force you to include a computer-checkable proof that your overridden equality operator forms an equivalence relationship.

I imagine depending on the assumptions, the same could happen in Rust, given Rust allows overriding equality too.

Most of the time in rust, you can just `#[derive(Eq)]` and be done with it, so those kinds of things are far less likely.

> I know ML derived languages well so I'm not a stranger to functional programming. And I'm a pretty competent C programmer, but it seems like Rust is about as complicated as C++, which I find offputting.

Have you used languages with memory safety and no garbage collection before?

I think Rust has no more features than it needs to support its goals, and would be interested to know what features you would like removed.

What gives you the impression that it's complicated? I can assure you that Rust contains an order of magnitude fewer features than C++, and none of C++'s edge cases or C's footguns.

Rust has a very powerful type system, and combining that with lifetimes makes for some crazy signatures that really hurt my brain.

The type system grows more powerful (and more complex) every time I revisit Rust, it seems.

I'm glad, as an increasingly powerful type system facilitates abstractions that were once painful, slow, unsafe, or impossible, but it is complex.

> Rust has a very powerful type system, and combining that with lifetimes

If you don't count lifetimes, Rust's type system isn't really more powerful or complex than, say, that of Swift. There are no dependent types here. There are no type families. There aren't even higher-kinded type parameters.

> The type system grows more powerful (and more complex) every time I revisit Rust, it seems.

What additions are you referring to?

I wouldn't say Swift's type system is particularly simple, I rather like it, but it does have a lot of complexities.

  > The type system grows more powerful (and more complex) 
  > every time I revisit Rust, it seems.

There have been no additions to the type system since well before 1.0. I'm curious where this perception is arising from.

Google the title to get around the paywall if you don't have an FT subscription.

How easy is it to deal with raw memory in rust? That's the main reason for using C in my opinion.

I don't know what you mean by "deal with raw memory" but rust allows you to do silly things like:

    let foo = unsafe { std::slice::from_raw_parts_mut(0xdeadbeef as *mut u8, 42) };

That gets you a slice (pointer+length that can be used as an array) that points to 0xdeadbeef. Bit more verbose than the c equivalent

    char* foo = 0xdeadbeef;

but arguably this is pretty rare usecase even for handling raw memory

You have to use `unsafe`, but you can do anything you can do in C. Raw pointers are the primary mechanism, same as C pointers http://doc.rust-lang.org/stable/book/raw-pointers.html

Not sure is it like this anymore, but might be worth giving a read:

> But allocating memory seemed like a fun exercise. To allocate something on the heap in Rust, you can do

> let a = ~2

> This creates a pointer to a 2 on the heap.

http://jvns.ca/blog/2014/03/12/the-rust-os-story/

That syntax has been changed, actually. Now, to allocated an owned pointer allocated on the heap, you use the Box type:

> let a = Box::new(2);

I believe it's an unstable feature currently to use the "box" keyword to heap-allocate a value, which can also be used in pattern matching. I saw somewhere that "box" will be made into an overloadable operator, such that you can easily create reference-counted and atomically reference-counted types.

Yes, that's generally correct. We still haven't fully decided on the exact syntax. If anyone wants to get involved, this RFC was the one that got merged, but hasn't been made stable yet: https://github.com/rust-lang/rfcs/blob/master/text/0809-box-...

And this is the active, in-final-comment-period one which modifies it: https://github.com/rust-lang/rfcs/pull/1228

Sounds a lot like a Commodore 64 or TempleOS, but in those this was/is considered an advantage.

I think your conclusion is right for most people, but you're a bit too cynical. The system isn't rigged purposefully. It is just that the people who decide who gets the elite jobs all act a certain way and had similar backgrounds. Naturally they like people like themselves and so the jobs go to those people. Even then, there are lots of qualified people from those backgrounds who don't get those jobs. Everyone is competing for a purely positional advantage (i.e. in order to move up, someone else must move down) and the 1% is already large enough to replenish its own ranks.

Yes. The idea the wealthy got together and formed a big conspiracy to shut everyone else out is a bit on the paranoid side. It's not that you can't get a prestigious job without the right kind of background, it's that you don't have an advantage other people have. And, as you say, there aren't enough top jobs to go around.

But we don't have to look at top jobs to see this dynamic at play. Good looking people of both sexes get better jobs than the rest of us, as do people with more energy.

Easy for you to say especially when you are not affected by the system.

Everyone who wasn't born into the small elite is affected by the system, including me. It's not a competition to see who suffers the most.

Edit: also, the elite themselves are punished by the way things work. The number of truly elite jobs is small and the competition is very strong. For every kid whose parents bought his/her way through the system there were a number of others whose parents tried, but failed, to do the same thing.