I'm looking to use larger MCU's for speed mainly. As projects get more complex I am wondering if some sort of operating system will help, maybe freeRTOS ? basically my question is what does the OS do, does it help setup the chip or would it be a peice of code that runs alongside mine and manages the timing of it ?
Some OSes will include a HAL (Hardware Abstraction Layer). ChibiOS is one. They will help you operate some or all of the MCU peripherals as abstract entities on the OS level without messing with the actual iron.
As to timing, all RTOSes have some kinds of timing functions, at least various non-busy waits.
The OS code does not really "run alongside" your code, instead the OS provides a library of functions managing creation and manipulation of what is usually called tasks, and communication between those tasks. Simple as it sounds, it is a very powerful concept when done properly.
Basically your code is divided into tasks, each one handling a specific feature or function of the application Thus there might be input and output tasks, a user interface task, various communication tasks to connect the application to the outside world, and signal processing tasks doing the number crunching or similar stuff. All of these tasks need to exchange information with each other and sometimes control the execution of things by putting tasks to sleep or waking them up. For this purpose all OSes implement a set of intertask communication methods such as queues, semaphores and mutexes and there are others.
A decent RTOS will also definitely include interrupts in the supported features such that communication from interrupt context to the scheduler is possible. A scheduler is the "core" of the RTOS, and it is the scheduler that grabs control from an executing task, switches the processor context to some other task and restarts (or continues) that task from where it left off last time. As a rule control is given to the highest priority non-blocked task or, if there are multiple such tasks then they are alternated round robin or some other "fair" priority rule.
The context switch can be either cooperative or pre-emptive. In the first case a task must explicitly yield either directly or by issuing an OS call that results in a context switch. A pre-emptive scheduler has a master clock ticking at a predetermined rate. Each tick wakes the scheduler that will then switch context all by itself if the switching conditions are met.
The end result is that you implement the app as a set of procedures that become the tasks under the OS once they have been "created". Usually you also create a set of OS queues and hand them to the tasks so they can talk to each other. Upon task creation (usually but not necessarily in the main program) the OS core allocates a stack for each task an initializes that stack (creates the initial running context in that stack). This way the tasks are allocated one by one and when the scheduler is started it switches the running context to the first task and the application proper starts from there.
Additionally, OSes always have functions to allocate and free dynamic memory (yes yes, but let's not go there). Some understand about memory protection and so on and so on.
While you can get a long way with the NoOS option, getting to know at least one common RTOS is decidedly a clever move if you ask me. Basic usage is if not trivial then entirely easy and produces predictable results as long as certain minimum sanity measures are kept in place (stack size for tasks and similar)
Basically what OSes should I consider and will they give me any simplicity in my projects ?
FreeRTOS and/or ChibiOS. There is a learning curve (reasonable). The code complexity and size will start at some nonzero level but the growth rate will be slower than for the NoOS option. In the end yes, they do give you simplicity but not at the trivial low end. The blink-a-led app won't get that much from an OS.