Pragma fix

[CrasherCourse]

All pragmas have been added and defined to the best of my understanding. Code builds correctly on my computer, but I would appreciate confirmation.

If any bits seems like they should be defined as something else please tell me. Example: not sure if the extended instruction set should be on.

[CrasherCourse]

@tylrtrmbl MPLAB was already set to 4 spaces. I actually went and changed it to eight which seems to be the setting in my version of git.

[CrasherCourse]

For some reason, when I view the file in files changed the comments are all weird. When I look in branches, they are all perfectly aligned. -_-

[taylortrimble]

Ah yes! Look one comment above and you'll see what that is. :smile:

[CrasherCourse]

Formatting is FINALLY finished. ...tabs...sigh

Now, @tylrtrmbl and @aterlumen can check the code without ugly comments.

[taylortrimble]

What crystal type and Fosc is this configuration assuming?

[taylortrimble]

I asked some questions in the diff. What I didn't question looked well done, thank you @CrasherCourse!

[CrasherCourse]

Some answers: Looks like Rachael designated RB6 and 7 to debug, so there's no harm in enabling it. HSPLL mode takes a crystal up to 10MHz and multiplies the frequency by 4. The product for the system clock.

[taylortrimble]

So we're limited to 40MHz. Okay. @aterlumen, is that acceptable? Or do we need to find a workaround in hardware or code?

[CrasherCourse]

Wait, the pickit 3 user guide says the kit handles debug by itself.

Caution: The DEBUG configuration bit value should not be specified in source code Configuration settings under normal conditions. Doing so may cause the bit to be asserted when programming a device outside the debugger. This will cause the device to function improperly or not all at in the application circuit.

[taylortrimble]

Well then. Let's leave that disabled. :sweat_smile:

[CrasherCourse]

Actually, I might have to remove it if specifying debug can result bad times.

Also, the datasheet says 40 MHz is the max frequency.

Something else: Looks like the extended instruction set is more trouble than its worth for free student compiler mode. I'll leave it off.

[taylortrimble]

Oh, I see, we shouldn't even have the #pragma. Got it.

[kevana]

I think 40MHz will be fast enough. Assuming the free version of the compiler is at least halfway efficient, my DMX receiving code should compile into ASM that's pretty similar to the original version from Microchip. The thing we'll have to check is whether the break time between DMX frames is long enough to send out all of the I2C data to the slaves. Even if it's not it won't be the end of the world. Servos travel slowly enough that even if half the DMX frames are dropped we probably won't notice much of a difference.

[taylortrimble]

Okay, that makes sense. Will we be able to get accurate baud rates for the MSSP (for I2C) and USART (for DMX) with a 40MHz clock? What is the configuration code (not #pragma bits like here) assuming for setting up the MSSP and USART?

[CrasherCourse]

I feel we should get decent resolution with 40MHz, which I believe leads 10MHz instruction frequency.

[CrasherCourse]

So does anyone have any objections to me merging this branch?

[taylortrimble]

:water_buffalo:

[CrasherCourse]

@tylrtrmbl I don't get it.

If there's no other objections I'll merge this branch this evening and start working on data abstraction.

[kevana]

No objections from me On Nov 15, 2012 3:42 PM, "CrasherCourse" notifications@github.com wrote:

@tylrtrmbl https://github.com/tylrtrmbl I don't get it.

If there's no other objections I'll merge this branch this evening and start working on data abstraction.

— Reply to this email directly or view it on GitHubhttps://github.com/teslaworksumn/HeadMaster/pull/19#issuecomment-10426784.

[taylortrimble]

@CrasherCourse Haha! A picture is kind of like "Go ahead".

Go for it! :smile: