Embedded systems are no different from others in regards to documentation etc. Up front you need your requirements and from that you can derive your acceptance procedure for the finished product. As for the type of doc and how much of it depends on what is required - if it is for medical, military or automotive the requirements will be greater than for something that just turns a light on and off!

Generally your requirements spec outlines what the end result is to be without telling the programmer how exactly to program it. If there's particular formats or protocols, these get described or mentioned here. Things like response times and operation sequences are described - it should give the programmer enough information to write the code.

As for books etc, my favourite is "Code Complete" from Microsoft Press. There's acouple of other books in the series also worth a read - you can buy the boxed set. Checkout Amazon.

For the code itself, well documented code doesn't mean a comment of every line - the comments are to give you extra information to better understand what the code does.