Menu

Category Archives: Arduino

Anyone who works with Arduino for any length of time will become familiar with the FTDI USB to Serial bridges. These convert the USB interface found on all modern computers into a simple serial interface, required by many Arduino boards for their bootloader.

There are many FTDI cables and boards available. A lot of Arduino boards have a built-in FTDI chip (the older ones with a USB port). Many vendors sell FTDI cables which have USB on one end and a pin header on the other (the chip is embedded in the USB connector). There are also a lot of breakout boards available.

There are two important voltage specifications on each cable:

Signalling voltage – they are generally available in 5V or 3.3V signalling. It is possible to damage some 3.3V boards using 5V signalling. With the ATmega microcontrollers, you should never exceed 3.8V on any pin with Vcc at 3.3V, but it doesn’t seem to cause damage. Conversely, a ATmega running with Vcc at 5V will pick up 3.3V as logic high with no issues. If in doubt, go with the 3.3V cable.

Power supply voltage (Vcc) – the normal FTDI pin out provides a power supply on one of the pins. Generally you get either 5V or 3.3V. The 5V versions often supply VUSB direct – so you can draw 500mA. Most of the 3.3V ones however use the pin 3V3OUT on the FTDI chip, which cannot supply more than 50mA (and the FTDI chip gets very hot when doing so!). This often isn’t enough to power a project. Again, a lot of boards don’t really care, but some ancillaries like radio chips will die if given 5V instead of 3.3V. The ATmega is a very forgiving chip.

There’s one big thing to catch you out here. A lot of the 3.3V cables still provide 5V on the Vcc pin. I didn’t realise this until I frazzled a CC1110 board with 5V.

So there are a lot of combinations of voltages available. Rather than have a four or more FTDI cables handy, I’ve found one particular board is versatile enough to use in all situations, with a bit of modification.

The USB BUB II is available from Jeelabs and Modern Device. It’s a small board, and by default it has 3.3V signalling with a 5V power supply. With a few small changes, it can be a lot more versatile.

It has a some good points that many other solutions don’t have. A small polyfuse protects your computer from over-current (although most machines seem fairly tolerant of this nowadays). It also has RX/TX lights, which are absent on many DIY and smaller boards.

Onto the modifications.

1. There are two pairs of small solder bridges on the front of the board, one labelled VOUT and the other LGLV. Use solder braid to remove solder from whichever combination is currently soldered.

2. Solder a pair of 3-pin headers into the space next to VOUT and LGLV. This allows you to chose between 5V from USB or 3.3V from 3v3OUT using jumpers.

3. Turn the board over and cut the 3v3_OUT trace using a scalpel. Bridge the VR_OUT pads using solder.

4. Finally, solder on a 3.3V regulator on the back of the board. Modern Devices suggest a MCP1703 which can provide 250mA. I used a MCP1825 which can provide 500mA as it was what I had lying around.

Now you have a FTDI board which will work for all of your 5V and 3.3V boards, as well as being able to provide power for most small projects.

A lot of Arduino sketches make fairly heavy use of the “boolean” type – after all, digitalRead() and digitalWrite() use TRUE/FALSE or HIGH/LOW don’t they? Why not use boolean? It seems intuitive, after all.

One of the silliest lines in Arduino

Well, there are many, many reasons not to use boolean. I think it is one of the biggest mistakes in the Arduino environment.

Everything on the AVR is at least 8 bits wide. If I write to a memory location, register, or port, I need to write all 8 bits. If I read, I need to read all 8 bits. A boolean is just a single bit. We can infer from this that we are going to need to do some work to represent a boolean.

The next thing we need to realise is how C evaluates true and false on various types. This is really simple. If every bit in an integer is set to 0, evaluate this as false. Otherwise, true. This stems from the way that processors work internally, using the Z (zero) flag to determine if a branch should be taken or not.

This means that 0xA6 is as true as 0x01 is as true as 0xFF. The only thing that evaluates to false is 0x00.

These two things – the smallest native memory location being 8 bits wide, and the evaluation of 0x00 as false – make it really easy to implement a boolean. We just use an 8-bit unsigned integer and call it boolean. We then assigned 0x00 to FALSE and something non-zero to TRUE.

1

2

3

typedefuint8_t boolean;

#define FALSE 0

#define TRUE 1

This is almost exactly how Arduino implements booleans. It works, but it hides some of the fundamental concepts you need to understand to efficiently write code for AVR microcontrollers.

What are the problems with this?

You are wasting 7 bits of a 8 bit memory location or register. This is fine on a modern PC, but on an AVR microcontroller, you only have 32 registers and limited RAM.

This is hugely exacerbated when you have build arrays of boolean. Having an array of bits is very common (for example, in serial transmission). “boolean arr_of_bool[32]” uses 32 bytes to store 32 bits. Use “uint8_t arr_of_uint8[4]” instead, and learn how to set bits.

It hides the concept that the only thing that evaluates to false is 0. You often see “if (variable == true)” in Arduino code. It just isn’t required. Even worse is “if (variable ? TRUE : FALSE)”. Ouch – I’ve even seen this tenary operator inside a comparison in a library before.

It hides the concept of setting individual bits in a byte. You really cannot go very far in embedded systems without knowing about this.

It is not a native C type. Move to another platform or compiler and you will need to re-implement it. Should it be bool or boolean? true or TRUE? HIGH or LOW?

I’d be really keen to see Arduino move towards native data types, but I can’t see it happening.

Whilst writing up some of the forthcoming posts on the alarm system, I found myself trying to write a simple method of setting, clearing, and getting bits in a byte buffer. I wanted this to be as transparent as possible so that the code was easy to understand.

The AVR microcontrollers are 8-bit. This means that registers, memory, and addresses are all 8-bits wide. It surprises many Arduino users when they find out that the type “boolean” is simply an entire unsigned, 8-bit integer (uint8_t). Boolean is just not a native concept to C and embedded systems. It’s incredibly wasteful to use a whole 8 bits to represent a single boolean value.

Bitwise operations

This isn’t to say that you don’t need to set individual bits in a byte though – this is actually a very common operation. Normally to do this, you use a couple of simple constructs.

To set the 6th bit in a register (0 is the first bit):

1

REGISTER|=1<<5;

This means “Shift 0b00000001 along 5 to 0b00010000, and perform a logical OR with whatever is in the register already”. This has the effect of setting bit 5 to 1, and leaving all the other bits as are.

To clear the 5th bit in a register:

1

REGISTER&=~(1<<4);

This means “Shift 0b00000001 along 4 to 0b00001000, invert it to 0b11110111, and perform a logical AND with whatever is in the register already”. This has the effect of clearing bit 4, and leaving all the other bits as are.

Bytewise operations

The above is all fine if you just want to look at a single bit in a byte. What happens if I want to deal with more than 8-bits? I need more bytes!

By far the easiest way to do this is to use an array:

1

uint8_t array_of_bytes[32];

Which just means “create an array of 32 unsigned 8-bit integers”.

I can access the first byte using:

1

array_of_bytes[0];

And the tenth by using:

1

array_of_bytes[9];

Really simple! I can combine this with the bitwise operations:

1

2

array_of_bytes[13]|=1<<3;

array_of_bytes[4]&=~(1<<6);

Now I have an easy way of accessing any bit in an array of bytes.

Bringing it together

The problem comes if I decide I want to set the bit 27 in the array. How do I work out which byte this is in?

This is just some simple maths. To work out the byte, integer divide 27 by 8 – we get 3. This means it will be in the 4th byte i.e.

1

array_of_bytes[3];// indexing starts at 0!

Then take the remainder of 27 by 8 (the modulus) – we get 3 again. We need to set the 4th bit.

1

array_of_bytes[3]|=(1<<3);

So now we have a method to set an individual bit in an array of bytes.

Making it easier

Rather than remember all of this maths and shifting each time I want to set a bit, why not use a macro?

1

#define bit_set(array,i) array[i/8] |= 1 << (i % 8)

This is just want we have said above. % is the modulus operator in C. This looks very clean and efficient.

That is until I use it in a project and find it is incredibly slow to set each bit in a buffer one by one. Why could this be? (I’ll go into benchmarking code another time)

If you look through the ATmega328P or ATmega2560 datasheets, you can see two key things:

There is no hardware division unit on the microcontroller – division is expensive!

There is only a single bit shift in either direction. Shifts of more than one need to be made up of multiple single bit shifts.

There’s something clever we could try here though. Division by 8 is exactly the same as shifting right by 3 bits:

1

2

3

0b00011011(dec27)

shift3bits right

0b00000011(dec3)

So now we can change our macro a bit:

1

#define bit_set(array,i) array[i >> 3] |= 1 (i % 8)

We can take this further though… modulus 8 is the same as only keeping the first 3 bits of a number i.e. masking.

1

2

3

0b00011011(dec27)

mask with0b00000111

0b00000011(dec3)

So the macro can be changed even further:

1

#define bit_set(array,i) array[i >> 3] |= 1 << (i & 0x07)

And now we recompile and try again…

And get exactly the same result as before.

It turns out avrgcc is clever enough to spot that the divide by 8 and modulus 8 can be implemented by simple shifts and masks.

What is the moral of this story? Generally these days you will not make many gains in micro-optimisation. The compiler handles all of this, and normally much better than you can. Think about the big picture to make gains!

This one has come up a lot recently on the Arduino subreddit and Electronics stackexchange – can I power my Arduino with a 9V battery?

The quick answer is yes, you can.

The long answer is yes, but only if your goal is to chose the most expensive and short lived batteries possible.

9V PP3 battery (Ashley Pomeroy, Wikipedia)

I think the boards and documentation should have an explicit warning about 9V PP3s for this reason!

9V is not a good input voltage to produce 5V through a linear regulator

The first problem is how to reduce that 9V to 5V that the Arduino board can use. Most Arduino boards have an external voltage input, and a range of 7-12V is recommended. So 9V seems perfect.

The problem is that most Arduino boards use a linear regulator to drop that 9V to 5V. If you are drawing a mere 50mA, 0.2W is being burnt in this linear regulator with 0.25W being used by the Arduno itself. This is very inefficient!

To solve this, either another battery should be used, or a switch-mode regulator used – these are much, much more efficient.

Even worse is if you try to draw large currents – say 250mA – from the 9V source. The regulator needs to now burn 1W of power. It will fry in no time!

9V batteries are very low capacity

An alkaline 9V PP3 has a capacity of between 500 and 600mAh. This really isn’t very high – a typical alkaline AA battery will be at least 2000mAh. 6 series AA cells will provide the same voltage, but a capacity at least 4 times the size!

This gets even worse if you look at rechargeable 9V batteries. A typical 9V PP3 NiMH battery has a capacity of less than 200mAh. This is so low it is hardly worth bothering with.

No matter how efficient the regulation is, these batteries are not going to last very long.

Ideal solution

First thing first, you need to ditch that linear regulator. It is meant to regulate external voltages when power loss is not an issue.

Use one of the modern switching regulators like the LTC3525 – this can take an input voltage of between 1.0V and 5.5V and convert it to 3.3V or 5V as required. Bypass the linear regulator on the board.

Couple this new regulator with high capacity AA batteries. The LTC3525 is so versatile it can take one, two or three batteries and drain the last drop out of them.

AA batteries are common, cheap, and high capacity. There are excellent rechargeable batteries available as well. Please stop using the 9V PP3s!

On the ATmega328P and most other Atmel microcontrollers, code is stored and executed in flash memory. Every time you “upload a sketch”, you are communicating with a small piece of code called the bootloader, which then programs the flash with your code.

Flash has a finite number of program/erase cycles – you can only write to it a certain number of times before bits will either be programmed incorrectly or become stuck at 1 or 0. With an ATmega328P, this will render the device unusable unless you invest a lot of time fiddling with the toolchain.

Now and then, someone will either ask “Will I wear out the chip?” or someone will admonish a newbie for so frequently programming the chip.

The reality of it is you are highly unlikely to wear out the flash memory on an Arduino.

Atmel spec 10,000 cycles. I don’t know the maths behind it, but it means they are highly confident a large proportion of chips will reach this level.

If we put that in real terms – if you are a hugely dedicated hobbyist who spends 2 hours each weekday and 8 hours over the weekend on their Arduino, flashing it once every 5 minutes, you will get almost a year of use before the chip could fail.

For a much more reasonable use case of about 8 hours per week, flashing it every 15 minutes, you get 6 years of use.

For the <£5 that the chip costs, this seems entirely reasonable to me.

Further to this – take into consideration that 10,000 cycles is almost guaranteed. Many will get far higher than this. Dangerous Prototypes have a project called the “Flash Destroyer“, which has the sole purpose of performing program/erase cycles on EEPROM to see how far it will go. A 1,000,000 cycle EEPROM got to 11,500,000 cycles before failure.

There’s no doubt the Raspberry Pi is extremely popular, and has been in the media far more than the lowly Arduino. But many users, forums and reddit seem to think that the Raspberry Pi is going to make the Arduino obsolete – after all, why would you spend £30 on an Arduino when you could spend £30 on a Raspberry Pi?

The Raspberry Pi is amazing – it’s a powerful ARM board for not very much. It has design flaws – the power by USB being the main one – but it has found a place, mainly as a media server for geeks.

However, for those looking for an Arduino replacement, it has many downsides:

1. The GPIO pins are only 3.3V tolerant. This locks out vast numbers of 5V add-on boards and peripherals that can be used by the Arduino.

2. The GPIO pins can only sink/source very low levels of current. So you need to add drivers to get decent levels of current. The ATmega328P has much stronger drive levels.

3. The whole board is less tolerant of overload of mistreatment. The ATmega328P is actually a very hardy chip.

4. The hardware peripherals built-in are lacking – timers, ADCs, PWM, pin change interrupts and so on. It may have some of these, but if it does, they aren’t widely documented.

5. If I want to use the ATmega328P in my own project, I can build a clone board for £5. I can’t built a Raspberry Pi, at all, and my tools, soldering and assembly skills are very good.

6. I can run an Arduino-like board for months, even years, on a single AA battery with aggressive power saving. This is just not possible with a Raspberry Pi.

7. Linux is not a real-time OS (RTOS). This may not mean much to a lot of people, but interfacing to the real world can be a real pain when IO and interrupts are not serviced predictably.

People build their projects, then want to battery power them. Their solution is to use a large battery (e.g. a 12V lead acid), connected to the Arduino external power input. The battery lasts mere days, and they become frustrated and move on to processors perceived as low power, like the MSP430 and ARM Cortex M0 series.

What if I said you could run a ATmega328P, RF transceiver and sensors from AA batteries for months at a time? A lot of people just won’t believe it, thinking the ATmega328P is a dated, power hungry chip that needs an ugly wall wart for power.

So why are people struggling with battery power?

1. The standard Arduino board accepts an external power input of between 7-12V, which then passes through a delightfully named NCP1117ST50T3G low dropout linear regulator to get it down to 5V for the rest of the board. If you are using a 12V battery via this regulator, and drawing a measly 50mA, you end up burning 0.35W of power in the regulator and the Arduino only using 0.25W! That linear regulator is an evil thing.

2. Most Arduino boards run at 5V. The ATmega328P runs fine at 3.3V and even down to 1.8V. At 3.3V, the chip uses ~40% of the power, and at 1.8V, it uses ~10%. Massive gains! 1.8V can make interfacing to other systems a bit awkward, but 3.3V is generally fine.

3. Most Arduino boards run at 16MHz by default, but a lot of the time you don’t need to run that quickly. By dropping to use the 1MHz internal oscillator, you reduce the power consumption 8 times. If you go further, you can use 128kHz oscillator and the power consumption drops 70 times!

4. A lot of Arduino code uses delays() and never sleeps. The ATmega328P has a sleep mode which can easily use less than 10µA – if you use an external 32.768kHz watch crystal, you can get this down to fractions of a µA. Learn about these and use them.

For the second post about Arduino misconceptions, there is the a common idea circulating that the Arduino is “slow”. Most frequently I hear this in the context of reacting to user input, dealing with multiple sensors, using LED or LCD displays, or acting as part of a control loop. People advise faster microcontrollers such as the ARM Cortex series.

Let’s look at the fundamentals here:

The ATmega328P on the Arduino boards runs at 16MHz – that’s 16 million cycles per second.

The ATmega328P instructions take between 1 and 3 clock cycles (with the exception of the subroutine related instructions which take 4 or 5). The average is somewhere between 1 and 2 for most compiled C code.

We can then infer than the ATmega328P can carry out at least 8 million instructions per second!

It’s hard to directly translate these instructions to lines of C code. What looks simple in C can take tens of instructions, and what looks complex can be done in one.

We can still say that the ATmega328P is going to tear through your code at a rate of knots, far faster than most people imagine.

So why do people say it is slow? I’d say the following reasons:

It is 16MHz, and most people’s PCs and phones operate in the 1GHz range, so it doesn’t sound like much. The ATmega328P is performing entirely different tasks though.

It is 8bit, and most modern processors are 32 or 64 bit. This doesn’t have many implications for projects using the Arduino though (but will be related to my next misconception!)

The frequent use of delay() in Arduino code. Delay() causes the processor to just churn – it can’t do anything else whilst it is running. So if you have 4 buttons which are meant to turn on 4 respective LEDs for 2s, the system becomes unresponsive if you use delay() for the 2s.

The frequent use of Serial.print() in most code for debugging or status reports. Arduino pre-1.0 uses to block when sending data out using the serial port. That meant an 80 character string output at 9600bps (the default, for some reason), would take over 80ms, during which time the processor could do nothing else! Even now that it uses interrupts, strings still take a long time to output.

Slow digitalRead and digitalWrite – these two functions are orders of magnitude (~60 cycles) slower than direct port access (~1 cycle!). Heavy I/O can look slow or latent as a result.

Bad code – the Arduino is exceptionally easy to use without understanding any of the underlying concepts of microcontrollers. As a result, code is sometimes simply bad.

A faster microncontroller can mask some of these issues, but without understanding some key concepts (interrupt handling and well structured state machines), you are going to be up against the same wall again in no time.

That’s not to say that faster microcontrollers aren’t needed sometimes – anything with heavy number crunching needs something more – but for a lot of situations an Arduino is more than capable in the hands of a good developer.

One of the first things you need to learn when interfacing switches to microcontrollers is the use of pull-up resistors. These ensure that the inputs to the microcontroller settle in either logic high or low when the switch is not made. They are fundamental, so fundamental that Atmel decided to build-in weak pull-up resistors into the ATmega328P used in the Arduino!

Simple pull-up resistor

Yet a lot of tutorials show external pull-up resistors being used with switches. There’s not really a problem with this – just that it is not required 99% of the time. It might be good to teach the concept, but I regularly see posts on forums where people have connected pull-ups incorrectly, causing them problems. I’ve even seen people confident enough to design a PCB, but have multiple external pull-ups for interfacing to a keypad!

So how do you use the internal pull-ups? It is very simple – when the data direction register is set to input, write a high to the output port:

pinMode(pin, INPUT);
digitalWrite(pin, HIGH);

Or, if you have moved away from the Arduino libraries:

DDRx &amp;= ~(1 &lt;&lt; pin);
PORTx |= (1 &lt;&lt; pin);

What’s the other 1% where these internal pull-ups won’t do? There are two situations:

The switch requires a pull-down rather than pull-up – though this can generally be avoided

You need a strong rather than weak pull-up – sometimes devices draw power from the pull-up, and the 20kOhm internal pull-up is too large.

I'm a security researcher and reverse engineer. By visiting this site, you must realise that any or all files on this site may be jam packed full of the finest exploits, tricks and other gubbins. You might also get geo-located and port-scanned for fun and profit.
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptRead More
If I really want to track you, by tricking you into visiting this site, then it's going to be a lot more subtle than a browser cookie.