Electronic – Frequency modulation and communication between two microcontrollers

It sounds like your underlying architectural flaw is that you have the receiving of pulses coupled to sending out the flow rate or accumulated water information. Also, make sure that this water meter either produces clean digital pulses already, or that you debounce the signal in case it is just from a mechanical switch.

In the most general case where you have to debounce the water pulses, don't interrupt on the pulses at all. Interrupt regularly from a timer. This needs to be a minimum of 10s of times faster than the pulses at the maximum flow rate. The interrupt routine will require a minimum number of consecutive high or low states before considering the debounced signal to have changed to the new state. Once that happens, it increments a counter. Microcontrollers are much faster than water meters, especially mechanical ones, so interrupting fast enough should be no problem. Usually a 1 ms interrupt is good enough for this, and then you can use it for other system timing.

Now you can periodically send the counter value or any accumulated delta on ansynchronously. To avoid contention over the counter with the interrupt routine, the counter the interrupt routine increments can be a single byte. The foreground code keeps it own copy of the last known value of that byte. It periodically reads the interrupt routine counter, compares it to the last known value, processes any new ticks the difference represents, then updates the last known value. As long as the foreground routine does this often enough so that the single byte counter can't wrap between samples, no data will be lost.

The foreground code can then decide when to send information. This can be based on a timer tick and/or when there is new information to send.

You can drive a small bipolar stepper motor using an L293, SN754410, or L298

If you find a unipolar stepper motor (not uncommon in the paper advance on cheap printers) you can drive that relatively easily with discrete NPN transistor switches. In theory you can do a bipolar motor that way, but the circuit is a bit trickier (it's easy to get both the high and low transistors on and as a result short out the power supply, making them rather warm). Besides printers (copiers?) floppy drives are another salvage source, but hard drives switched to voice coils ages ago. Lots of surplus outfits will sell you motors; if you aren't looking for something powerful enough to run a machine tool you probably won't have to spend much.

Since you are very new to embedded programming as well, you might want to look at one of the "motor shield" type solutions - not necessarily to buy (though of course that is an option) but to study the plans and example software.

If working with a salvaged motor for which you don't have data, start with low voltage/current until you get movement. One thing that can be interesting to do is to take a <1 amp power supply and work out the series of voltage applications to the winding by hand connnecting them to slowly step the rotor. You can buy chips such as the L297 which generate this sequence to control the power driver chip, or you can do it yourself in software.

Actually making a motor may be fairly tricky, but people do make brushlesss motors which are stepper's lower-pole-count cousins. For early experiments ball bearings are likely not your greatest concern - plastic or oil-impregnated bronze sleeves might serve. But rollerblade wheel bearings are fairly cheap: mounting them is going to be a big part of the challenge (and a challenge which starts to stray from the topic of EE stackexchange)