text:
Is using malloc() and free() a really bad idea on Arduino?
The use of malloc() and free() seems pretty rare in the Arduino world. It is used in pure AVR C much more often, but still with caution.
Is it a really bad idea to use malloc() and free() with Arduino?

you'll run out of memory really fast otherwise, and if you know how much memory you'll use you might as well statically allocate it anyway

As usual, the right answer is "it depends." You haven't provided enough information to know for sure whether dynamic allocation is right for you.

My general rule for embedded systems is to only malloc() large buffers and only once, at the start of the program, e.g., in setup(). The trouble comes when you allocate and de-allocate memory. Over a long run session, memory becomes fragmented and eventually an allocation fails due to lack of a sufficiently large free area, even though the total free memory is more than adequate for the request.
(Historical perspective, skip if not interested): Depending on the loader implementation, the only advantage of run-time allocation vs. compile-time allocation (intialized globals) is the size of the hex file. When embedded systems were built with off the shelf computers having all volatile memory, the program was often uploaded to the embedded system from a network or an instrumentation computer and the upload time was sometimes an issue. Leaving out buffers full of zeros from the image could shorten the time considerably.)
If I need dynamic memory allocation in an embedded system, I generally malloc(), or preferably, statically allocate, a large pool and divide it into fixed-size buffers (or one pool each of small and large buffers, respectively) and do my own allocation/de-allocation from that pool. Then every request for any amount of memory up to the fixed buffer size is honored with one of those buffers. The calling function doesn't need to know whether it's larger than requested, and by avoiding splitting and re-combining blocks we solve fragmentation. Of course memory leaks can still occur if the program has allocate/de-allocate bugs.
Update 02/16/23:

I'm curious why the Arduino library's malloc implementation doesn't
implement some coalescing of the free blocks like a full OS would.

That's interesting to think about, but let's first be clear that in C/C++, malloc() and free() are implemented as library functions at the application-level not the OS level, even in major OSes. And they are based on fragmenting the heap, just as the Arduinos' malloc() functions do.
Embedded systems, are relatively new, at least as an influential force in the design of OSes, languages, and libraries' design. Which is to say, programs that had to run "forever" without failing (other than, perhaps the OS itself) were outliers. Most programs we run on our desktops or (once upon a time) ran on mainframes, were started, processed a batch of data, and exited.
Secondly, the malloc()/free() method of memory allocation/deallocation was simple, where anticipating the sizes of memory requests was not; and some allocations are used briefly and returned, where some are kept for the duration of the run. How is a library designer to provide for coalescing currently free and newly deallocated memory with no knowledge of the allocate/deallocate usage and sizes of requests? The fixed-size buffer scheme I described above doesn't suffer the fragmentation problem that "malloc() an arbitrary number of bytes" scheme does. It is still limited to available memory but within that limitation, could meet the "run forever" requirement. There may be algorithms that split and coalesce memory, but probably only for a few - statistically predictable - patterns of allocation and deallocation.
Update 02/18/23:
@edgarbonet points out that Arduino's free() does try to coalesce free blocks. This is a good example of an algorithm that works for certain cases: Properly done, it would work for "last-out / first-in" cases, and to some extent for some other cases.
The trouble is, most of our use patterns are not very regular, if they're regular at all. An alogrithm that does no splitting, but merely allocates & deallocates fixed-size pieces (rather like loaning library books) can still run out of memory but won't end up with fragmented resources. In fact, because it doesn't split, it will need more memory to meet the same random-sized requests than even a coalescing malloc() and free().

Another historical note, this quickly led to the BSS segment, which allowed a program to zero its own memory for initialization, without slowly copying the zeros during program load.

I'm curious why the Arduino library's malloc implementation doesn't implement some coalescing of the free blocks like a full OS would.

@vasilescur: The AVR implementation of malloc()/free() does coalesce adjacent free blocks.

I have taken a look at the algorithm used by malloc(), from avr-libc,
and there seems
to be a few usage patterns that are safe from the point of view of heap
fragmentation:
1. Allocate only long-lived buffers
By this I mean: allocate all you need at the beginning of the program,
and never free it. Of course, in this case, you could as well use static
buffers...
2. Allocate only short-lived buffers
Meaning: you free the buffer before allocating anything else. A
reasonable example might look like this:
void foo()
{
    size_t size = figure_out_needs();
    char * buffer = malloc(size);
    if (!buffer) fail();
    do_whatever_with(buffer);
    free(buffer);
}

If there is no malloc inside do_whatever_with(), or if that function
frees whatever it allocates, then you are safe from fragmentation.
3. Always free the last allocated buffer
This is a generalization of the two previous cases. If you use the heap
like a stack (last in is first out), then it will behave like a stack
and not fragment. It should be noted that in this case it is safe to
resize the last allocated buffer with realloc().
4. Always allocate the same size
This will not prevent fragmentation, but it is safe in the sense that
the heap will not grow larger than the maximum used size. If all your
buffers have the same size, you can be sure that, whenever you free one
of them, the slot will be available for subsequent allocations.

Pattern 2 should be avoided as it adds cycles for malloc() and free() when this can be done with "char buffer[size];" (in C++). I would also like to add the anti-pattern "Never from an ISR".

Typically, when writing Arduino sketches, you will avoid dynamic allocation (be it with malloc or new for C++ instances), people rather use global -or static- variables, or local (stack) variables.
Using dynamic allocation can lead to several problems:

memory leaks (if you lose a pointer to a memory you previously allocated, or more likely if you forget to free the allocated memory when you don't need it anymore)
heap fragmentation (after several malloc/free calls) where the heap grows bigger thant the actual amount of memory allocated currently

In most situations I have faced, dynamic allocation was either not necessary, or could be avoided with macros as in the following code sample:
MySketch.ino
#define BUFFER_SIZE 32
#include "Dummy.h"

Dummy.h
class Dummy
{
    byte buffer[BUFFER_SIZE];
    ...
};

Without #define BUFFER_SIZE, if we wanted Dummy class to have a non-fixed buffer size, we would have to use dynamic allocation as follows:
class Dummy
{
    const byte* buffer;

    public:
    Dummy(int size):buffer(new byte[size])
    {
    }

    ~Dummy()
    {
        delete [] bufer;
    }
};

In this case, we have more options than in the first sample (e.g. use different Dummy objects with different buffer size for each), but we may have heap fragmentation issues.
Note the use of a destructor to ensure dynamically allocated memory for buffer will be freed when a Dummy instance is deleted.

I disagree with people who think you shouldn't use it or it is generally unnecessary. I believe it can be dangerous if you don't know the ins and outs of it, but it is useful. I do have cases where I don't know (and shouldn't care to know) the size of a structure or a buffer (at compile time or run time), especially when it comes to libraries I send out into the world. I agree that if you're application is only dealing with a single, known structure, you should just bake in that size at compile time.
Example: I have a serial packet class (a library) that can take arbitrary length data payloads (can be struct, array of uint16_t, etc.). On the sending end of that class you simply tell the Packet.send() method the address of the thing you wish to send and the HardwareSerial port through which you wish to send it. However, on the receiving end I need a dynamically allocated receive buffer to hold that incoming payload, as that payload could be a different structure at any given moment, depending on the application's state, for instance. IF I'm only ever sending a single structure back and forth, I'd just make the buffer the size it needs to be at compile time. But, in the case where packets may be different lengths over time, malloc() and free() are not so bad.
I've run tests with the following code for days, letting it loop continuously, and I've found no evidence of memory fragmentation. After freeing the dynamically allocated memory, the free amount returns to its previous value.
// found at learn.adafruit.com/memories-of-an-arduino/measuring-free-memory
int freeRam () {
    extern int __heap_start, *__brkval;
    int v;
    return (int) &v - (__brkval == 0 ? (int) &__heap_start : (int) __brkval);
}

uint8_t *_tester;

while(1) {
    uint8_t len = random(1, 1000);
    Serial.println("-------------------------------------");
    Serial.println("len is " + String(len, DEC));
    Serial.println("RAM: " + String(freeRam(), DEC));
    Serial.println("_tester = " + String((uint16_t)_tester, DEC));
    Serial.println("alloating _tester memory");
    _tester = (uint8_t *)malloc(len);
    Serial.println("RAM: " + String(freeRam(), DEC));
    Serial.println("_tester = " + String((uint16_t)_tester, DEC));
    Serial.println("Filling _tester");
    for (uint8_t i = 0; i < len; i++) {
        _tester[i] = 255;
    }
    Serial.println("RAM: " + String(freeRam(), DEC));
    Serial.println("freeing _tester memory");
    free(_tester); _tester = NULL;
    Serial.println("RAM: " + String(freeRam(), DEC));
    Serial.println("_tester = " + String((uint16_t)_tester, DEC));
    delay(1000); // quick look
}

I haven't seen any sort of degradation in RAM or in my ability to allocate it dynamically using this method, so I'd say it's a viable tool. FWIW.

Your test code conforms to the usage pattern 2. Allocate only short-lived buffers I described in my previous answer. This is one of those few usage patterns known to be safe.

In other words, the problems will come up when you start sharing the processor with other unknown code - which is precisely the problem you think you are avoiding.  Generally, if you want something that will always work or else fail during linking, you make a fixed allocation of the maximum size and use it over and over again, for example by having your user pass it in to you in initialization.  Remember you are typically running on a chip where everything has to fit in 2048 bytes - maybe more on some boards but also maybe a lot less on others.

@EdgarBonet Yes, exactly. Just wanted to share.

@ChrisStratton It's because of the memory constraints that I believe dynamically allocating the buffer of only the size required in the moment is ideal. If the buffer isn't need during regular operation, the memory is available for something else. But, I see what you're saying: Allocate a reserved space so that something else doesn't take away the space you may need for the buffer. All great information and thoughts.

Dynamically allocating a buffer of only the size needed is risky, as if anything else allocates before you free it you can be left with fragmentation - memory that you can't re-use.  Also, dynamic allocation has tracking overhead.  Fixed allocation doesn't mean you can't multiply use the memory, it just means that you have to work the sharing into the design of your program.  For a buffer with purely local scope, you might also weigh use of the stack.  You haven't checked for the possibility of malloc() failing either.

@ChrisStratton Right, that chunk of code doesn't check if malloc() works or not. Then again, that chunk of code is using notoriously fat Arduino libraries and routines. :) Thanks for your insight. Very reasonable and valuable.

"it can be dangerous if you don't know the ins and outs of it, but it is useful." pretty much sums up all development in C/C++. :-)

Using dynamic allocation (via malloc/free or new/delete) isn't inherently bad as such. In fact, for something like string processing (e.g. via the String object), it's often quite helpful. That's because many sketches use several small fragments of strings, which eventually get combined into a larger one. Using dynamic allocation lets you use only as much memory as you need for each one. In contrast, using a fixed-size static buffer for each one could end up wasting a lot of space (causing it to run out of memory much faster), although it depends entirely on the context.
With all of that being said, it's very important to make sure memory usage is predictable. Allowing the sketch to use arbitrary amounts of memory depending on run-time circumstances (e.g. input) can easily cause a problem sooner or later. In some cases, it might be perfectly safe, e.g. if you know the usage will never add up to much. Sketches can change during the programming process though. An assumption made early-on could be forgotten when something is changed later, resulting in an unforeseen problem.
For robustness, it's usually better to work with fixed-size buffers where possible, and design the sketch to work explicitly with those limits from the outset. That means any future changes to the sketch, or any unexpected run-time circumstances, should hopefully not cause any memory problems.

Is it a really bad idea to use malloc() and free() with Arduino?

The short answer is yes. Below are the reasons why:
It is all about understanding what an MPU is and how to program within the constraints of the available resources. The Arduino Uno uses an ATmega328p MPU with 32KB ISP flash memory, 1024B EEPROM, and 2KB SRAM. That is not a lot of memory resources.
Remember that the 2KB SRAM is used for all global variables, string literals, stack and possible usage of the heap. The stack also needs to have head room for an ISR.
The memory layout is:

Todays PC/laptops have more than 1.000.000 times the amount of memory. A 1 Mbyte default stack space per thread is not uncommon but totally unrealistic on an MPU.
An embedded software project has to do a resource budget. This is estimating  ISR latency, necessary memory space, compute power, instruction cycles, etc. There are unfortunately no free-lunches and hard real-time embedded programming is the most difficult of programming skills to master.

Amen to that: "[H]ard real-time embedded programming is the most difficult of programming skills to master."

Is the execution time of malloc always the same? I can imagine malloc taking more time as it searches further in the available ram for a slot that fits? This would be yet another argument (aside running out of ram) to not allocate memory on the go?

@Paul The heap algorithms (malloc and free) are typically not constant execution time, and not reentrant. The algorithm contains search and data structures that require locks when using threads (concurrency).

In light of the resource limitations of such small devices some would argue that the use of malloc/free as required for the scenarios is a much more efficient use of resources than pre allocating a bunch of fixed size buffers whose size must be large if being conservative (i.e. able to handle ALL scenarios). Lots of wasted allocation most of the time in that usage pattern methinks.

Ok, I know this is an old question but the more I read through the answers the more I keep coming back to an observation that seems salient.
The Halting Problem Is Real
There seems to be a link with Turing's Halting Problem here.  Allowing dynamic allocation increases the odds of said 'halting' so the question becomes one of risk-tolerance. While it is convenient to wave off the possibility of malloc() failing and so forth, it is still a valid outcome.  The question the OP asks only appears to be about technique, and yes the details of the libraries used or the specific MPU do matter; the conversation turns towards reducing the risk of the program halting or any other abnormal end. We need to recognize the existence of environments that tolerate risk vastly differently.  My hobby project to display pretty colors on a LED-strip won't kill someone if something unusual happens but the MCU inside a heart-lung machine likely will.
Hello Mr. Turing My Name is Hubris
For my LED-strip, I don't care if it locks up, I'll just reset it.  If I were on a heart-lung machine controlled by an MCU the consequences of it locking up or failing to operate are literally life and death, so the question about malloc() and free() should be split between how the intended program deals with the possibility of demonstrating Mr. Turing's famous problem. It can be easy to forget that it is a mathematical proof and to convince ourselves that if only we are clever enough we can avoid being a casualty of the limits of computation.
This question should have two accepted answers, one for those who are forced to blink when staring The Halting Problem in the face, and one for all others. While most uses of the arduino are likely not mission critical or life-and-death applications, the distinction is still there regardless of which MPU you may be coding.

I don't think the Halting problem applies in this specific situation considering the fact that heap usage isn't necessarily arbitrary. If used in a well-defined manner then heap usage becomes predictably "safe". The point of the Halting problem was figure out if it can be determined what happens to a necessarily arbitrary and not-so-well-defined algorithm. It really applies much more to programming in a broader sense and as-such I find it to be specifically not very relevant here. I don't even think it's relevant at all to be entirely honest.

I'll admit to some rhetorical exaggeration but the point is really if you want to guarantee behavior, using the heap implys a level of risk that is much higher than sticking to only using the stack.


text:
Is there a way to detect if Arduino, Stino or another IDE/toolchain is in use?
I've noticed some irritating differences between the Arduino IDE and Stino (mainly around including certain header files). These are likely bugs that need following up with one or both of the parties, but in the meantime, I would like my code to compile with both of them without editing. This is because I do not want to lock any users out of using my code.
Are there any macros or similar that are readily available (as in, require no modification of the toolchain or IDE) that would allow me to detect which is in use?
For example, in many libraries, there is this snippet:
#if ARDUINO >= 100
  #include "Arduino.h"
#else
  #include "WProgram.h"
#endif

However both Stino and Arduino define this.

I've poked around in the Stino toolchain a fair bit, and submitted a pull request or two. It should be pretty easy to get something like #define STINO_COMPILER added to the compilation-time defines. The guy who manages the repo is quite open to sensible pull-requests like that, and once it's properly in the mainline repo, it wouldn't require changes for any of the end-users.

Thanks Fake Name - yes, I think that sounds like a good plan. I think I only need support for Stino really. I've not seen Eclipse used often enough to care.

This isn't a real solution but you could also add two versions of the code or somehow have a comment: Uncomment the following lines and delete the other lines for Stino. | @Fake Would that be a problem when using that code with the Arduino IDE?

To further Anonymous Penguin's comment, you could have a pound define per compiler.  And then the default version of the code has an error and will not run unless the user comments a line to specify which compiler they are using.  Something like this #if !defined(STINO_COMPILER) #error please uncomment one of the compiler lines #endif

As Stino claims to use the installed Arduino IDE you already have, which means you can not differentiate at compile time.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
What alternatives are there to the Optiboot bootloader?
Nearly all modern Arduino boards use the Optiboot bootloader. Compared to the ATmegaboot used before, this is smaller in flash terms (by about 1.5KB) and faster in upload speed (115.2k vs 57.6k) and starts your sketch quicker (the delay whilst waiting after reset is shorter).
Are there any alternatives to the Optiboot bootloader? Specifically, are there any smaller (in flash terms) boot loaders? What differences do they have?

Optiboot is about the smallest bootloader available.
But, there is a much more powerful (with inbuilt console for hardware testing, RAM and Flash contents checking, etc) bootloader with a more developed and robust stk500v2 communications protocol between avrdude and the AVR bootloader.
I've used it on the ATmega2560 and on the ATmega1284p. It works for both 3 byte and 2 byte program counter MCU.
I have a STK500v2 Bootloader version on Sourceforge.
This bootloader is based the Peter Fleury STK500v2 bootloader, updated by Mark Sproul. I've made edits to have it supporting with the Goldilocks (an ATmega1284p) board.
The key feature is to use the STK500v2 protocol for uploading the Flash image to the Arduino. This protocol is more robust and gives better error capabilities than the avr109 protocol. As an aside the avr109 protocol is called "Arduino" in the Arduino world, because it toggles DTR (to reset the board and automatically enter the bootloader), and the STK500v2 protocol is called "Wiring" in the Arduino world, because of the same reason.
The Fleury/Sproul STK500v2 bootloader is designed to work with the ATmega2560 which has a 3 byte program register, because of the larger Flash size. But, it also supports normal 2 byte boards (everything else really).
For boards with plenty of Flash (like Goldilocks 1284p), there is a hardware monitor that can be used to query Flash, SRAM and hardware; you can check connections without additional code, and check the actual contents of Flash and EEPROM. Because the 1284p supports 2 USART, I added the ability to have debugging on USART1, so that the upload process via USART0 isn't disturbed.

This seems to be part of FreeRTOS, is that bootloader totally independent from FreeRTOS?

It is totally independent. The bootloader is used to write flash with anything. FreeRTOS comes later after main() is started. I just keep it in the same repository. I didn't write it, just modified for my purposes.

This seems interesting; it would be useful if you could sum up important features of your bootloader in your answer: size in Flash, upload max speed, Arduino boars it can work with, and some more details about hardware testing).

It is (based on) the Peter Fleury STK500v2 bootloader, updated by Mark Sproul. I've made edits to have it supporting with the Goldilocks (an ATmega1284p) board. The key feature is to use the STK500v2 protocol for uploading the flash image to the Arduino. This protocol is more robust and gives better error capabilities than the avr109 protocol. As an aside the avr109 protocol is called "Arduino" in the Arduino world, because it toggles DTR (to reset the board and automatically enter the bootloader), and the STK500v2 protocol is called "Wiring" in the Arduino world, because of the same reason.

The Fleury/Sproul STK500v2 bootloader is designed to work with the ATmega2560 which has a 3 byte programme register, because of the large flash size. But, it also supports normal 2 byte boards (everything else really). For boards with plenty of flash (like Goldilocks 1284p) there is a hardware monitor that can be used to query flash, RAM, and hardware. You can check connections without additional code, and check the actual contents of flash and eeprom. Because the 1284p supports 2 USART, I added the ability to have debugging on USART1, so that the upload process via USART0 isn't disturbed.

Thanks for the info, I have updated your post as I think this information should directly be part of your answer. Feel free to add more information if you see fit!

One more question: you mention the Goldilocks 1284p a lot, but all features that work for it also work for the Arduino Mega, right?

Yes, absolutely. It was designed for 3 byte program counter devices, such as the Atmega2560/2561, the Arduino Mega.

TinySafeBoot is an alternative for ATtiny and ATmega devices.

Compatible to plenty of ATtinys and ATmegas (see below)
Read/Write access to Flash and EEPROM.
All IOs available for serial communication
One-wire, also with multiple AVRs on a single line
Autobauding, rugged protocol.
Activated by Reset + Password (optional)
Password and Timeout user changeable anytime.
"Emergency Erase" to overcome lost Password - kills all data but leaves bootloader intact.
ATtinys: ~ 550 bytes,
ATmegas: < 512 bytes (!)
TSB for ATtiny can update itself.
The Sourcecode is free Software (GPL)

anyone know how TSB compares to Optiboot? Last update seems at least 2 years ago...

Are there any alternatives to the Optiboot bootloader?

Err... not really. There's actually a [unofficial] modification to Optiboot to make it faster when uploading.

To install the high baud rate variations…

Ensure the Arduino IDE is not running
Download the 7-Zip archive using the link above
Extract the three files to the following directory: {Arduino Installation Root}\hardware\arduino\bootloaders\optiboot\
Open the boards.txt file located in the following directory: {Arduino Installation Root}\hardware\arduino\

Find This section inside it:
uno.name=Arduino Uno
uno.upload.protocol=arduino
uno.upload.maximum_size=32256
uno.upload.speed=115200
uno.bootloader.low_fuses=0xff
uno.bootloader.high_fuses=0xde
uno.bootloader.extended_fuses=0x05
uno.bootloader.path=optiboot
uno.bootloader.file=optiboot_atmega328.hex
uno.bootloader.unlock_bits=0x3F
uno.bootloader.lock_bits=0x0F
uno.build.mcu=atmega328p
uno.build.f_cpu=16000000L
uno.build.core=arduino
uno.build.variant=standard

Add the following section…
uno_uf.name=Arduino Uno / Upload Fast
uno_uf.upload.protocol=arduino
uno_uf.upload.maximum_size=32256
uno_uf.upload.speed=250000
uno_uf.bootloader.low_fuses=0xff
uno_uf.bootloader.high_fuses=0xde
uno_uf.bootloader.extended_fuses=0x05
uno_uf.bootloader.path=optiboot
uno_uf.bootloader.file=optiboot_atmega328_250000.hex
uno_uf.bootloader.unlock_bits=0x3F
uno_uf.bootloader.lock_bits=0x0F
uno_uf.build.mcu=atmega328p
uno_uf.build.f_cpu=16000000L
uno_uf.build.core=arduino
uno_uf.build.variant=standard

Change the two highlighted values to the baud rate you plan to use:    250000, 500000, or 1000000 Save and close the boards.txt file
Using your favourite ISP programmer, install the new bootloader. Don’t forget to: Ensure the Arduino Uno / Upload Fast board is selected (Tools / Board), If appropriate, ensure the Serial Port of
  your programmer is selected (Tools / Serial Port), Ensure the
  programmer is selected (Tools / Programmer), After installing the
  bootloader, change the Serial Port to the serial port of your Arduino
  Uno.

Above text slightly modified for compatibility with site. Original post

Besides that, and the ATmegaboot bootloader, you can't really find any alternative. I would imagine that if Arduino loads it on all the Unos ever produced, it's pretty optimized. The above hack speeds up upload time, but it doesn't reduce the size of the bootloader. You can also remove the wait time on the bootloader so it has a faster startup.
If you're that concerned about maximising flash see: How to really shrink a sketch and this answer [on on What can I do if I run out of Flash memory or SRAM?].

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Serial interrupts?
In a project, I’m using an EIA485 bus to send encrypted data packets. That works with Arduino’s buffered serial, but it is kind of awkward, and I’m using none of the more complex stuff in that class anyway.
If I do not use Serial anywhere in my Arduino sketch, is it safe to create my own interrupt handlers for USART_RXC etc. and to directly manipulate the USART registers?

Absolutely. The only interrupt that Arduino takes for itself unilaterally is the timer 0 overflow interrupt, used for timing purposes (delay(), milliseconds(), et alia).

Does it only define the ISR (like this one) once you've used the Serial object?

@Gerben: Using Serial causes it to link in two additional vectors on the '328P: USART, RX and USART, UDRE. I have not checked whether using Serial1 et alia is required for the further vectors on the '1280 or '2560. And to be fair I have not verified any of this on ARM.

Hmm 485. FYI if your interested in 9bit. I recently helped a friend and found it much quicker to tweak the existing core library. Rather than rewrite it. See https://gist.github.com/mpflaga/ebe6aadd20f81de8e970


text:
Can I load programs through the RS232 pins?
Can I upload new programs onto a MEGA2560 through a serial port connected to pins 2&3?  (through the correct RS232<->TTL level shifters)
I know the 16U2 chip acts as a USB->serial converter and it also asserting the reset which starts the bootloader running on the 2650. Does it do anything else?
As long as I can time the reset correctly, is there anything else preventing reprogramming directly through the RX/TX pins?
And if I do this, will the application program still be able to use the serial channel?

If there are resistors between the 16U2 and the 2560 then likely yes that may give you an opportunity to "overcome" the 16U2's transmit line, though reset timing may be tricky unless you graft in a way to drive that as well.

I'm actually looking at making a clone which wouldn't even have the 16U2.  I'd probably tie serial DTR to a reset circuit like the one the 16U2 is driving.

Then yes, you can just place a header for an FT232 header or similar, as the minimal interfaceless '328 boards do.

The stock bootloader will accept the load of new programs on PE0(RX input) and PE1(TX output) (of the ATmega2560) just after reset. Note PE0/1 on the Arduino correspond to pins D0 and D1. Not D2 and D3. You could change the Boot loader if desired.
There is a 1K series resistor between the 16U2 and 2560's PE0/1. So you can directly connect your external TTL serial port's TX(out) to PE0(D0), without harm. And correspondingly connect PE1(D1) to the TTL Serial port's RX(in).
Next you need to synchronize the bootloader. Either by manually synchronizing the Reset of the 2560 with the starting of the download (of AVRdude). Or by connecting the DTR(out) of the TTL Serial Port through a 100nF capacitor to the RESET pin of the Arduino.
I would also recommend putting the 16U2 into reset, to get it out of the way. Simply place a jumper between ICSP1's RESET2(pin5) and GND(pin6).

Great.  I was thinking of pins 2 and 3 on the 2560 chip - Thanks for pointing  out that's it's D0 and D1 in the Arduino labeling scheme.


text:
How do I install the firmware on an Arduino Mega clone?
I have a brand new board which is a clone of the Mega2560.  I need to install the USB firmware on the 16U2 and the bootloader on the 2650 chip.  I have Atmel Studio and a JTAGICE-3. Using those, I can download HEX files compiled with the Arduino  IDE, and they run successfully.
But I'm having trouble finding Mega-specific instructions for getting the firmware installed so that I can use the Arduino ISP protocol for downloading new sketches. I can find much more information about the Uno than the Mega. And much of the information I do find seems to be dated.
1) Which are the right files to download?
   I've tried to install the 'MEGA-dfu_and_usbserial_combined.hex' to the 16U2 and the 'stk500boot_v2_mega2560.hex' to the 2560.
But the IDE won't connect via AVR ISP, and I get no serial communications from a serial sample sketch downloaded with the ICE.
2) What are the correct Fuse settings after I flash those files?
3) Is there a good way to confirm that the 16U2  USB converter is working correctly in isolation from the 2560 chip?

Let focus on one thing at a time, that is flashing the 16u2. You can see if you've successfully done that when you can see the Arduino in your device-manager.
First of, MEGA-dfu_and_usbserial_combined.hex is, as stated on the github page, for the 8u2, not the 16u2. Since you already have a ISP programmer you don't need the dfu functionality.  You can just flash the precompiled Arduino-usbserial-atmega16u2-Mega2560-Rev3.hex file.
The fuses can also be found in the readme.txt on github: -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0x0F:m. I don't see any difference in the fuses between the 8u2 and 16u2, so they should work for the 16u2 too.
Hope this helps.

Thank you. Is there any reason not to include the DFU?

dfu is needed if you want to reprogram the 16u2 over usb. First you'll probably never have to update it. Second you already have a JTAG programmer, so you can use that one. Thirdly, to get the dfu version for the 16u2 you'll have to compile it yourself, as it isn't present precompiled in the github repository. (And it needs LUFA to compile). So in short, it's just not worth the trouble.


text:
How many total digital pin outs does the Arduino Yun have
I have read the details on the products page for Arduino Yun but I have also read, on a Arduino forum, that there are only 18 digital pins because of Tx, and Rx. Is this true? I am not worried about the PWM, or analog capabilities of the pins, just purely digital.

According to the official specification, it has 20 digital IO pins which can be used with digitalRead() and digitalWrite() etc.. As is typical on Arduino boards though, pins 0 and 1 also act as serial Rx and Tx (respectively).
You can program it to use them for either purpose.
The information you read might be referring to problems with uploading though. If you have something physically connected to pin 0 and/or 1, then you may have to disconnect it while you do an upload, otherwise it can interfere with the communication between your computer and the microcontroller.
If you're doing a lot of tinkering, then sometimes it's simply easier to avoid using pins 0 and 1 altogether, meaning you'd only have 18 IO pins left.


text:
How come people connect their arduinos to buzzers without any coil protection?
If you connect your arduino to a motor you use this schematic:

However, when it comes to buzzers, which also have a coil, no one protects the circuit:

What the hell is going on? Are these just buzzers "coiless"? How can I find the type of buzzer I have?

That kind of "buzzer" doesn't have a coil.  It is a "Piezo Transducer" and uses a crystal to produce the sound.
When you're using a real speaker and producing sound you are doing it very differently to switching a motor or a relay on and off.  You're generating a much smoother waveform and you don't have the sharp "ON-OFF" that causes a collapse of the magnetic field.  You're actually gradually reducing the power and then reversing it to remove the magnetic field then apply a new one in the opposite direction (if you have wired it right of course).
Also the currents involved in driving a speaker like that are minuscule compared to switching a relay, especially when driven direct from the Arduino.  For louder volumes you will use an amplifier, and that deals with the whole protection within itself since it is designed to drive a speaker.

This picture here states that buzzers have a coil http://1.bp.blogspot.com/-j-B5fWFwJVo/UQTewNIMC7I/AAAAAAAACzA/Y7WLCNIbUGs/s1600/buzzer%20coil.jpg so you are saying that this coil is harmless to arduino?

That is a specific component within a circuit within a stand-alone buzzer.  It is not a coil directly connected to an Arduino.  It is part of an oscillator circuit that drives the piezo transducer and thus is irrelevant to the Arduino.


text:
Can I connect to a DALI network as a master node using an Arduino?
I have googled a lot, and mostly every website you can link me I have already explored, some are outdated and don't work, others aren't clear in their documentation, and use equipment too expensive to run the risk of buying it and it not working.
https://github.com/edinburghhacklab/dali
https://github.com/sde1000/python-dali
https://github.com/krzychb/DimSwitch/blob/master/extras/pictures/PHILIPS-HF-REGULATOR-TOUCH-a-DALI%2018-58w-T8-%201-a-2-LAMPS.pdf
http://microcontrollershop.com/product_info.php?products_id=5384
Moreover, like any free protocol, you have to pay to access the DALI standard.
What can I do to control a network of connected DALI dimmable ballasts?

I have made a simple DALI controller with Arduino Nano. Maybe it will be useful for you. Look here: Simple DALI Controller

This is [almost] a link only answer. Links tend to die over time. If you could expand your answer with a summary of the content of the link then that would be very helpful.

This tutorial is poetry! Amazing! Thanks! Is there a way to have it in PDF or any other offline mean (without the videos for ex.). This should be eternalized!

Hi, can you confirm that these resistors values are correct? How can you drop 12V to those voltages using that resistors? http://prntscr.com/e4guvx

Yes, you are right. It was a mistake. I have corrected. You need 2,2 and 3,3 kOhm resistors.

DOCX version of tutorial


text:
Is this Bluetooth module cool for Arduino?
I am making a basic project that will have 4 or 5 arduino nodes. Each arduino will have a bluetooth module attached. The thing I want is, I want to be able for each one of these arduinos to know the other is present in the room (let's say, 5 meters). For my experience in the cellphone, I don't even have to pair bluetooth devices to know about their presence, as long as they are in visible mode. Since I just need to know their presence, and no exchange of information will ever happen, I probably will never have to pair them right?
For this project I need a bluetooth (BT) module that:
1) Enables me to change the ID of each arduino, so that, even if I use my cellphone to scan for BT devices I will see (Arduino1, Arduino2, etc...) instead of default-factory-names.
2) Enables me to scan around for existing devices every time each X seconds, because I want each arduino to know if the others are in the room.
Will this module do the trick? http://www.ebay.co.uk/itm/Interface-Base-Board-Serial-Transceiver-Bluetooth-Module-For-Arduino-UNO-R3-/111482008102?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item19f4d87226
Later I will probably hang around with batteries so I will want a low power BT module, having the same 2 capabilities mentioned. Will NRF8001 do the trick for me? http://www.nordicsemi.com/eng/Products/Bluetooth-Smart-Bluetooth-low-energy/nRF8001
Thanks!

This is not even remotely an Arduino question, but rather one which belongs on EESE.

From skimming that post, I believe that your linked pcb is not a full bluetooth module (note how there is no bluetooth chip or antenna of any kind). This is simply a "base board," which is why it is so cheap1.
You will need something like this that actually has the components you want.
To answer your questions:

The bluetooth library for arduino sets the discoverale name to ARDUINOBT by default, but that can be changed in the setup() method.
"scan around" is a little ambiguous—AFAIK, bluetooth can only connect to one device at a time, but I'm not sure if that's totally true. You may want to look into using radios instead of BT, as they can communicate more freely with one another, are extremely cheap, and have extensive arduino libraries availible. I'm currently working on a project that uses the nRF24L01, and I'd be happy to answer any questions you have about it.

1: It also has a draw of 6v VCC, which is more than the Uno can output.

Also, I believe this arduino forum post is talking about the same exact boards. Lots of information there if you're interested.

I have the idea that while you are scanning for other devices no connection is being made (correct me if im wrong). In that case I won't even make a connection. I am just interested in the part where you scan for visible devices. Like what you do on your phone: https://motorola-global-eng.custhelp.com/rnt/rnw/img/enduser/wirelesssettingsdroidx2bluetooth.jpg
I am interested in that list which shows the devices that I can connect to (but I won't connect because I only want to know their presence and that list is enough for that).

Ah, sorry I misunderstood. Yeah, I'm pretty sure there's a bluetooth library with functions to get an array of available devices to pair to. You would simply then need to write a sketch to print that array to serial or display it in some way. Check out the various bluetooth libraries people have created for arduino—a quick google search should give you a whole bunch.

The first link is for a breakout board only - it has a placeholder for a BT module, similar to the HC Bluetooth models series, but it is not a complete Bluetooth board (hence the "Interface Base Board" in the product's title). Please do not do that mistake - I did it already :)
For your purposes, it seems that something similar to the cheap HC-05 can satisfy both requirements: You can change the device name, and perform inquiry to scan other Bluetooth devices' MAC address, both using AT commands.
It has low operation voltage (1.8v-3.6v), but it operates as the good-old 2.1 Bluetooth standard, which waste a LOT of energy while running. If power consumption is a prime requirement, you might want to consider the more expensive Bluetooth low energy, such as a breakout board for the chip you suggested (the NRF8001).

Should've been a comment, but...
First of all, your questions 1 and 2: yes, that can be done.
I'd go for a HC-05 just like Omer suggests. And if you want to pair them, it is perfectly possible to pair one master with several slaves. Depending on implementation, a slave can connect to several masters too. The HC-05 can switch between these modes.
You can't do it with a NRF8001, as this is a BLE slave device only, it won't do scanning. Try to find a device that can do both, like BLE mini.
You can't mix BLE and Bluetooth devices for this, it's either or.


text:
What is the difference between declaring a variable outside of loop and declaring static inside loop?
These are two ways I can hold a variable outside of loop (or any function).
First, I can declare it with global scope outside of loop:
void setup()
{
    Serial.begin(9600);
}

int count = 0;

void loop()
{
    Serial.println(count);
    count++;

    delay(250);
}

I can also declare it static inside the loop:
void setup()
{
    Serial.begin(9600);
}

void loop()
{
    static int count = 0;

    Serial.println(count);
    count++;

    delay(250);
}

What difference, if any, will this make?

The most basic difference is of scope.
In the first case, you are declaring a global variable. It is a variable that is accessible in every scope after its definition.
void setup()
{
    Serial.begin(9600);
}

void inc();
int count = 0;

void loop()
{
    Serial.println(count);
    count++;

    inc();

    delay(500);
}

void inc() //Can edit the value of count
{
  count=count+1;
};

In the second case, you are declaring a static variable with local scope. The variable will persist for the entire program run similar to global variables, but will be accessible only in the code block it is declared in. This is the same example, with only one change. count is now declared as a static variable inside loop.
void inc();

void loop()
{
    static int count = 0;
    Serial.println(count);
    count++;

    inc();

    delay(500);
}

This will not compile as the function inc() does not have access to count.
Global variables, however seemingly useful, come with some pitfalls. These can even cause damage when it comes to writing programs that can interact with the physical surroundings. This a very basic example of something that is quite likely to happen, as soon as programs start getting larger. A function may inadvertently change the state of a global variable.
void setup()
{
    Serial.begin(9600);
}
void another_function();
int state=0;

void loop()
{
    //Keep toggling the state
    Serial.println(state);
    delay(250);
    state=state?0:1;

    //Some unrelated function call
    another_function();
}

void another_function()
{
  //Inadvertently changes state
  state=1;

}

Such cases are very hard to debug. This type of problem however, can easily be detected, by simply using a static variable.
void setup()
{
    Serial.begin(9600);
}
void another_function();

void loop()
{
    static int state=0;

    //Keep toggling the state
    Serial.println(state);
    delay(250);
    state=state?0:1;

    //Some unrelated function call
    another_function();
}

void another_function()
{
  //Results in a compile time error. Saves time.
  state=1;

}

From a functional perspective, both versions generate the same result, since in both cases the value of count is stored between the executions of the loop() (either because it is a global variable or because it is marked as static and therefore keeps its value).
So the decision which to choose come down to following arguments:

Generally, in computer science, it is encouraged to keep your variables as local as possible in terms of scope. This usually results in much clearer code with less side-effects and reduces chances of someone else using that global variable screwing up your logic. E.g. in your first example, other logic areas might change the count value, whereas in the second, only that particular function loop() can do so.
Global and static variables always occupy memory, where as locals only do when they are in scope. In your above examples that makes no difference (since in one you use a global, in the other a static variable), but in bigger and more complex programs it might and you could save memory using non-static locals.
However: If you have a variable in a logic area that is executed very often, consider making it either static or global, since
otherwise you loose a tiny bit of performance each time that logic
area is entered, since it takes a bit of time to allocate the memory
for that new variable instance. You need to find a balance between memory load and performance.
Other points such as better layout for static analysis or optimization by the compiler might also come into play.
In some special scenarios, there might be issues with the unpredictable initialization order of static elements (not sure about that point, compare this link though).

Source: Similar thread on arduino.cc

Re-entrancy should never be an issue on Arduino since it doesn't support concurrency.

True. That was more of a general point, but indeed not relevant for Arduino. I removed that bit.

A static variable declared inside a scope will always exist and use the same space as a global variable! In the OP code, the only difference is what code can access the variable. In scipe static wil be accessible within the same scope.

@jfpoilpret That of course is true, and I see that the respective part in my answer was a bit misleading. Fixed that.

Both variables are static - they persist for the entire execution session. The global is visible to any function if it declares - not defines - the global, or if the function follows the definition in the same compilation unit (file + includes).
Moving the definition of count to inside of a function both limits its scope of visibility to the nearest enclosing set of {}es, and gives it function invocation lifetime (it is created and destroyed as the function is entered and exited). Declaring it static as well gives it execution session lifetime it exists from the start to the end of the execution session, persisting across function invocations.
BTW: be cautious about using initialized statics within a function, as I have seen some versions of the gnu compiler get this wrong. An automatic variable with an initializer should be created and initialized on every function entry. A static with an initializer should only be initialized once, during the execution setup, before main() is given control (just as a global would be). I have had local statics get reinitialized on each function entry as though they were automatics, which is incorrect. Test your own compiler to be sure.

I'm not sure I understand what you mean about a function declaring a global. Do you mean as an extern?

@PeterR.Bloomfield: I'm not sure what part of my post your asking about, but I was referring to the OP's two examples - the first, an inherently global definition and the second, a local static.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
What design patterns can I use to handle user input and display updating?
I've used enough products with embedded microcontrollers and unresponsive UIs to know that it can make or break a product. Even a slight delay or lag between the button presses and the display updating, or button presses being ignored or double counted, can be extremely frustrating.
What design patterns can be used to deal with user input (from buttons) and updating displays without causing these issues?
I currently use the following kind of pattern (this is simplified down to the bare minimum):
#include <Bounce.h>

#define GREEN_LED       6 // Pin for green LED

#define BUTTON_PIN      15 // Pin for button - uses external pull down so active high

#define DISPLAY_REFRESH_INT 100 // How many MS between display updates

Bounce button = Bounce(BUTTON_PIN, 5);

// To signal between the button read and the display update
bool ledState = false;

// Used to keep track of last display update
long displayUpdate = 0;

void setup()
{
    pinMode(GREEN_LED, OUTPUT);
    pinMode(BUTTON_PIN, INPUT);
}

void loop()
{
    // Read the button status
    if (button.update())
    {
        if (button.risingEdge())
        {
            ledState = !ledState;
        }
    }

    // Update the display periodically
    if (millis() - displayUpdate > DISPLAY_REFRESH_INT)
    {
        displayUpdate = millis();

        digitalWrite(GREEN_LED, ledState);
    }

}

What other options are there? Is it ever worth using pin change interrupts to read buttons (if we are not considering battery life!).

The answer depends on exactly how the sketch is meant to respond to the user interaction.
External interrupts
If the interaction depends on responding very accurately to the rising or falling edge of an input event (as in your example), then an external interrupt may be the way to go, if possible.
This is particularly important if the input event might be shorter that the duration of a call to loop(). If that happens, consecutive attempts to poll the input could completely miss the state change. It's quite rare for a user input event to be that short though, unless loop() is quite slow to execute.
External hardware to get help that though, e.g. by having an input which latches until it is read and reset by the microcontroller.
Improving polling frequency
External interrupts often aren't possible (e.g. because the chip only supports a limited number), or they are simply overkill/unnecessary for a given application.
In those cases, it may still be possible to improve the timing precision when using polling. One option is to split up all the different parts of the main loop into separate functions. On each successive iteration of loop(), it will call the next function, and then wrap round to the first. In between each of those functions, it can poll the button. Here's a simple example:
unsigned int g_section = 0;

void setup() { }

void pollButton()
{
    //...
}

void runSection0()
{
    //...
}

void runSection1()
{
    //...
}

void runSection2()
{
    //...
}

void loop()
{
    // Poll the button on every pass:
    pollButton();

    // Execute the next section of the main code:
    switch (g_section)
    {
    case 0: runSection0(); break;
    case 1: runSection1(); break;
    case 2: runSection2(); break;
    }

    // On the next iteration, run the next section:
    if (++g_section > 2) g_section = 0;
}

One important issue with this approach is that it's very difficult to make each of those runSectionX() functions take the same execution time. That can result in the button being polled inconsistently from one iteration to the next. If it's fast enough though, then it shouldn't be too big of a problem.
Display update
Updating a display is unfortunately often quite slow, compared to many other operations. That means you need to be quite careful where you do it. Inside an Interrupt Service Routine often wouldn't be appropriate, as that could introduce other timing issues in your sketch.
Realistically, you'd have to do it in the main loop. If you absolutely have to run it quickly though, then it can be included in the faster polling example I've given above -- i.e. update the display on every iteration, the same as polling. You have to be careful to avoid partial updates though.

This is a great answer by the way. Exactly the kind of answer the site needs.

For program control, I made something of a menu handling framework for one of my projects and shared the source on Github. Note that this is for chipKIT but the menu handling code is generic. After building my 3rd or 4th huge if-else-if and switch structure, I decided there had to be a better way. Credit for the source of the static menu structures.
I just use the main loop to check the button.
I'm wanting to say the first step is to get a TFT. If you try it, you'll never go back... I particularly love the Adafruit 1.8" TFT with joystick. Arduinos are slow enough that I cannot recall caring to debounce user input.

I like the way you've done that - it's understandable, clean, and very small in size. I had been looking at using a library (MenuBackend) but it is hard to understand for new programmers (using callbacks) and can't sit in PROGMEM.

I find debounce often isn't required, but some switches seem to be much noisier than others. The upright, edge mounted PCB tactile switches seem the worst by far, maybe because instead of pressing, users often lever these forwards. Debouncing is so easy that I nearly always do it now.

Sorry for all the questions - why a TFT? I'm currently working with a 128x64 LCD which has a lot of benefits (mainly being physically large). Also cheap.

@Cybergibbons ah, didn't see any mention of a display. The one I like is a ready made shield, cheap enough, and you can do things with colors. Here's a build report of my most recent project: http://forums.adafruit.com/viewtopic.php?f=22&t=44710&p=223543#p223543

You could interrupt instead of polling if you can de-bounce the buttons in hardware. Otherwise you'll be take many more interrupts than there were button presses and still have to de-bounce them in software.
But to the primary question, a collection of state machines can be very useful, at least for the ui, and give you most of the benefits of multi-tasking without needed a m/t kernel.  can be  in RAM limited devices, unfortunately, because
The technique could be especially useful on these small devices but for the severe limits on RAM, making it something of a challenge to divide your state-machine data between flash and RAM, to fit.

As Chris K i've also implemented a static menu library with a wide variety of output options like Serial,LCD,TFT, etc..
I've started it to help in a friends project and I'm also sharing it open source for people that with similar problems, hope you can find it useful.
https://github.com/neu-rah/ArduinoMenu


text:
What is the smallest microcontroller capable of running Arduino?
I'd like to know which is the most powerful, lightest, and perhaps least expensive micro controller capable of running Arduino.

Each of those criteria has a different answer.

Is there not one that meets all the criteria above in some capacity better than others? If not, could you please provide a standout microcontroller for each of the listed criteria? Thanks.

There are so many that it's impossible to give a good recommendation based on such general criteria. Perhaps you could describe what you need the microcontroller for? Is it for a specific project, or just general tinkering?

I want to build a micro quadcopter drone

You'll need some idea of the I/O requirements, calculation load, and RAM requirements for controlling your drone, before you can select a processor to meet thme. Cook your design a bit more. Is this an R/C drone? Autonomous? Does it need on board navigation? Stability augmentation? Must it find it's own way home? Manage it's fuel/flight duration? Yesses to some of these questions will have strong implications for the processor you'll need.

Well, your questions is quite vague and perhaps overly broad.  I'll answer your main question "what is the smallest," assuming you meant dimensionally, while keeping in mind that you also want the most powerful one in that size. The pricing of different chips like this will be fairly similar so I'll ignore that.
Next, I'm not sure what you meant by saying "capable of running Arduino" which may mean capable of having the Arduino bootloader installed or could mean being capable of running code written with Arduino libraries.  I'll assume the latter since it's the most practical requirement. I'll also assume you want an Atmel chip since it will be the most directly compatible with the Arduino libraries.
So what is the most powerful of the smallest Atmel microcontrollers capable of running Arduino code?
The answer is probably the Attiny 10 which comes in a 2 x 2mm 8-UFDFN Exposed Pad package, or a 2.9 x 1.6mm SOT-23-6 package for about one dollar in small quantities.
Also see this Hackaday article on how to use the Attiny10 with Arduino.
Edit: After more research, I was unable to find an Arduino core for the Tiny10. So while you can program it with an Arduino using assembly or something, writing Arduino code for it won't work.  The smallest Attiny with an Arduino core I could easily find is the Attiny13 in a 3 x 3mm 10-VFDFN package.  The upside is that while not being that much bigger or more expensive, it's a way more capable chip for your project.

There is no Arduino core for the 4/5/9/10; they're just too small for it to be practical.


text:
Function call only works if called once
I have 3 LED chains which are all mapped to concentric rings. Each ring has a its own 2D array with the chain number & LED number. I have a function that is passed a ring array and then lights the appropriate LED. I'm using FastLED
void lightUp(int ring_arr[][2], int i, int col){

  if(ring_arr[i][0] == 0){
      L0[ring_arr[i][1]] = CHSV(col, 255, 255);
    }
    if(ring_arr[i][0] == 1){
      L1[ring_arr[i][1]] = CHSV(col, 255, 255);
    }
    if(ring_arr[i][0] == 2){
      L2[ring_arr[i][1]] = CHSV(col, 255, 255);
  }
}

This works fine BUT only if its called once in loop() if I make a 2nd call none of the LEDs light up. So I can light up 1 ring at a time but if I try to light up 2 or more then nothing lights up. Anyone see anything obvious that I'm overlooking?
The full code listing,
#include <FastLED.h>

#define NELEMS(x)  (sizeof(x) / sizeof((x)[0]))
#define DATA_0 5
#define DATA_1 6
#define DATA_2 7
#define NUM_LEDS 50

CRGB L0[NUM_LEDS];
CRGB L1[NUM_LEDS];
CRGB L2[NUM_LEDS];

// Rings
int ring_1[][2] = {{0,0}, {0,1},  {0,2},  {0,3},  {1,49},
                   {1,28}, {1,29}, {1,30}, {1,31}, {1,32},
                   {1,23}, {1,24}, {1,25}, {1,26}, {1,27},
                   {1,2},  {1,3},  {1,4},  {1,5},  {1,6},
                   {1,0},  {1,1},  {2,0},  {2,1},  {2,2},
                   {2,19}, {2,20}, {2,21}, {2,22}, {2,23},
                   {2,24}, {2,25}, {2,26}, {2,27}, {2,28},
                   {2,45}, {2,46}, {2,47}, {2,48}, {2,49},
                   {0,29}, {0,28}, {0,27}, {0,26}, {0,25},
                   {0,4},  {0,5},  {0,6},  {0,7},  {0,8}};

int ring_2[][2] = {{1,48}, {1,33}, {1,22}, {1,7},  {2,3},
                   {2,18}, {2,29}, {2,44}, {0,24}, {0,9}};

int ring_3[][2] = {{1,47}, {1,34}, {1,21}, {1,8},  {2,4},
                   {2,17}, {2,30}, {2,43}, {0,23}, {0,10}};

int ring_4[][2] = {{1,46}, {1,35}, {1,20}, {1,9}, {2,5},
                   {2,16}, {2,31}, {2,42}, {0,22}, {0,11}};

int ring_5[][2] = {{1,45}, {1,36}, {1,19}, {1,10}, {2,6},
                   {2,15}, {2,32}, {2,41}, {0,21}, {0,12}};

int ring_6[][2] = {{1,44}, {1,37}, {1,18}, {1,11}, {2,7},
                   {2,14}, {2,33}, {2,40}, {0,20}, {0,13}};

int ring_7[][2] = {{1,43}, {1,38}, {1,17}, {1,12}, {2,8},
                   {2,13}, {2,34}, {2,39}, {0,19}, {0,14}};

int ring_8[][2] = {{1,42}, {1,39}, {1,16}, {1,13}, {2,9},
                   {2,12}, {2,35}, {2,38}, {0,18}, {0,15}};

int ring_9[][2] = {{1,41}, {1,40}, {1,15}, {1,14}, {2,10},
                   {2,11}, {2,36}, {2,37}, {0,17}, {0,16}};
// Colours
int col_1 = 0;
int col_2 = 160;
int col_3 = 96;

void setup(){

   // LED set up
   FastLED.addLeds<WS2811,DATA_0,RGB>(L0, NUM_LEDS);
   FastLED.addLeds<WS2811,DATA_1,RGB>(L1, NUM_LEDS);
   FastLED.addLeds<WS2811,DATA_2,RGB>(L2, NUM_LEDS);
   FastLED.setBrightness(255);
   clearAll();
}

void loop()
{

  for(int i; i < NELEMS(ring_1); i++){
    lightUp(ring_1, i, col_1);
  }

  for(int i; i < NELEMS(ring_2); i++){

//    lightUp(ring_2, i, col_2); // if I uncomment any of these
//    lightUp(ring_3, i, col_3); // no LEDs light up
//    lightUp(ring_4, i, col_1);
//    lightUp(ring_5, i, col_2);
//    lightUp(ring_6, i, col_3);
//    lightUp(ring_7, i, col_1);
//    lightUp(ring_8, i, col_2);
//    lightUp(ring_9, i, col_3);

  }

  FastLED.show();
  delay(1000);
}

void clearAll(){
  for(int i; i < NUM_LEDS; i++){
    L0[i] = CHSV(0, 0, 0);
    L1[i] = CHSV(0, 0, 0);
    L2[i] = CHSV(0, 0, 0);
  }
  FastLED.show();
}

void lightUp(int ring_arr[][2], int i, int col){

  if(ring_arr[i][0] == 0){
      L0[ring_arr[i][1]] = CHSV(col, 255, 255);
    }
    if(ring_arr[i][0] == 1){
      L1[ring_arr[i][1]] = CHSV(col, 255, 255);
    }
    if(ring_arr[i][0] == 2){
      L2[ring_arr[i][1]] = CHSV(col, 255, 255);
  }
}

what happens if you run the first for loop twice?

@jsotola no LEDs light up

Your for loops are missing an initialization. You should write
for (int i = 0; i < NELEMS(ring_1); i++)

but you missed the = 0 part. This means the i variable ends up
uninitialized, and contains whatever was left in this memory location by
whatever used that memory before. The behavior in such situation is
generally unpredictable. However, one may guess that the i of the
second loop could be allocated in the same spot as the i of the first
loop. If this happens, then the second loop starts at i=3 and ends up
being an empty loop.
As a (completely unrelated) side note, you could gather your three L*
arrays into a single 2D array. This would make lightUp() significantly
simpler:
void lightUp(int ring_arr[][2], int i, int col) {
    L[ring_arr[i][0]][ring_arr[i][1]] = CHSV(col, 255, 255);
}

or maybe it would be clearer like this:
void lightUp(int *location, int col) {
    L[location[0]][location[1]] = CHSV(col, 255, 255);
}

To be called as lightUp(ring_1[i], col_1);.

Let this be a lesson for people who flit between Python & C++ too often. Also why did the question get a downvote?

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Replicate output of pwm pin on another output pin?
Ardiuno Mega 2560
I have a legacy PCB that connects PORTA, pins = {22, 23, 24, 25, 26, 27, 28, 29} to the PWM input of a set of actuators. The accompanying code made use of an interupt service routine to generate PWM signals. This in turn caused all sorts of other problems for the system.
So, I would like to leverage the Mega's internal counters & use the PWM available on pins = {2, 3, 4, 5, 6, 7, 8, 9} & use the analogWrite() function. At present there is nothing else connected to these pins but access is limited.
Before I go down the route of redesigning the PCB I was wondering if it was possible to replicate the outputs of pins {2, 3, 4, 5, 6, 7, 8, 9} to pins {22, 23, 24, 25, 26, 27, 28, 29}?

It is not clear, what you are trying to achieve. What I understood is: You want do measure the value of the PWM signal on the pins {22, 23, 24, 25, 26, 27, 28, 29} and then outputting a new PWM signal with the same value on the pins {2, 3, 4, 5, 6, 7, 8, 9}. Is that correct?

I want to generate the PWM on pins {2, 3, 4, 5, 6, 7, 8, 9} using analogWrite() but replicate that output on pins {22, 23, 24, 25, 26, 27, 28, 29}

It is not possible to route pins to other pins, the functionality of a pin is fixed to that pin. You could try a software pwm library.

Is there a reason, why you want the same PWM signal on more than 1 pin? Why don't you just connect the one pin to both targets?

as mentioned in the orginal post the issue is to do with a legacy PCB. I'm just soundng out options before I have to redesign anything

Internally, it's not possible. If pins 22 through 29 are not used for anything else, soldering jumper wires onto a spacer or directly onto the PCB might be an option.
Otherwise, as @Jot suggested, software PWM is always an option, but they achievable frequency would be limited.

As Jot wrote, you cannot simply route a signal from pin to pin inside the chip/Arduino. So - unless you redesign the PCP, which would be the cleanest way, or use jumper wires, which is not so clean - you are down to using software PWM. There are also libraries for this, if you don't want to write this yourself, for example the SoftPWM library. These libraries have their own limits, especially in frequency. Be sure to check, if they fit your needs.

will check out the linked library tomorrow thanks. Is there any reason you can think of why I couldnt hard wire the pins together?

You can. This is only about how clean the solution would be. Of course it is best to have a PCB thats designed for it. Connecting the pins with jumper wires is a bit less clean, but will work well (as long, as you don't need these pins for other purposes)


text:
Sending variable length sequence via serial from PC to Mega
I am trying to send a sequence of commands from a PC to a Mega. The Mega in turn controls 2 signal generators (AD9833's).
The sequences can vary in length but always have the same format:

A start byte of 255
The length of the sequence
Elements of the sequence: Channel 0: MSB, LSB & waveform, Channel 1: MSB, LSB & waveform

The PC side code:
import serial
import struct

usbport    = 'COM3'
ser        = serial.Serial(usbport, 9600, timeout=1)

def sendSequence(seq):

    ''' Send a sequence of frequencies along with waveform '''

    # Start byte & sequence length
    ser.write(struct.pack('>B', 255))
    ser.write(struct.pack('>B', len(seq)))

    for s in seq:

        print(s)
        MSB, LSB = (s[0] & 0xFFFF).to_bytes(2, 'big')     # Split frequency to send
        ser.write(struct.pack('>B', MSB))
        ser.write(struct.pack('>B', LSB))
        ser.write(struct.pack('>B', s[1]))                # Waveform

        combined = ((MSB & 0xFF) << 8) | (LSB & 0xFF)
        print(combined)

sendSequence([[1000, 0], [1000, 0], [2000, 0], [1000, 0], [2000, 0], [2000, 0]])
ser.close()

On the Arduino side:
#include <SPI.h>

// Set up Serial data variables
byte freq_MSB;
byte freq_LSB;
int startbyte;
unsigned long freq_seq_ch_0[16];
int wave_seq_ch_0[16];
unsigned long freq_seq_ch_1[16];
int wave_seq_ch_1[16];
int wave_select = 0;
int seq_length;
long f_2;
long f_1;

const int SINE     = 0x2000;                // Define AD9833's waveform register value.
const int SQUARE   = 0x2028;                // When we update the frequency, we need to
const int TRIANGLE = 0x2002;                // define the waveform when we end writing.
int wave           = SINE;

const float refFreq = 25000000.0;           // On-board crystal reference frequency

const int FSYNCA = 53;                       // Standard SPI pins for the AD9833 waveform generator.
const int FSYNCB = 49;
const int CLK    = 52;

unsigned long pause     = 5000;
unsigned long freq      = 1000;              // Set initial frequency.
int i;

void setup() {

  // Set slave ocntrol pins
  pinMode(FSYNCA, OUTPUT);
  pinMode(FSYNCB, OUTPUT);
  digitalWrite(FSYNCA, HIGH);
  digitalWrite(FSYNCB, HIGH);

  // Set up SPI
  SPI.begin();
  SPI.setDataMode(SPI_MODE2);
  delay(50);

  // Set up AD9833s
  AD9833reset();                                   // Reset AD9833 module after power-up.
  delay(50);
  AD9833setFrequency(freq, SINE, FSYNCA);          // Set the frequency and Sine Wave output
  AD9833setFrequency(freq, SINE, FSYNCB);

  // Open the serial connection, 9600 baud
  Serial.begin(9600);
}

void loop() {

   // Wait for serial input
  if (Serial.available()) {

    startbyte = Serial.read();              // Read the first byte
    if (startbyte == 255) {
      seq_length = Serial.read();

      for (i = 0; i < seq_length; i++) {

        // Channel 0
        freq_MSB = Serial.read();
        freq_LSB = Serial.read();
        f_2 = (long)freq_MSB << 8;
        f_1 = (long)freq_LSB;
        freq_seq_ch_0[i] = f_2 | f_1;
        wave_select = Serial.read();
        switch (wave_select) {
          case 0:
            wave_seq_ch_0[i] = SINE;
            break;
          case 1:
            wave_seq_ch_0[i] = TRIANGLE;
            break;
          case 2:
            wave_seq_ch_0[i] = SQUARE;
            break;
          }

        // Channel 1
        freq_MSB = Serial.read();
        freq_LSB = Serial.read();
        f_2 = (long)freq_MSB << 8;
        f_1 = (long)freq_LSB;
        freq_seq_ch_1[i] = f_2 | f_1;
        wave_select = Serial.read();
        switch (wave_select) {
          case 0:
            wave_seq_ch_1[i] = SINE;
            break;
          case 1:
            wave_seq_ch_1[i] = TRIANGLE;
            break;
          case 2:
            wave_seq_ch_1[i] = SQUARE;
            break;
          }
      }

      // Send sequence to signal generators
      for (i = 0; i < seq_length; i++) {
        AD9833setFrequency(freq_seq_ch_0[i], wave_seq_ch_0[i], FSYNCA);
        AD9833setFrequency(freq_seq_ch_1[i], wave_seq_ch_1[i], FSYNCB);
        delay(3000);
      }

    }

  }
}

// AD9833 documentation advises a 'Reset' on first applying power.
void AD9833reset() {
  WriteRegister(0x100, FSYNCA);   // Write '1' to AD9833 Control register bit D8.
  delay(10);
  WriteRegister(0x100, FSYNCB);
  delay(10);
}

// Set the frequency and waveform registers in the AD9833.
void AD9833setFrequency(long frequency, int Waveform, int channel) {

  long FreqWord = (frequency * pow(2, 28)) / refFreq;

  int MSB = (int)((FreqWord & 0xFFFC000) >> 14);    //Only lower 14 bits are used for data
  int LSB = (int)(FreqWord & 0x3FFF);

  //Set control bits 15 ande 14 to 0 and 1, respectively, for frequency register 0
  LSB |= 0x4000;
  MSB |= 0x4000;

  WriteRegister(0x2100, channel);
  WriteRegister(LSB, channel);                  // Write lower 16 bits to AD9833 registers
  WriteRegister(MSB, channel);                  // Write upper 16 bits to AD9833 registers.
  WriteRegister(0xC000, channel);               // Phase register
  WriteRegister(Waveform, channel);             // Exit & Reset to SINE, SQUARE or TRIANGLE

}

void WriteRegister(int dat, int channel) {

  // Display and AD9833 use different SPI MODES so it has to be set for the AD9833 here.
  //SPI.setDataMode(SPI_MODE2);

  digitalWrite(channel, LOW);           // Set FSYNC low before writing to AD9833 registers
  delayMicroseconds(10);              // Give AD9833 time to get ready to receive data.

  SPI.transfer(highByte(dat));        // Each AD9833 register is 32 bits wide and each 16
  SPI.transfer(lowByte(dat));         // bits has to be transferred as 2 x 8-bit bytes.

  digitalWrite(channel, HIGH);          //Write done. Set FSYNC high
}

My problem is that this does NOTHING. No matter what sequence I send the output of the signal generators never deviates from the set up defaults.
The generators do work & I have managed to control them via serial before but in that case I knew exactly how much information would be in the serial buffer before I read it in but in this case the sequence length isn't known a priori.
Is this a serial issue?

Are you waiting after opening the serial port in Python for the Arduino to reboot and run pass the bootloader before sending data?

@Majenko I have added sleep(1.0) to the Python code after opening up the serial comms but I still get nothing

OK upped that to 10 seconds & hey presto! it worked!

The main issue here is, that you are reading data, that might not be received yet. This:
if (Serial.available()) {

will check if there is any data in the Serial buffer. As the code runs rather fast and communication over Serial at 9600 baud is relatively slow, this very well might be true, when not your complete message was received. So you might have received the start byte, but the rest of the data is still being transmitted. In that case Serial.read() will return -1.
With Serial (UART) the transmission happens with individual bytes, not in big chucks. You need to only read data, that is really received.
As you don't know the sequence length beforehand I would suggest 2 different ways:

You can wait for 2 bytes being in the Serial buffer (start byte and length) and then again wait, until enough further bytes are in the Serial buffer (as you now have the length of the sequence).

You can rebuild your code, so that it just places the data in an extra buffer, until you have received enough data (which you need to check via the received length byte). Then, when you have received the full message, you process it and then clear the buffer, waiting for a new message.

OK so I've added if (Serial.available > 1) then added while (Serial.available < seq_length*3){} but its still doing nothing.


text:
Confusing stepper reaction to increase in delayMicroseconds()
I have been following this tutorial using the same hardware, TB6600 driver, 42HS48-1704A (yes I think its supposed to be 42hs40 but thats not what it says the sticker) stepper but am controlling via a Nano.
The code,
const int stepPin = 5;
const int dirPin = 2;
const int enPin = 8;

int num_steps = 200;
int dt = 1000;

void setup() {

  pinMode(stepPin, OUTPUT);
  pinMode(dirPin, OUTPUT);
  pinMode(enPin, OUTPUT);
  digitalWrite(enPin, LOW);

}

void loop() {

  digitalWrite(dirPin, HIGH); // Enables the motor to move in a particular direction

  for(int x = 0; x < num_steps; x++) {

    digitalWrite(stepPin, HIGH);
    delayMicroseconds(dt);
    digitalWrite(stepPin, LOW);
    delayMicroseconds(dt);

  }

  delay(1000); // One second delay
  digitalWrite(dirPin, LOW); //Changes the direction of rotation

  for(int x = 0; x < num_steps; x++) {

    digitalWrite(stepPin, HIGH);
    delayMicroseconds(dt);
    digitalWrite(stepPin, LOW);
    delayMicroseconds(dt);

  }

  delay(1000);
}

I added dt so I could control the step speed but its not behaving as I thought it would.
The original code has dt = 500 which needed 15V to run & runs not quite chunky movement but bordering on it & just over 1 revolution when num_steps = 2000
I changed to dt = 1000 & now its got really smooth faster motion & doing quite a few revolutions (too fast for me to count with my eyes) but if reduce num_steps = 200 that results in 1 revolution & now only needs 9V to run.
So, how come when I increase the delay it runs faster? Is this some kind of clocking/synching issue?

With dt = 500 you get one step per millisecond. This is probably too fast for the motor/driver combination. When the driver tries to execute another step, while the previous is not fully executed by the motor shaft (which needs some time due to the shafts inertia), the magnets will misalign and the coil current of the current step will not result in a proper rotation of the shaft. Some of the pulses are aligned enough to the motor shaft position just by chance and can result in a correct step. So the motor skips some of the pulses due to its inertia. Increasing the voltage will increase the force of the motor coils, which drive the shaft. Thus it can overcome the described problems easier (the shaft moving faster by the force of one pulse than before)
Increasing to dt = 1000 gives the motor enough time to follow each step. You aren't loosing steps because the magnets and coils in the motor always align correctly.


text:
Stepper motor shield compatibilty question
I recently bought Adafruit's motor shield v2 only to find out it can only support upto 12v.
So I'm on the look out for another shield & found this one
Arduino Dual L6470 Stepper Motor Shield
I have an Arduino Mega & the documentation says it is fully compatible with the UNO.
Will there an issue using this shield with a Mega? Or if anyone else can point me at a decent stepper controller?

That is an SPI based device, and it doesn't use the (now considered standard) 6-pin ICSP header for SPI.
Therefore it will only directly work on boards that have the SPI pins available on pins 10-13 of the digital headers.
To use it with other boards you will need to manually route the SPI pins to the right places using wires.

Just so you know, the L6470 is a pretty sophisticated and high-performance driver with lots of options to tweak, but it is a voltage-mode driver that requires some tuning for best results (otherwise, expect to generate some heat). There is a separate ST microelectronics application note, not mentioned in the L6470 datasheet, that describes some tuning guidelines - but it's written for an engineering audience.
There is also a SparkFun version of the L6470 out there.


text:
Multiple peripherals using SPI with a Mega
I am using a Mega 2560 and 2 x AD9833 programmable waveform generators.
The AD9833's use a SPI protocol and I have used vwlowen's code as a jumping off point (I'm not usng the display just the generators). I added a channel variable to select the slave device.
It all works fine until I try to add a second AD9833. I saw this post about more than 1 peripheral using SPI & a Mega, that says I can use any pin for slave selection (SS) but the following code only ever works if I use pin 53. The upshot if which is that I can send the same data to both i.e. both share the same SS pin as long as that pin is 53. Any other SS pin selection is ignored by the devices. I tried pin 49 for both & no change, I''ve tried 53 & 49 yet only the device on 53 changes.
So what's going on here? What's so special about pin 53 that it cant be replicated by another output pin?
/*
Amended code for AD9833 Waveform Module originally from vwlowen.co.uk
Common SPI terminology & pinout on AD9833
MOSI - DATA
SCLK - CLK
SS   - FSYNC
MISO - not implemented i.e. ther is no MISO pin on the AS9833
*/

#include <SPI.h>

const int SINE     = 0x2000;                // Define AD9833's waveform register value.
const int SQUARE   = 0x2028;                // When we update the frequency, we need to
const int TRIANGLE = 0x2002;                // define the waveform when we end writing.

const float refFreq = 25000000.0;           // On-board crystal reference frequency

const int FSYNCA = 53;                       // Standard SPI pins for the AD9833 waveform generator.
//const int FSYNCB = 49;
const int CLK    = 52;                       // CLK and DATA pins.
const int DATA   = 51;

unsigned long freq = 1000;                   // Set initial frequency.

void setup() {

  pinMode(FSYNCA, OUTPUT);
  // pinMode(FSYNCB, OUTPUT);

  SPI.begin();
  SPI.setDataMode(SPI_MODE2);
  delay(50);

  AD9833reset();                                   // Reset AD9833 module after power-up.
  delay(50);
  AD9833setFrequency(freq, SQUARE, FSYNCA);        // Set the frequency and Sine Wave output
 // AD9833setFrequency(freq, SINE, FSYNCB);

}

void loop() {

// TODO: PC control via USB

}

// AD9833 documentation advises a 'Reset' on first applying power.
void AD9833reset() {
  WriteRegister(0x100, FSYNCA);   // Write '1' to AD9833 Control register bit D8.
  delay(10);
 // WriteRegister(0x100, FSYNCB);
 // delay(10);
}

// Set the frequency and waveform registers in the AD9833.
void AD9833setFrequency(long frequency, int Waveform, int channel) {

  long FreqWord = (frequency * pow(2, 28)) / refFreq;

  int MSB = (int)((FreqWord & 0xFFFC000) >> 14);    //Only lower 14 bits are used for data
  int LSB = (int)(FreqWord & 0x3FFF);

  //Set control bits 15 ande 14 to 0 and 1, respectively, for frequency register 0
  LSB |= 0x4000;
  MSB |= 0x4000;

  WriteRegister(0x2100, channel);
  WriteRegister(LSB, channel);                  // Write lower 16 bits to AD9833 registers
  WriteRegister(MSB, channel);                  // Write upper 16 bits to AD9833 registers.
  WriteRegister(0xC000, channel);               // Phase register
  WriteRegister(Waveform, channel);             // Exit & Reset to SINE, SQUARE or TRIANGLE

}

void WriteRegister(int dat, int channel) {

  digitalWrite(channel, LOW);         // Set FSYNC low before writing to AD9833 registers
  delayMicroseconds(10);              // Give AD9833 time to get ready to receive data.

  SPI.transfer(highByte(dat));        // Each AD9833 register is 32 bits wide and each 16
  SPI.transfer(lowByte(dat));         // bits has to be transferred as 2 x 8-bit bytes.

  digitalWrite(channel, HIGH);        //Write done. Set FSYNC high
}

What's so special about pin 53

Pin 53 is the slave select pin of the SPI peripheral. As such it has a bearing on how the SPI peripheral operates.
It is intimately tied to the master/slave operation in that when it's an input SPI works in slave mode, and when it's an output it runs in master mode.
So to use SPI in master mode, whether you use pin 53 or not, it must be in OUTPUT for SPI to work at all.
There is nothing much wrong with your methodology, but one thing is missing: the initial state of the chip select pins.
You should always start with all chip select pins disabled (i.e., HIGH) rather than in an unknown (probably low - I'd have to check the datasheet) state - the exception might be pin 53 which SPI might itself set HIGH for you.
So if you add:
digitalWrite(FSYNCA, HIGH);
digitalWrite(FSYNCB, HIGH);

right after setting the pinMode for your pins and still use both pins 53 and 49 then it should work.

SPI.begin() sets the SS pin (53) as output and HIGH


text:
Serial monitor when port is being used by another application
I am controlling some LEDs via the USB serial port using a Tkinter/Python3x script to debug what I suspect is a hardware problem.
from tkinter import *
import serial

usbport = 'COM3'
ser = serial.Serial(usbport, 9600, timeout=1)

def init():
    print("Started")

class App:

    def __init__(self, master):

        frame = Frame(master)
        frame.pack()
        self.scale1 = Scale(master, from_=0, to=255, command=lambda ev: self.getBright(1), bd=5, bigincrement=2, length=360, width=30, label='RED')
        self.scale1.set(128)
        self.scale1.pack(side=LEFT)
        self.scale2 = Scale(master, from_=0, to=255, command=lambda ev: self.getBright(2), bd=5, bigincrement=2, length=360, width=30, label='GREEN')
        self.scale2.set(128)
        self.scale2.pack(side=LEFT)
        self.scale3 = Scale(master, from_=0, to=255, command=lambda ev: self.getBright(3), bd=5, bigincrement=2, length=360, width=30, label='BLUE')
        self.scale3.set(128)
        self.scale3.pack(side=LEFT)
        self.centre = Button(frame, text="Centre All", command=self.centre)
        self.centre.pack(side=TOP)

    def getBright(self, slider):

        if slider==1:
            brt = self.scale1.get()

        if slider==2:
            brt = self.scale2.get()

        if slider==3:
            brt = self.scale3.get()

        ser.write(255)
        ser.write(slider)
        ser.write(brt)

    def centre(self):

        for LED in range(0, 4):

            ser.write(255)
            ser.write(LED)
            ser.write(128)

        self.scale1.set(128)
        self.scale2.set(128)
        self.scale3.set(128)

init()
root = Tk()
app = App(root)
root.mainloop()

On the Arduino Mega 2560 side I read in from serial a start byte, LED label & a brightness value...
int user_input[3];
int start_byte;
int LED;           // which LED to pulse? r=1 g=2 b=3
int brightness;
int i;

// LED pins
#define REDPIN 7
#define GREENPIN 8
#define BLUEPIN 9

void setup()
{

  // LED outputs
  pinMode(REDPIN, OUTPUT);
  pinMode(GREENPIN, OUTPUT);
  pinMode(BLUEPIN, OUTPUT);

  Serial.begin(9600);
}

void loop()
{
  if (Serial.available() > 2) {

    start_byte = Serial.read();
    if (start_byte == 255) {

      for (i = 0; i < 2 ; i++) {
        user_input[i] = Serial.read();
      }

      LED = userInput[0];
      brightness = user_input[1];

      switch (LED) {

        case 1:
          analogWrite(REDPIN, brightness);
          break;

        case 2:
          analogWrite(GREENPIN, brightness);
          break;

        case 3:
          analogWrite(BLUEPIN, brightness);
          break;

      }
    }
  }
}

Now I would like to see what is actually being sent via the serial port to the Arduino using the serial monitor (yes I know I can just print the values in the Python terminal that's not what I'm asking).
The problem is that the Arduino Serial Monitor is locked out. I'm guessing this is a Windows thing (Win10 x64)? Has anybody here come across this?

I think this is totally normal. Only one application can use the port at once

Wire USB to Serial adapter to any other hw Serial of the Mega and print there

Serial data can only go to one place at a time. Either your Python program can receive the data, or the Serial Monitor can receive the data. Similarly the serial port can only receive data from one place at a time.
So Windows prevents you doing something invalid by locking you out of the serial port when something else is using it.
This is normal, and entirely desired functionality.
Your simplest option is to just print what you receive in your Python program.

So this is an in built Windows thing then? I have no problem reading a serial port from multiple applications when using Raspbian.

That's because Linux us far more sophisticated than Windows. However, if you open the port multiple times on Linux only one program will receive data. Which one? Impossible to say.

@Majenko "Which one? Impossible to say." Very sophisticated, indeed. ;)

@DataFiddler It depends on many factors. Maybe it will be the last one connected. Maybe the first. Maybe it will be a 50/50 split. I don't know the answer. Some Linux kernel hacker might, but I don't. Personally I use socat on Linux to "tee" the data off and pass it out to another pty device if I need to debug at that sort of level.

@Majenko: Thanks for bringing socat to my attention.


text:
What data type are the analog pin labels (A0, A1, etc)?
Arduino Mega
I would like to have an array containing analog pin labels something like...
int analog_pins[] = {A0, A1, A2, A3};
int num_analog_pins = sizeof(analog_pins) / sizeof(analog_pins[0]);

Is this possible? It has compiled without any warnings or errors but I'm dont have my board with me (yes beginners mistake) so cant really check if it works.

Read the wiki entry, it should give you a good understanding of the sizeof operator. https://en.wikipedia.org/wiki/Sizeof

As you can see in Arduino.h, the analogRead() has uint8_t as parameter. You can define them as byte or uint8_t and you don't have to use the sizeof().
The type of A0 is defined in the file pins_arduino.h:
#define PIN_A0 (14)
static const uint8_t A0 = PIN_A0;

Nevertheless, what you have with integers is 100% okay as well.
When you don't have a Arduino board available, you can use the simulation of an Arduino Uno at Tinkercad.

As @DataFiddler writes below this answer, using a 'const' keyword is preferred:
const uint8_t analog_pins[] = {A0, A1, A2, A3};

const uint8_t analog_pins[] might even be better, eventually allowing for a lot of compiler optimization

Your calculation will be correct for num_analog_pins, however it's convention to use the type of the array like so
int num_analog_pins = sizeof(analog_pins) / sizeof(int);

As @Jot noted, you'd save much space by declaring your array using uint8_t like so
uint8_t analog_pins[] = {A0, A1, A2, A3};
uint8_t num_analog_pins = sizeof(analog_pins) / sizeof(uint8_t);

sizeof(uint8_t) :-) very formal

@Juraj haha indeed!  I've always written such code for portability and clarity.

@RamblinRose You should write uint8_t num_analog_pins = sizeof(analog_pins) / sizeof(analog_pins[0]);

@MarkSmith I'm confused by your comment - sizeof returns the number of bytes allocated for an array, sizeof(array) / sizeof(array_type) = number of array elements.

Apologies, I hadn't seen the denominator there. Comment deleted.


text:
433 MHZ connection between two Arduino (nano,uno) fails after some time
The goal of this part of my project is to establish a wireless connection between an Arduino nano and an Arduino uno. For this I use 433 MHZ receiver and sender. The nano sends, the uno receives and prints. I have working code and the connection works and I can send, receive and print my message.
But at some point the Uno receives just a part of the message and after this point always receives (or prints) just this part of the message:

Nano (sender):
#include <VirtualWire.h>
char *msg = "123456789123456789";

It is not always 2 digits, sometimes more are received.
I searched for errors. The nano is constantly sending and the uno flips to not receiving the whole message. So I reupload the code to the uno without modification and it works again for a few seconds/minutes, so I guess it's a problem at the receiving end.
Here is my code:
Sender(nano):
#include <VirtualWire.h>
char *msg = "123456789123456789"

void setup()   {
 Serial.begin(9600);

 pinMode(7,OUTPUT);
 pinMode(5,OUTPUT);
 digitalWrite(5,LOW); //GND
 pinMode(6,OUTPUT)
 digitalWrite(6,HIGH); //5V
 vw_setup(5000);
 vw_set_tx_pin(7);
}

void loop()     {
 vw_send((uint8_t*)msg, strlen(msg));
 vw_wait_tx();
 delay(500);
}

Receiver(Uno):
#include <VirtualWire.h>

int i;
uint8_t buf[VW_MAX_MESSAGE_LEN];
uint8_t buflen = VW_MAX_MESSAGE_LEN;

void setup() {

 Serial.begin(9600);
 pinMode(5,INPUT);
 pinMode(6,INPUT); // two data inputs, we use just one
 pinMode(7,OUTPUT);
 digitalWrite(7,LOW); //GND
 pinMode(4,OUTPUT);
 digitalWrite(4,HIGH); // 5V VCC
 vw_setup(5000);
 vw_set_rx_pin(6);
 vw_rx_start();
 Serial.println("Starting up");

}

void loop() {

 if(vw_get_message(buf,&buflen)) {
   for(i=0;i<buflen; i++) {
    Serial.print((char)buf[i]);
   }
 }
}

It doesn't happen after a certain time or number of messages. I have no clue what could be the problem.
Thanks in advance,
Niklas
Edit: Problem seems solved. Changing bitrate from 5000 to 2000 solved the problem, but I don't actually know why.

Try to also print the buflen variable on the receiver side to see if the data got corrupted (Serial.print will not print anything if it encounters a '\0' or other special characters) or if the data has not been received at all. You can also print the raw values to see what you get.

One thing I have noticed about those units is the power requirements.  You need to be able to provide the amperage that those units will use.  For instance, I couldn't get them to work at all with just USB power, but with a 2 Amp 12V supply they did just fine.  The fact that they start out working is a good sign.  So, are you sure you are giving them enough power?

Did you use the latest official VirtualWire library, or just a zip file you found somewhere on the internet ? The newer RadioHead has a few bugs fixed, look at the 'ask' examples of RadioHead, the usage is almost the same as VirtualWire. You need a piece of wire as antenne (16 cm) or else they almost don't work. 5000 bitrate is too much, everyone else uses 2000 for those very cheap 433MHz RF modules. Too low is not good and too high not good.

I think I/you solved it.
I printed out the buflen variable and at some point it switches to 2 instead of 18. Who knows why.
But changing the bitrate to 2000 helped @Jot
It's running and working for several minutes now, will test it at least a few hours.
Thanks!!

@Niklas - in Sender it might be better to change char *msg = "123456789123456789" to const char msg[] = "123456789123456789";  the compiler will allocate memory in a different way, I don't understand why/how I just get told it is better.

@CodeGorilla const variables are committed to flash memory.

@Niklas Did changing bps to 2000 solve it? How many metres are you transmitting, and are there any objects between the devices? If so, what material are the objects made from?

@user2497 Yes, it did solve it. 5-10cm distance between sender and receiver, no objects in between. I need the connection just for a galvanic separation

@Niklas Great ;) Have you tested with both a linear supply (like 7808) and switching supply (USB)?

Regarding the hardware problem, there are some advices in the comments.
As you wrote, the solution is to reduce the bitrate at 2000 bps.
The remaining question is why the receiver always truncates the message (after a receiving error occurs). The answer is in the definition of the buflen parameter of the vw_get_message function. The page https://www.pjrc.com/teensy/td_libs_VirtualWire.html says:

"buflen" should have the array's maximum size upon input, and upon return the number of bytes actually copied is retured.

Therefore, when a transmission error occurs, the buflen variable returns a smaller number to inform you how many characters are received. If you do not reset the buflen variable to VW_MAX_MESSAGE_LEN before calling vw_get_message again, you are telling the library that you expect a smaller number of characters and the function respects that size (thinking that you have a smaller buffer).
In other words, if you want try to receive the full message after a transmission error occured, set the buflen variable to VW_MAX_MESSAGE_LEN before each call of the vw_get_message function.

Those cheap 433 MHz RF modules can not handle a high bitrate. There are many different 433 MHz modules and the more expensive modules might be able to handle perhaps 10 kHz.
Every pulse from the receiver generates an interrupt. That means also the software has to be able to keep up with it.
For a basic Arduino board at 16 MHz (Arduino Uno, Nano, Leonardo, and so on) and the cheap RF modules the sweet spot is around 1 kHz to 2 kHz bps. The 2 kHz is a safe value.
The 433 MHz frequency requires in most countries that only 1/10 of the time a transmission might be active and the VirtualWire/RadioHead has overhead. That means that the resulting data speed with 2 kHz bps will be between 10 and 20 bytes per second.
The transceiver modules don't have all these (ridiculous) limitations. They can transmit data at a fast rate. Transceiver modules are for example nRF24L01+ modules, CC1101 modules, RFM69 modules, and so on.


text:
OLED display crashes when connecting USB
I got an 16x2 OLED Display (DEP 16201-Y , compatible to the HD44780 controller) for my Arduino Uno and I got it to work in 4-bit Mode, but just if the USB isn't connected and it is powered by a 9V power supply.
So my routine is:

Connect USB and power supply
Upload Code
--> Doesn't work
Disconnect USB and power supply
Just connect power supply
--> Works
Connect USB
--> Display crashes

So basically: If the arduino is connected via USB to my PC, with or without an additional power supply, the display won't work properly, it will crash or the Arduino even restarts itself. (some kind of memory error?)
I have no possible explanation for this..
Thanks for your help.
EDIT: I'm running Ubuntu Mate Kernel 4.4.0-43-generic 64bit
If I plug in the cabel without power, display works fine.
If I plug in the cabel with 5V, but the PC is shut down, the display works fine.
For the display to crash, the pc has to be running.
Test code:
#include <LiquidCrystal.h>
LiquidCrystal lcd(13, 12, 11, 10, 9, 8);

void setup()
{
    //lcd.clear();
    lcd.begin(16, 2);
    lcd.clear();
    lcd.setCursor(0,1);
    lcd.print("Hello there");
    delay(1000);
}

void loop()
{
    lcd.setCursor(0,1);
    lcd.print("Hello World");

    lcd.setCursor(0,0);
    lcd.print("ABCDEFGHIJKLM");

    delay(1800);

    lcd.clear();

}

Does this only happen if your PC is running? If yes: which OS are you using?

When your computer boots, or when you plug the board in with it booted, most likely the serial port that gets created (/dev/ttyACM0) is opened by the process modem-manager. That will cause the Arduino to reset giving you the same results you see when you reset the board in other ways.
I have had no end of trouble in the same manner with a green version of the same screen. The best results I have had is to control the power to the display and power it up at every boot.  You can do it with a simple P-channel logic level MOSFET or PNP transistor:

simulate this circuit – Schematic created using CircuitLab
If you chose, say, D3 (as an example) as your control GPIO you would go:
void setup() {
    pinMode(3, OUTPUT);
    digitalWrite(3, LOW);
    delay(1000); // Give it time to settle after powering up
    ... rest of setup code ...
}

You can also then use it to save power (if you want to) by turning the display off - simply set the pin back to INPUT and it will be turned off by R1.

@LookAlterno Have you ever used one of these displays though? They are troublesome to say the least.

@LookAlterno also, have you ever noticed how, if you boot your computer with an Arduino plugged in, the Arduino will reset part way through the boot sequence? That's modem-manager.

@LookAlterno So am I, but I like to sleep at night so I turn my computer off.

I had the same problem but solved it with with the following code:
The noDisplay(); display(); seems to reset the screen to the correct position.
void LCDInit()
{
  lcd.begin(DISPLAY_LINE_LENGHT, DISPLAY_LINES);
  // We need to do  this to reset the OLED display
  lcd.noDisplay();
  lcd.display();
  lcd.clear();
}