New C18 3.0+ Compatible FRC Code

[billbo911]

Originally Posted by EHaskins

I believe that headers within <>s are found in "c:\mcc18\h" by default. If you look adc.h, delays.h, and stdio.h, are all located there.

So I have learned.
Well, as long as I keep learning, I don't mind hanging it out there. At least now I know more than I did this morning.

Originally Posted by Joe Ross

adc.h should be included with the compiler. Are the include and library paths set? In the older MPLAB, the settings would be in project->build->project and would be:

C:MCC18\h for Include Path
C:MCC18\lib for Library Path

Originally Posted by Kevin Watson

Actually it's <adc.h> and <delays.h>. The <> tells the compiler to use it's own header files (usually in mcc18\h) instead of looking in the build directory. Once the code is stable and I have a sense that teams will want to use it, I'll build versions with support for some of my other code, like the ADC, gyro, encoder, etc.

-Kevin

That explains what I didn't understand. Thanks.

I am looking forward to the new builds that include your: ADC, gyro, encoder, PWM etc. I have learned a lot this summer by working with those versions from previous years and getting them to work with my Vex.
As of right now, I can fairly confidently say, we will use your code this year as long as the programmers don't decide to go with EasyC Pro. I need to let them make the choice.

[Kevin Watson]

Originally Posted by billbo911

I noticed a couple "#include" statement for files that do not exist. For example, in "ifi_code.c" is a call to include "adc.h" and <delay.h>. I'm not clear on the differences when the "<xxxx>" is used, but it sure would be nice to have your "adc" code included.

Actually it's <adc.h> and <delays.h>. The <> tells the compiler to use it's own header files (usually in mcc18\h) instead of looking in the build directory. Once the code is stable and I have a sense that teams will want to use it, I'll build versions with support for some of my other code, like the ADC, gyro, encoder, etc.

-Kevin

[Kevin Sevcik]

The layout looks a lot more straightforward than the standard IFI. To address the concerns of those who would rather have a single Spin function, you always have the option of defining your own Default_Spin() function and calling it from each of the other Spin functions. I really think that choice comes down to six of one and a half dozen of the other. If you'd rather have a single spin function and switch inside of it on flags, you're duplicating the mode determining logic already defined in the main loop for the privilege of shoving all your spinning code into one large function. I don't think saving a function call to a Default_Spin() routine is really worth that hassle.

[Kevin Watson]

Originally Posted by billbo911

If I understood the included "C18 ISR.pdf", we should be fairly safe and not have to modify it at all, correct?

Yes, as long as you keep your code within the ISRs that I've provided in interrupts.c and timers.c, you should be fine.

-Kevin

[gnormhurst]

Great design. Just a word about words.

The *_Spin() functions are great -- it's just that in my little robot namespace world "spin" refers to when the robot turns around its axis. (We set up the joystick so one of the buttons calls the spin() routine that makes the robot turn on a dime.) When I saw "spin" that's what I thought it meant; I had to study the code to see what it really meant.

Is "spin" so standard in the embedded world that I should invent a new term for "turning on a dime"? (Diming? What if you only turn 90 degrees? Is that Quartering?) Or can we name the _Spin() functions something else? _WhileWeAreWaitingForNewData()? _StudyHall()? _Loitering()?

Sorry for the bad jokes, but I'm seriously concerned about overloading the term "spin"...

It just me?

[Kevin Watson]

Originally Posted by gnormhurst

Is "spin" so standard in the embedded world?

In computer science a "spin loop" is a way to waste time while waiting for something to happen.

-Kevin

[Kevin Watson]

Originally Posted by Jon236

Had a little problem compiling...

It's not backward compatible with the 2.4 compiler. I'll create a 2.4 friendly version if people like the layout. The update to 3.1 is available on Microchip's website:

http://ww1.microchip.com/downloads/e...-doc-v3_10.exe

-Kevin

[Spencer E.]

Wow Kevin! I love it already. Everything is so well organized and everything is incorporated. This will be a really good tool for rookies as well as veteran teams . I will definitely be using this on our 2008 robot

[Lafleur]

Kevin:

Here are some change that I made to your serial routine to set the baudrate correctly for any processor speed.

in serial_port.c

#ifdef ENABLE_SERIAL_PORT_ONE
void Init_Serial_Port_One(void)
{
// Start by initializing the serial port with code
// common to receive and transmit functions
// SPBRG = BAUD_38400 ; // baud rate generator register [251]
SPBRG = SPBRG_VAL_1; // defined in hardware.h
//
#ifdef USART1_USE_BRGH_LOW
TXSTAbits.BRGH = 0; // high baud rate select bit (asynchronous mode only) [248]
#else // 0: low speed
TXSTAbits.BRGH = 1; // high baud rate select bit (asynchronous mode only) [248] // 1: high speed
#endif // 1: high speed


.................................................. .................................................. .................................................. ......


#ifdef ENABLE_SERIAL_PORT_TWO
void Init_Serial_Port_Two(void)
{
// Start by initializing the serial port with code
// common to receive and transmit functions
// SPBRG2 = BAUD_9600; // baud rate generator register [251]
SPBRG2 = SPBRG_VAL_2; // defined in hardware.h
//
#ifdef USART2_USE_BRGH_LOW
TXSTA2bits.BRGH = 0; // high baud rate select bit (asynchronous mode only) [248]
#else // 0: low speed
TXSTA2bits.BRGH = 1; // high baud rate select bit (asynchronous mode only) [248] // 1: high speed
#endif // 1: high speed





------------------------------------------------------------------------------------------------------------------------------------------------------------


in the hardware set up routines...




// Define system xtal/clock frequency
//
#define CLOCK_FREQ (40000000) // Frequency in Hz

#if defined(__18CXX) // All PIC18 processors
#include <p18cxxx.h>
#define INSTR_FREQ (CLOCK_FREQ/4) // PIC18 clock divider
#else
#error Unknown processor or processor not defined
#endif


// Set up serial port(s) baud rate
//
#define BAUD_RATE_1 (38400) // Serial port 1, bps
#define BAUD_RATE_2 (38400) // Serial Port 2, bps

// set as needed...
//#define USART1_USE_BRGH_LOW // for most lower baud rates
//#define USART2_USE_BRGH_LOW // for most lower baud rates

#if defined(USART1_USE_BRGH_LOW)
#define SPBRG_VAL_1 ( ((CLOCK_FREQ/BAUD_RATE_1)/64) - 1)
#else
#define SPBRG_VAL_1 ( ((CLOCK_FREQ/BAUD_RATE_1)/16) - 1)
#endif

#if defined(USART2_USE_BRGH_LOW)
#define SPBRG_VAL_2 ( ((CLOCK_FREQ/BAUD_RATE_2)/64) - 1)
#else
#define SPBRG_VAL_2 ( ((CLOCK_FREQ/BAUD_RATE_2)/16) - 1)
#endif

#if ((SPBRG_VAL_1 > 255) || (SPBRG_VAL_2 > 255))
#error "Calculated SPBRG value is out of range for current CLOCK_FREQ."
#endif

[Code Monkey]

To be clear, without Kevin this would be miserable. Team 1622 is massively
in your debt. Thank you.

For those who have not already installed the MCC upgrade, make sure you put it in the same directory with the upgraded MPLAB 8.0. Otherwise the linker can't find the libraries. I know by the trying it the wrong way.

[comphappy]

Rookie team 2605 will be using your code, it is structured in a way that makes more sense, I have not gone through it all the way yet, but so far so good. BTW is there a better search tool in mplab than the just straight basic find? For my embedded systems work I am always using grep and regexps, so far mplab has been really disappointing.

[B.Johnston]

Comphappy,

The answer maybe Yes!

Try under the Project Menu > Find in Project Files.

Once you enter your keyword you'll be able to see the results in the output window under the find in files tab.

Double click on whatever you want to see and a new window will open with a pointer to your chosen element.

I hope this answers your question, as I'm not really sure as to what grep would deliver as a result.

[comphappy]

Thanks that is what I was looking for, still not very good, but better then what I had found. Grep is extreamly flexible long as you are willing to spend the time to learn how to use it correctly.

[Kevin Watson]

Here's a snapshot of the latest build:

http://kevin.org/frc/ifi_frc_beta_3.zip
http://kevin.org/frc/ifi_frc_gyro_beta.zip (with integrated ADC and Gyro code)

-Kevin

[Guy Davidson]

Kevin,

Is there any change log? So we can keep track of what's bew in beta 3? Other than, of course, the ADC and gyro in that version.

Thanks.