I used an F2808 based ezDSP board, and it had an integrated USB JTAG programmer on the board. The parallel port interface on yours might also be connected to an integrated JTAG programmer, or if not, the Code Composer IDE is probably equipped to handle the details of the programming.
Sorry I'm sketchy with the details, it's been a couple of years since I used it .. but look around on the Code Composer menus; somewhere there you should find the option to flash your project into the chip. In CCS 3.2, there was a dialog that could be brought up that listed all the flash banks, let you choose the .out image to flash, PLL multiplier value to use, etc. Device selection was on a nearby menu.
Once you solve the flashing-the-chip problem, I do recall the biggest pain getting started was dealing with the linker ".cmd" files that set the memory layout for the project. When you write C apps for linux or windows, you don't have to deal with these, but when you get as close to the metal as 28xx's with Code Composer, you have to say exactly what block of physical memory is to be used for what program segment. The easy way to get past the complexities of the .cmd file, initially anyway, was to steal one out of the example projects.
In fact, if your software has them, I'd recommend building and flashing one of the canned examples before setting out to write your own software. A search for 'examples' or 'samples' in the CCS install directory should turn them up.
Hey, great timing! This week I've been interviewing E.E. students for an intern position. Here's what I can say with 100% certainty: Students from the big schools, even Juniors working on their Bachelors, have almost ZERO useful knowledge. One guy I interviewed couldn't calculate the value for a current limiting resistor for an LED. Yup, that's what $30k/year will get you for an education. The point is, any practical experience or knowledge you have will put you above your classmates when it comes to landing a job! Seriously, it's that bad out there.
Ok, on to your question. From an employers perspective it doesn't matter which uC you use. Odds are that whatever you choose, it'll be wrong. What's more important is the experience and knowledge you gain will apply to most uC's. That being said, stick to the common ones.
The Microchip PIC's are my least favorite. The hardware is fine, but writing software for them is a super pain in the you-know-what. I've used them in the past, and never again. I've also used the Cypress pSoC 1. It was nice at first, but their software is buggy and documentation is very lacking. A current project of mine uses an MSP430, but it's too early to say how well it works. The TI ARM based uC's are also nice, but might be too much for you at this early stage.
Best Answer
I assume you're talking about how to physically write to the program memory, and not how to write programs using an assembler or compiler for a given micro.
Often this information is not in the datasheet or in the data that covers the instruction set, but in a separate document.
In some cases, unfortunately, that information may be tightly controlled and you may have to sign an NDA (Non-Disclosure Agreement) and/or prove that you are a real company and have a legitimate need for the information.
The assumption is that an ordinary moderate to high-volume user will merely buy a programmer (or get a supplier to pre-program the parts), and has no need to know the protocols involved. Many Asian suppliers really are not interested in providing support for a customer who only wants a few thousand pieces- their ratio of engineers to production workers won't allow for it.