The accepted answer of jfpoilpret is very well written, perfectly valid and in 99% of the cases I will do exactly what he explains. His solutions are well within your defined parameters, so they should work very well. But what is better than "very well"? Perfection! After all, the question is about generating a exact value. As said close enough is good in most cases (arguably all), and even when dealing with something as a clocks when 1 second need to be 1 second, you still have to suffer inherited parts imperfections.
What I will suggest is not always possible. In some cases, it's possible, but with much more hassle and effort than this case. Is it worthy depend on a case-by-case basis. My goal is mostly to show a alternative for future references that is better in somewhat fringe cases. This is written with novice Arduino users in mind that don't have extensive experience in electronics.
For more advanced people this probably will look too verbose and dumbed down. But I believe that, those same people probably already know it and don't need this answer. This is also applicable to every microcontroller and every manufacturer and architecture. But for other microcontrollers you will need to consult the correct datasheet to find out proper registers and prescale names and values.
In your case, you need a specific frequency and the nice thing about it, is that exactly 56 kHz actually can be achieved very easy (not counting practical imperfections of the parts). So this is also a perfect example case.
Generating a signal depends on the timers and clock source of the microcontroller, as explained well by jfpoilpret. His answer deals with the problem of one point of view only and that is fiddling with timers. But you can fiddle with the clock source too, or even better with both for synergy and awesome results. By changing the parameters of the environment, in this case hacking the system and replacing the clock source, we can deal with a specific problem with much, much more ease and simplicity.
First to remind, because of toggling the pin state, you need to execute the ISR two times more than the signal frequency. This is 112,000 times per second. 56,000 and 16,000,000 don't add up very nicely as pointed out already. We need to change either the signal frequency or tact frequency. Let's deal for now with an immutable signal frequency and find a better clock speed.
It would be most straightforward to choose a clock with some order of magnitude bigger than 56 kHz (or 112 kHz, but it is practically the same), as you only add zeros and this kind of math is simplest for most people. Unfortunately everything in this world is some kind of compromise with something. Not every value will work.
The first example is with a too low tact generator speed.
If you choose a 56,000 Hz clock you won't be able to do anything as you will need to call the ISR every cycle and can't do anything else. It is utterly useless. If you choose 10 times faster speed (560 kHz), you will have 9 (10 cycles for the timer to reach its max value - one cycle to call ISR function) microcontroller cycles to do your work and this quite possible can be not enough. You simply often need more computational power.
If you choose a value far too great at other hand, as 56 MHz the microcontroller simply can't work with it. It is way too fast. So, simply choosing the biggest value in the shop won't cut it either.
Original Arduino Uno R3 have a stock clock at 16 MHz, so anything slower that that is guaranteed to work. The next value that is an order of magnitude bigger than 56 and lower than 16 MHz is 5.6 MHz. This will lead to be able to call the ISR every 50 cycles and will create the perfect 112,000 Hz timer frequency. And your signal will be exactly 56 kHz. You will have 49 MCU cycles to execute your program between ISR calls, but it is still around 1/3 of the speed of the original clock. One can use 112 as base and use a 11.2 MHz clock and this will give a about 2/3 of the stock 16 MHz resonator. The ISR function will be called every 100 cycles and still generating a perfect 56 kHz signal.
However two major problems exist with these values.
The first problem severely depends on your needs: You sacrifice about 1/3 (with 11.2 MHz) of your maximum computational power to get the exact signal frequency that use an easy-to-find register value (OCR iirc). You may be fine with it or you may not.
The second problem is a hard showstopper: It is very easy to find values, but very often they simply do not exist as a manufactured clock source. This is Farnell's resonator web page that simply lack both 5.6 MHz and 11.2 MHz.
To circumvent this we can look at available resonator values and find out something else that can be used to generate exactly desired values. If we divide 56 by 4 we get 14 and luckily there is a 14 MHz resonator. This provides us with much higher speed and more power and with equally easy to find register value. To call the ISR 112,000 times per second we need to put value of decimal 124 or hexadecimal 0x7C in the OCR register, so with counting 124 cycles + 1 for calling the ISR, we get our desired perfect value.
N.B.
- ISR - interrupt service routine (this is the code that is executed only on generated interrupts)
- How big your program can be depends on the memory size! It has nothing to do with the clock speed and has nothing to do with how often you call the ISR.
When the microcontroller starts with program command a counter is incremented. If an interrupt is generated, the ISR is called and this value is stored in a special register. When the ISR code completes, the value of the program counter is restored from this special register and the program continues from where it was interrupted as if it had never happened.
I will give an extremely dumbed-down example. If you are a purist, I warn you: Nose and eye bleeding can occur.
Imagine you have to walk from somewhere to somewhere. The step-by-step route instructions are your main program and its commands. How fast you walk or run, depends on your "clock speed", but not on the route instructions (30 steps forward, 1 turn 90 grad. left, 10 steps forward, 45 grad. right, etc.) They are always the same. Now imagine a little kid or a greedy corrupt local politician untie your shoes now and then. This is the event that generates an interrupt. Then you halt after your last step, kneel and tie your shoe again. This is your ISR program.
Then you continue from the place you have stopped; you do not start from beginning. When you walk without a care in the world and with all the time, you don't care even if you have to tie your shoe every other step. If you however do it with time constrains, like running in 100 meters on the Olympics (or running from a hungry flesh-eating predator), stopping and tieing your shoes can have dire consequences. The same is with microcontrollers. Even if you execute only one line of code your program will continue, albeit slow. If you don't care about speed at all, it won't be a problem. If you have to do some time related, like using other timer dependent actions, interference can be very unwanted and problematic.
Less is more! A faster clock is not always better. Slower clocked devices use considerably less power. This can be a crucial point in a battery-operated device.
The needed cycles are derived from this formulae:
(clock speed / (prescaler value * needed ISR calling frequency)) - 1
