Loving Bitlash, in that it provides a means of transitioning from interpreted shell to hosted code. Always a little worried about being caught in a cul-de-sac though, even if it's a garden of eden That's one of the reasons for raising this query to begin with.

dxw00d understand what you're saying on Firmata support. If in practice the community is turning away from it we have to take this into account. We're not using Megas (or Arduinos for that matter), so I'm not too worried on that front. However, I don't believe it's easy to substitute and write your own protocols, at least for the average person.

The I.T.A. parallel from Mike was pivotal to me understanding where I'm coming from. It clarified in my mind what exactly I feel needs to be taught. I think you're right if the aim is to get them to use C, then it's a bit mad to teach them Python. However, the aim is to teach them to be programmers, not C programmers (and importantly NOT computer scientists, this is like the difference between a carpenter and a dendrologist).

I'm hoping to teach the fundamental skills which transcend any language and are a matter of the programmers craft, insights like the concept of a variable, the habits and shortcuts of how and when you structure data into sequences (containers for items without names = list/array) or dictionaries (containers for items with names = struct/object) depending on what you're trying to achieve, sensible approaches for choosing names, how to break complex behaviours down into smaller parts. I believe these aspects are easier to learn in an interpreted, untyped shell language, and especially one which can be used for so many jobs, but in any case, these skills can transfer. In the ideal world, session participants will have developed some of the skills of a pragmatic programmer, concepts which can be used across javascript, java, ruby, php and so on.

If the fishing trip is successful, they bite the worm, and become developers probably C is one of the least useful languages for them when branching out into web programming, audio, graphics. If they were stuck with python, it could be worse - it can be used for almost anything and this is where the parallel with I.T.A. breaks down, which really was a cul-de-sac, and could never be used for real-world tasks.

I have to differ with dxw00d that you can explore individual concepts in C. I thought it was a matter of fact that causing anything to happen through  Arduino C demands a complete program compiled to hex, which means you're exposed to void, function defs, function calls, (implicitly) library calls and many other things before you can achieve anything at all. I'm talking from a semi-religious point of view here, as I've been convinced by Constructivism... http://en.wikipedia.org/wiki/Constructivism_(learning_theory) and indeed Constructionism... http://en.wikipedia.org/wiki/Constructionism_(learning_theory) , which takes things a little further, and more literally. Both of these emphasise being able to act on your world to figure stuff out or else most people just won't figure it out. If you can go pin.write(1) and see the light come on, this meets the challenge. If you have to write the whole of Blink without errors and upload and run it to confirm your comprehension of 10 concepts at once, this is a real problem.

It's no surprise that Papert (the original Constructionist guy) was behind the family of programming tools leading to Scratch. This could go some way to explain your experience of educationalists too, Mike. This atomic, active manipulation is the sort of experience they feel individuals need to have in order to make sense of programming. The geeks amongst us can cope even in the face of complexity. I fear many people other people are left by the wayside because our typical teaching approaches mean they cannot build up incrementally. I'm probably reaching more for the non-geeks here, but as a geek myself I'm badly qualified

Has anyone in the thread had success teaching non-programmers with either C or python or anything else? Be good to hear your anecdotes of how key concepts 'dawned on' people. I'm especially wondering if anyone's had success converting people who are not classically interested in computers/logic into using programming for its practical benefits? That's the particular line I'm trying to go down. Happy to teach natural geeks too, but I'm wondering if I can achieve some evangelical programming; on a mission

@dxw00d I appreciate you taking the time to engage in this debate.  Sorry for delay replying, I wanted to respond to each of your points in turn and was under pressure of deadlines at the time - a university submission is partly why the use-of-Firmata rationale was written up as the draft PDF which I linked to.

It's clear you don't agree that Firmata should be used, but I'm not sure I share your assumptions, and your reasons for your strong opinion aren't that clear to me.

I suppose it's a start, but as soon as you want to make something that can stand on its own, you have to learn to program the Arduino, so why not start with that?

This comes to the heart of the debate. Indeed this is specifically for novice programmers, and we detail how we transition from Python to C in the document. The reasons "why not start with that" were outlined in the PDF. I don't know if you found it tl;dr but it's probably better to say it here in the thread.

The main issue is that Arduino programs are monolithic. If you're a programmer it may not be obvious to you that there's a lot of concepts in the Blink sketch. With an interactive shell, using pyfirmata you can tackle language structures one by one, introduce the notion of values, types, expressions, named values (variables), named sequences of values (arrays), steps (statements), named groups of steps (functions) and so on, individually. Each can be introduced and explored step by step until the learner is comfortable with the concept in practice. They can see immediate results from individual steps because the servo moves, the array changes or the LED lights. There's a lot of commonality with work on Senseboard, and the section in  http://oro.open.ac.uk/30294/1/cse202-Richards.pdf called "Reducing the obstacle of programming" makes the argument well, although they settled on a 'Scratch' blocks programming language instead. 

It doesn't appear to be supported.

I'm confused by this. On the one hand, multiple Firmata sketches are distributed directly with the Arduino IDE under the Example menu, including updated sketches which handle the library compatibility changes since version 1.0 so I don't know what other model of 'support' you have in mind. As an open source project, it's as supported as the people who care about it enough to maintain it, update it and help users with its adoption. If any community is going to step up and do this support, it's the one represented in this forum. In any case if Firmata ain't broke, maybe it doesn't need fixing at all. Perhaps you think it's broke in some way.

It removes the point of having a microcontroller, with onboard intelligence...[unless] all of your projects are tethered, and driven by intelligence on the PC

Microcontrollers are specifically designed to open up the possibility of interfacing with the external world, (as opposed to mere microprocessors which provide the intelligence). An Arduino is something which can be extraordinarily useful when tethered as a slave of a laptop whose microprocessor does not have any general I/O pins. Most projects which I've been involved with are structured in exactly this way, combining PC programs with a bespoke physical-computing peripheral, implemented as an Arduino. One reason for pursuing this direction is that our project was initially all about "shrimping laptops". Of course there are deployment scenarios where tethering doesn't serve the application, but I don't think it's even possible to add GPIO to a PC without using a microcontroller, and Arduino is my board of choice. I was surprised by the implication that standalone use of Arduino is somehow the one true way.


If students are comfortable with all the relevant programming concepts, I believe moving to C is a relatively trivial issue, and for someone who is actively engaged in using Arduino the effort is then justified, just as you say, by the fact you can get your behaviour to run standalone. Starting with C, in my view, is a terrible way to introduce programming concepts for the reasons outlined in the PDF, and will tend to turn people off programming altogether, unless they are of a certain mindset. This project is about reaching out to the other 99%

@bromatt I recently experienced a blown/broken crystal, which didn't behave as you describe - the circuit simply didn't function. However, I don't know if there's any weird behaviour before one fails completely.

Without seeing the circuit in action, it sounds like it might be resetting for some reason, such as a temporary load which affects the voltage. If I'm right, the variation in blinking is therefore to do with it restarting the whole program again. I've seen this happen in unprotected circuits controlling motors, and it may reveal latent issues with having some contacts which are not conducting well for some reason (perhaps corrosion in the breadboard connections).

Protection from variations in load is one primary reason, as well as stable analog reference voltages, for the differences between the minimal programmable circuit at...
http://shrimping.it/blog/shrimp/shrimpduino_bb_minimal/
...and the more practical, protected circuit at...
http://shrimping.it/blog/shrimp/shrimpduino_bb/
...which is recommended for any substantial physical computing work.

Try the more protected circuit instead, and be sure everything is cleanly contacting.

I have a kind of manifesto document for a specific workshopping technique at http://shrimping.it/blog/wp-content/uploads/demo_sequence.pdf

It outlines why I think it's better to teach novice Arduino programmers using python and firmata rather than for example, the Blink sketch within the Arduino IDE.

I'd love to hear people's thoughts on this, especially if there are better ways, or if people can see big holes in the approach, or just if you disagree strongly (with reasons).

@bromatt we should probably continue discussion of your layout/wiring/config issue on the other thread http://arduino.cc/forum/index.php/topic,121571.0.html but if you're still stuck after all the helpful advice, after I've finished my deadlines from 11th September, I can post you a full tested set of parts, then you can post your duff layout back on the breadboard for me to figure out what's wrong.

That way I gain a breadboard, (really useful for workshopping here in Morecambe), and maybe a 328P-PU (I'm working with the cheaper 328-PUs)!  At worst, I'll have swapped a good CP2102 for a fried one, but that's fine by me. If you're heading for Preston Raspberry Jam or OSHCamp we could cross paths there, or you could join us at a future http://shrimping.it workshop in Morecambe.

Let me know if that's interesting to you.

Does anyone have a view on the stability implications of placing the large electrolytic cap on the opposite side of the circuit. I'm guessing it's only going to respond over a relatively long timescale anyway compared to the smaller caps (which are there for rapid response).

Having it on the other side would be really useful given the left hand side is really packed when using just the 5 rails of a breadboard/stripboard...


However, it's not worth doing if it defeats the object of the cap altogether.

@bromatt when you say "it doesn't work for me" what exactly are you experiencing.

If you can't reprogram it even manually with a (well-timed) reset button push then I'd stop investigating the DTR pin and look at the rest of the circuit, especially the TX vs RX as Lakes points out.

That one (inverted serial pins) foxed me with an entire workshop full of people when I'd done the diagram they were all working to the wrong way round [facepalm].

If anyone wants to send me a (really clear) picture of their busted breadboard layout I can try to figure out what's wrong. Equally if there's anything else I can help with by way of parts or what have you, then get in touch especially if you're in the North of England. There's bound to be some way I can swap some bits with you for sanity checking whether things are roasted.

Contact me via this forum or http://shrimping.it If you're happy for me to share your pictures it would be good to have a resource of examples which need various fixes.

I'm relying on Bill Westfield's totally amazing Optiloader for flashing chips from Mouser. It does have a weird behaviour after I've flashed them. If I try to reflash them it seems to report they're busted, but they're actually fully functional. I think it's just a counterintuitive error message. I should file that on the Optiloader github when I get a chance.

I did have a DOA CP2102 but only one out of the 50 or so which I've bought, and I don't know what people did with it when workshopping, so they could have really zapped it somehow. Put it this way, I'm not going to try and get my money back

Just like Lakes says, you need to use the pin labelled DTR on the CP2102 to wire to the reset pin (pin 1 on the ATMEGA328P). All the CP2102s I've been passing on to people are exactly the same as Lakes, and have a right-angled male pin header manually soldered in place there. This really has to be detailed better on our website, sorry.

There's a picture of a minimal Shrimp on a breadboard which uses a modded CP2102 and matches Lakes' schematic exactly (apart from the LED) in the Shrimping Safari article at http://blog.safaribooksonline.com/2012/07/03/time-traveling-with-old-laptops-and-arduino-compatibles/ It looks like this...

   

However, there's a bunch of commentary in this forum thread which suggests some additional protective components which should be added for stability if you're trying to make a general purpose Arduino-compatible on a breadboard. The argument is that the components are so cheap that they're not worth trying to eliminate them, which we'd have to agree with, given our bill of materials at http://shrimping.it/blog/bill-of-materials/

We've tried to incorporate all of these insights in the latest layout which looks like this...


Alternatively, if you haven't access to a soldering iron, get the timing really good on hitting the reset button (which you need to wire with a pull-up resistor as per the http://shrimping.it schematic). Hit the reset button just after Compiling and just before Uploading. You have about a microsecond Seriously, though, it's not that tight. I can generally get it every time.

Latest developments now mean we can make the components for an Arduino-compatible circuit available to Morecambe hackers for around £1.40 in component costs, or £3.05 including the CP2102 USB to UART adapter.

This is a fairly major development, putting a binary-compatible #Shrimp about one tenth of the cost of a retail Arduino!

I'll change the thread title to reflect this. To find out more, visit http://shrimping.it/blog/bill-of-materials/

An update on the Laptop Shrimping project. We now have a URL at http://shrimping.it and Twitter @ShrimpingIt

The #Shrimp design is fairly stable now thanks to many contributions from people who know stuff.

I've personally distributed about 30 kits of parts. Some are taken with a breadboard, some with USB-UART adaptor, and some taken by hobbyists to put onto stripboard at home. However, the most exciting direction is feeding in to the National Curriculum and STEM subjects here in the UK.

Thanks to @teknoteacher for making me realise something like the #Shrimp was needed at Hackademy "Inside the Machine" http://teachcomputing.wordpress.com/2011/10/26/hackademy-live-blog/ Thanks to @oomlout for early discussions and support and thanks to @tshannon for hosting and supporting Shrimp makers at Howduino. Thanks to @jonachamberlain @patlink72 @iMartyn and his Mum for testing out the first boards and working with me to think of decent expansion kits. Thanks to Mike Cook for all his experimentation with a clone of the MB Games 'Simon'.  Thanks to @monsonite and @simonmonk2 for suggestions. Thanks to many many others  including those in this thread. Sorry if you've helped I didn't credit you by name but I've had a huge amount of fun and engagement with loads of people.

There's a lot of excitement about being able to actually solder together your own Arduino-compatible. Thanks to Fignition, and @ManchesterBudo for helping me realise how important this is to people - it's now become central to the project.

Essentially, this is developing into a classroom pack which teachers should be able to progressively introduce to pupils, with a single lesson to build the circuit and program it on breadboard, another lesson to prototype established project designs from 'expander' kits (which include some extra sensors and actuators for a specific project), and a final lesson to solder onto stripboard and test on battery. At any point, it is feasible for individuals to take a direction towards their own personal project/invention/game/alarm/joke/toy what have you. We're just offering a kind of template for leading people through this.

All along the way, you're working directly with incredibly cheap components and using the same 'mental model' from the moment you start building your Arduino-compatible, right the way through to prototyping your own project circuitry - one advantage of not using the blue board, at least for education purposes. There's a huge crossover with Design and Technology subjects, and it's loads of fun designing, choosing and packaging glossy buttons, displays etc. even for those who don't want to change the circuit or the program.

Here in Morecambe the rough plan is to make the components for a Shrimp available for £3 at workshops, with a returnable deposit of £2 for the USB-UART adaptor (which you may not need when you've finished building your project), and a returnable deposit of £3 for the breadboard (which you can give up when you've finished prototyping and you've transferred to stripboard, or maybe you found a cheaper breadboard

Hopefully people will get involved enough that they want to keep both the CP2102 and the Breadboard for further projects, and we can keep giving them packs of £3 components for each new experiment they undertake, with the aim that they actually deploy their experiments, powered by battery or a USB power source (without UART), and don't deconstruct them again as people like me tend to do with Arduino because of owning a limited number of boards.

Anyway, it's been a bit whirlwind. The moment I get any parts, people seem to take them away, so I've bought another load of 100 lots from mouser/tayda/shcfstore (the cheapest places I've found to get the bits so far). The CP2102s could take a while to arrive, unfortunately, but I'll have all the other parts within a week.

We can help you get the parts at a reasonable rate, and with rapid shipping from UK but we are not claiming any ownership of the design, though it's nice to get credit and pingbacks.

If you're interested in following along, getting a kit of parts or contributing to the project, then get in touch @ShrimpingIt http://shrimping.it

I'd like to be able to use the Pinout image at...
http://www.arduino.cc/en/Hacking/PinMapping
...as part of material which I'll distribute at a workshop and may share online.

The same is true of e.g. the http://arduino.cc/en/Tutorial/blink images including the Fritzing breadboard view, and schematics. When I'm introducing and commenting on these individual experiments within workshops, I'd like to have freedom to use the images, rather than having to remake them from scratch for each experiment I include.

Is there a general principle regarding licensing of images, for example those in the Wiki? Everything says copyright Arduino at the bottom of the page. Who do I need to seek permission from?

Cefn
http://cefn.com

LiPo are more like 4.2V when fully charged and 3.7V when discharged.
If you running at 16MHz, then full performance is guaranteed down to ~3.8V.
If you run at 8 MHz, it's less. So you coul run from a LiPo directly and not use a regulator at all.
I have an RF remote control that does just that - 8 MHz, 1000mAH LiPo, MAX1811 to control recharging the battery from a 5V source.

I am testing a '2560 design right now using 3 AA batteries. I have a 24V to 5V DC/DC module on the board, but don't have the right female cables yet to power it up.
Running from battery with no regulator is fine as long as the battery voltage is in the correct range.

Setting fuses is a really hard ask for new Arduino-compatible experimenters in a workshop. Do you know, is attaching an 8MHz crystal like http://www.taydaelectronics.com/8-000-mhz-8-mhz-crystal-hc-49s-low-profile.html in the place of the 16MHz crystal more-or-less equivalent to asking it to use it's internal clock, or is the change of fuses also needed to get other aspects of 328 behaviour to line up correctly with the 8MHz clock speed?

It would be great if I could just plug in an 8MHz crystal to the circuit, then use a 'board' setting in the Arduino IDE which would assume an 8MHz clock in its defines for Serial interrupts etc. Then I could use that setting when programming a simple 8MHz ATMEGA328 circuit which could be programmed directly off 5V but run down to a <3.8V supply on a battery without changing anything (assuming the project doesn't mind timings all going astray as per PaulS' comments).

Update: given the comments by WizenedEE below, I'm now of the feeling I shouldn't have accepted all of PaulS suggestions entirely as the gospel truth, although it sounds intuitively to make sense that many things change with a change in voltage, it seems that there are mechanisms specified to prevent this, such as crystals, and that there's no need to change fuses necessarily for a change in voltage. There still seems to some debate anyway. Now go on to read my original response >>>>>>>>>

With suitable changes to fuse settings, the Arduino can run at either 3.3V or 5V, not any random value in between.

Aha, makes perfect sense. I had no idea that fuses had to be changed to support a 3.3V set up, although I knew 8MHz operation needed a change in fuses I didn't figure for the voltage itself having to be accounted for. I guess the Jeenodes I had just came with the correct fuse settings out of the box. I'll follow up with JCW at Jeenodes and see if I can find out more about this compromise.

...bad things happen when the voltage is not constant. Serial data transmission, among other things relies on clock speed, which is a function of voltage.

Right, that makes a huge amount of sense too. Fortunately when we're connected to the USB (and wanting to attempt Serial comms) it will be powered off the 5V regulated. The rest of the time perhaps we'll get away with a slow clock (and incorrect timings). Once people have got the idea of programming simple behaviours and the arduino-compatible bug has bitten, we can expose them to more complex design issues, so when they start to design their own projects which demand a near-real-time clock or an actual real-time clock, then we can talk them through using a power regulator or a supporting chip. I think we're already stuck with a 'now we add 4 capacitors and a diode for protection' phase in the workshop, and this might be a moment to introduce the power regulator too.

Perhaps you're trying to underline my ignorance.

Not really. Just questioning why you think that the 5V is not important.
[/quote]

I simply didn't know why 5V was important. What you describe makes a lot of sense, thankyou.

Given their low cost I'd really REALLY consider using an LDO regulator when running from batteries. I wouldn't feel comfortable feeding any microcontroller-based project from an unregulated supply, even from batteries. It doesn't really add much complexity to the circuit

One of the aspects of the way we're workshopping with the ATMEGA chips is to try and maintain continuity as much as possible from one stage to the next. Ideally the exact same solderless breadboard circuit powered off the CP2102 attached to a laptop is transferred to stripboard wholesale, without having to rethink or rewire it. One way to go is to include the LDO regulator in the circuit even when it's not strictly needed (e.g. when attached to the regulated USB supply). That way we can switch seamlessly from the USB-connected lab-prototyping mode into a battery-operated in-the-field mode without any sleight of hand.

Do you think this would work? I gather there's a loss of voltage when going through a regulator, but given the spec of the component you described this may not be significant.