New Controller Board

Lynxmotion
101

I have an 18F4550 and a dsPIC30F4011 on my breadboard now. :slight_smile: Maybe I can wire up enough of Peteā€™s MCU circuit to fiddle with. I am most interested in the I2C master/slave stuff right now.

Yes, of course. :smiley: I wired up there MCP23017ā€™s when I was learning about I2C and using an Atom PRO to drive the circuit. I had one of these driving 16 LEDs so I could use both 8 bit and 16 bit modes of the chip. I eventually plan to use at least one of these chips to sequence some LEDs on my robot for visual indicators of what sensor is detecting an obstacle and just all around fun. I know how these chips work now, and how the circuit should behave, so it should be a good test for the PIC I2C stuff also.

Yes, I am always tweaking my code, looking for better ways of doing things. :smiley: Grasshoppah proposed a change which I could not make work and thatā€™s when I discovered I didnā€™t need one of the for loops.

8-Dale

102

Hi Dale,

Iā€™m thinking just daisy chain the I2C stuff. Thatā€™s only a few lines.

Sounds about right. that wonā€™t be hard to handle. I went looking for the schematic, and found that I DIDNā€™T have a URL for Peteā€™s website and the files on this machine! Musta left it in my other PC. I want to map out the I2C stuff, and see how it fits into my boards. Yes, 4620 is very much similar to the 4550, except as noted. I like heartbeats as well! Can you give me the URL? It will save me some time.

Looks like I have some reading to do! A little slow, (I can easily get over 5 MHz with SPI), but itā€™ll do.

Iā€™ve used ribbon cables with multiple connectors before. An edge connector would be best, but a right-angle connector would work. This will a simple ribbon to run along one edge, and allow the boards to open like a book. Iā€™m not about to buy a ton of Modtronix boards, unless I win the Lotto! Iā€™ll work with what Iā€™ve got, or can build for now.

That would be good, Maybe youā€™d draw up Peteā€™s circuit?

Iā€™m most interested in getting my 'Bot code to imitate the Atom code! After that, I want to do a real-time multitask version. That may be a little tricky, as sending th long SSC32 text strings takes large blocks of time. Even with interrupt driven tx/rx, I have a lot to work out.

Thatā€™s a good use! And it will give you some experience with I2C as well. I should consider it.

Waitā€™ll you check out the real-time stuff! Have you studied the BASIC Atom code?

Alan KM6VV

103

This would work with two I2C connections per board - in and out.

Sure. Iā€™ve created a directory on my website for this stuff. No HTML there yet, but I will work on that too. Maybe a Wiki would be in order for this on my website.

Peteā€™s dualPIC electronics
Peteā€™s dualPIC PC Board

Iā€™m going to collect a bunch of stuff from this thread and eventually put it on my website once we have things a bit more finalized.

I want to learn about SPI also, at some point, so might have questions for you on this some time. :slight_smile: I have the Philips PDF file on I2C if you need it. I can add it to my website.

Oh, I agree! I was not suggesting purchasing a bunch of Modtronix boards. They are just a good example for reference. I might get one at some point to fiddle with though. I still want to get an OOBOT board because it does accept standard PICs also and is the closest to a PIC bot board there is right now.

Yes, that is my plan. It seems like it would be very desirable to have Peteā€™s schematic converted to Eagle, especially if you can make boards from this data.

This is my plan also. :smiley: I want to convert all my Basic Atom code for WALTER to run on Peteā€™s dualPIC board and any variant we create. I love the idea of having a USB capable version of Peteā€™s board and think the trade off for USB vs a bit of program memory is worth it.

I agree, but interrupt driven serial I/O routines are very desirable. I have not looked at Peteā€™s serial I/O code yet, but he may already have done this.

I am concentrating on one section of his code at a time plus any related code. Right now I am concentrating on I2C and am just getting ready to start working with it. I have the MCP23017 on the breadboard and ready to wire up to the 4550. I have my I2C pull ups already wired in. I have alread pulled Peteā€™s I2C files into my i2cleds project and everything builds, so it should be good for use.

The MCP23017ā€™s are actually very easy to work with and I recommend them for a first I2C project. I can help with them too, if you have problems. :slight_smile:

The Basic Atom was my first embedded microcontroller and what I still have on WALTER now. :slight_smile: I actually have so much code that I ran right to the limit of the Basic Atomā€™s program memory.

8-Dale

EDIT: Fixed quoting

104

Hi Dale,

TWO I2C connections? Pins or Connectors? I forgot to count the address lines, and interrupts? But still, there are only two data lines (SDA/SCL), which are SHARED, arenā€™t they? ONE ribbon cable, with a connector per board should do it, I think. Iā€™m going to dig up the Microchip I2C documentation.

You could do that. Just getting a series of schematics up (Eagle!), some board layouts, and software in a series of modules would work.

Thanks for the URLs. More stuff on Peteā€™s boards then I remember! The battery charger could be interesting, I was thinking about that.

I just got my ā€œBirthday Giftā€, a box of Lynxmotion parts! servos, brackets, and a 2800 mAH 6V battery pack. Iā€™m busy putting a leg or two together. Not enough for a full 'bot, but Iā€™ll be able to work out the leg motion, and compare it to my friendā€™s 'bot.

His 'bot has itā€™s legs up in the air, and Iā€™ve been playing with the sequencer. Iā€™m still not certain what bolt-circle diameter I need the shafts of the servos to be on my 'bot. 10.75" looks REALLY BIG!

Sure, Iā€™ve done SPI a few times, on different processor families. I have the Philips doc. 39340011.pdf, right?

the OOBOT board is OK. Too bad there is no bare board available. Iā€™m currently set on using the Quick Flash (PICbook.com) boards.

If they are connected by I2C, you might want to get some of the Modtronix schematics (if possible), and see what theyā€™re doing.

[Draw Eagle schematics]

It is surprising how much code DOES fit into a Stamp! I borrowed a Stamp 2 to be able to see it run and compare it.

Alan KM6VV

105

Greets, Alan!

You need a way for the I2C bus to go to the next board, so having one connection from the last board and one to the next board seems reasonable. Yes, you could also try using a ribbon cable with multiple connectors if your QuickFlash boards only have one I2C connection.

Beware of noise on the I2C bus. There is a set standard for I2C cabling. You can also use the Acroname I2C cable standard. Acroname has done a lot with I2C so why not make use of this?

OK, I am going to spend some time with Eagle and see what I can come up with for schematics. It does seem like a worthwhile project, and I really do need to get into schematic capture.

Yes, there is a lot of stuff in Peteā€™s design to digest. I am looking at his I2C code now, and have started pulling bits and pieces into my main module for my i2cleds project. So far, it compiles, but I have only brought the pic_init routine over so far, plus the I2C and SCI related headers and code.

Congratulations and Happy Birthday! You are building a hexapond, one leg at a time. :smiley: I so want to build a CH3-R!

I have some info on some of the lexan decks and such, so will see what I can find out for you. I am also in the process of creating some 3D CAD models for various parts, including the new HUB-12. I already have a model for the GHM-04 motor.

I believe that is it. If not, let me know and I will add it to my website for download.

I would like to get just one of them to tinker with. I am always interested in what companies like Modtronix is doing.

I donā€™t currently have a board I can plug PICs into, so thatā€™s why I want an OOBOT board. I also want to explore the ooPIC a bit.

I know they do have I2C on their boards. I will have to see if they have any schematics online.

I already have the code for UBW 1.4.2. :smiley::smiley: As soon as I get my 20 Mhz crystals, Grasshoppah is going to help me get the USB working. He uses a lot of 2550ā€™s and 4550ā€™s in his own projects. I have all the parts I need except the crystals, which I had to order.

Speaking of speed, I notice that Pete has a 10 Mhz crystal for the 4620 and a 7.3728 Mhz crystal for the dsPIC4011 in his design. Would there be a major impact to go to a 20 Mhz crystal for the 4550 and something faster for the dsPIC? I realize that software timing loops would be affected, but is there anything else I would have to consider?

I can learn and work pretty quick when I am very interested in something.

I agree. Thatā€™s why I want to use a circuit I am already very familar with.

I just ordered some more 2550ā€™s, 4550ā€™s, MC23017ā€™s and dsPIC4012ā€™s. I have a bunch of MCP3208 (8 channel, 12-Bit ADC) I want to tinker with too, but I think they use SPI so that will have to wait for awhile.

I am just starting to wire the I2C from the 4550 to the MCP23017, so we shall see what I can do with it. I have two circuits wired on my breadboard now - a working production circuit with a 4550, and a development circuit with a 4550, dsPIC4011, and an MCP23017. I have the heartbeat LED working with the development circuit now. I have changed my code to write to the latches rather than directly to the ports. This is how Pete seems to be doing it, so I switched my stuff to match that.

8-Dale

106

Actually, I have only used 4550s. I have no need, yet, for 2550s as they are 28pin. I am planning on getting some later so I can try out the UBW on them.

The difference would be time sensitive issues. Delays, for example, are based on clock cycles. You will not feel anything, depending on how Pete made the code. If he set a global at the top which defines the clock speed and used that global as the FOSC in all of his clock related code, then you simply edit that one or two globals and your perfect. If he did not, you would need to go through every file and replace 10MHz with 20MHz, or 48MHz (if using USB Bootloader). Things like I2C are done on a specific frequency. This frequency needs to be defined. It can either be defined based on FOSC/4, or as a hex value. You will need to check in those functions as well to make sure everything is correct.

Other than that, you shouldnā€™t notice anything other than everything getting done FASTER!!! I mean, FASTER!!! ZOOM FAST!

I tested my OLED from Spark on the default 8MHz internal freq of my 4550 and text went slow :frowning:! I mean, slow. Half a minute or so to write out a line or two (not a long line either). I upgraded to 20MHz and poof! My text went flying across the screen. I have yet to test the upgrade from 20MHz --> 48MHz. That should be WHOA! Canā€™t wait to see how a dsPIC @ 120MHz takes it o.o

-robodude666

107

I need to find an Eagle library that has the 18F4620. I have a library with the 18F4550 and dsPIC30F4011. I am surprised I canā€™t find a library for the 4620. I will check the Microchip site also. Iā€™ve looked on the CadSoft site already and missed it if it is there.

8-Dale

108

I have been thinking about clock rates and MCU speeds as I dig deeper into Peteā€™s code and start to pull some of it in so I can use it. His code is based on a 10 MHz clock rate for the 18F4620, and there is a second_ticks variable that is set to the number of clock ticks/second. So far, it looks like everything is based around these values.

Now, I have been thinking it should be pretty easy to speed up the 4620/4550 wthout messing up the rest of the code. Iā€™d like to be able to run the 4620/4550 at 10 Mhz, 20 Mhz, and 40 Mhz. Maybe even 48 Mhz (fastest) if possible. It would be great to have speed options for various applications. So far, it seems like we would only have to figure out the magic values for second_ticks for each clock rate. I believe we would just have to double the value of second_ticks to go from 10 MHz to 20 Mhz and again to go to 40 Mhz.

Here is the oscillator setup code:

// Settings for 10 Mhz oscillator: OSCCON = 0b11000000; // external xtal OSC, 10 Mhz Osc_Freq_Mhz = 10; second_ticks = 100; ADCON2 = 0b10000001;
8-Dale

109

The 100 ā€œsecond ticksā€ deals with timers and interrupts. If you look at Peteā€™s InterruptHandlerLow(); (Low Priority interrupt handler) you will see that that he has

    // Timer 2 interrupt.
	if (PIR1bits.TMR2IF) // expires every 10Ms at 10 Mhz
    {
        PIR1bits.TMR2IF = 0;

        tmr2_expire_cnt++;

        if (tmr2_expire_cnt >= second_ticks)
        {
	        // Do this stuff every second.
            tmr2_expire_cnt = 0;
            
            // Trigger a blink of the heartbeat LED.
			heartbeat = TRUE;
        }
    }

Every 10ms it checks to see if 100 ā€œticksā€ passed by (AKA the timer is going at 100Hz). If it does, then the heartbeat will become true. This variable is used in the main while loop to trigger an LED and do some i2c related things.

Why is this? Lets look at the 10MHz settings:

	// Settings for 10 Mhz oscillator:
	OSCCON = 0b11000000; // external xtal OSC, 10 Mhz
	Osc_Freq_Mhz = 10;
	second_ticks = 100;

We know that the PIC is operating at 10MHz. So the proper OSCCON is set, and OSC_Freq_Mhz (used in his delay library) is set to 10. And second_ticks is set to 100 as needed. But why? The answer lies in the Timer settings. Timer2 to be exact!

If we scroll up a bit, we will find this nice blob of code:

	// Setup Timer 2.
    T2CON = 0b01001010;     // 10 post scale, timer off, 16 prescale
    PR2 = 156;              // create 10ms clock at 10 Mhz
    TMR2 = 0;
    PIR1bits.TMR2IF = 0;
    //TMR2IP = 1;             // high priority
    PIE1bits.TMR2IE = 1;	// enable interrupt
    tmr2_expire_cnt = 0;
    T2CONbits.TMR2ON = 1;

Whats it all mean? I wonā€™t get into bit details but I will explain the reasoning and behind it.

Remember FOSC/4? Thats your new best friend. FOSC is written in units of Hz, so at 10MHz it will be equal to 10,000,000Hz. There are 4 operations per Hz so we divide by 4.

We then take a look at the first line of the setup:

    T2CON = 0b01001010;     // 10 post scale, timer off, 16 prescale

Thanks to the comments, it saves me from some bit picking. Check the 4620 manual under ā€œREGISTER 13-1: T2CON: TIMER2 CONTROL REGISTERā€ for more info.

Basically there are two important numbers here. A 10 post scale, and a 16 prescale.

Prescale is applied before so we first divide by 16 and get:

WAIT! We need something else. Timer2 is an 8-bit timer. So there are 256 counts. It starts at 0, by default, and counts upto 255 and then ā€œoverflowsā€ or ā€œwraps aroundā€ back to 0.

(I am rusty on this part, so forgive is my wording is wrong or if my explanation is wrong)

    PR2 = 156;              // create 10ms clock at 10 Mhz

We have a register called PR2. PR2 is the ā€œstartingā€ position for the Timer2. Since we are starting at 156 we only have 100 counts to go (256 - 156 = 100). We need to multiply the prescaler by the number of counts the timer will make.

Then we apply the post-scaler of 10:

So at 10MHz with a prescaler of 16, post scaler of 10, and PR2 of 156, there will be 100 interrupts per second.

Fairly simple!

So what is it for the other frequencies?

20MHz: ((20000000/4)/(15616))/10 = 200
40MHz: ((40000000/4)/(15616))/10 = 400.6 = ~401
48MHz: ((48000000/4)/(156*16))/10 = 480.7 = ~481

Or simply: (FOSC / 4) / (COUNTS * PRESCALER) / POSTSCALER

So basically, its about 10x of the MHz with these settings!

I hope I got it right >_< I havenā€™t done this stuff in a while. Nick exaplained it to me a lonnnng time ago, back in like feb/march! I didnā€™t understand it very well but I read for a bit and seem to understand it better. Sorry if my wording is wrong.

-robodude666

110

This is all making more sense to me now. :smiley: My reasoning was correct, even if the basis was a little flawed. I just didnā€™t see how we could run at 48 Mhz and not upset at least some of Peteā€™s code. I knew second_ticks had to be the key.

I am glad I decided to order several 20 MHz crystals now. I have all the other parts for a 20 Mhz clock rate, but I believe some of the values may have to change for the higher 48 Mhz speed. Is this right?

In our IM discussion tonight, you showed me why we have to run at full speed (48 Mhz on the 4550) to get full use of USB. So our 4550 crystal will be 20 Mhz instead of 10 Mhz, and our clock frequency will be 48 Mhz. Iā€™ll just have to set second_ticks = 481 in the pic_init() routine. I definitely want the option of using a USB bootloader for the 4550. Then we just have to use ICSP for the dsPIC. I have some interesting questions regarding programmability of the dsPIC nowā€¦ :wink: :wink:

I think you did just fine, Grasshoppah. :smiley: You have sure been helping me understand all this stuff, and I appreciate that.

8-Dale

111

Hi Dale,

OK, you mean to plug one connector in and one connector out of the board. then youā€™d use two or three small ā€œjumperā€ cables. yes, that would work at the expense and real estate of a 2nd connector.

I am putting legs together, and comparing them with my friendā€™s 'bot. Funny, I thought his fixed mounting of the hip servo ON the 'bot body would cause it to rotate the opposite direction. Same for the knee servo flipped left-right. Not so! Iā€™ll have to check them all, and the LEFT and RIGHT sets of servos on the CH3-R (and other lynxmotion 'bots) must account for some observable direction differences.

That would be helpful. Iā€™m going to use aluminum for my 'bot body, and Iā€™d like to keep it smaller then the 10.75" Iā€™ve seen, but the legs need room to swing. I will have a custom board mounting for the main processor (stack?).

The UBW code is a good place to start. Actually, except for the user.c file, itā€™s the code that Microchip released. Youā€™ll want to re-map the board connections, but itā€™s easy to get working. Oh thatā€™s right, depending on which compile you use, I think the author of the UBW board used a slower crystal. The PICDEM USB board uses 20 MhZ. A setting in the code to change. I donā€™t know what the dsPIC wants. Hopefully any timing loops use XTAL type constants, and calculate from there.

The MCP3208 sounds interesting. EEPROMS can be interfaced with SPI or I2C as well, two different (24, or 25) series parts.

All that on one breadboard? Are you using a timer to generate the heartbeat interrupt? Youā€™re making progress! You can take a similar uP and make your own library!

Hopefully that will do it. donā€™t forget about the PLL.

Some reason to run at different speeds? Just run it all out! Basically thatā€™s it. you want to be able to set up a timer for a system clock tic, say 100 KHz, and then itā€™s easy to do delays, I2C, SPI, heartbeat, etc.

112

Yes, thatā€™s it. I think Acroname uses a dual row 2x5 header, which doesnā€™t take up that much more board space than the single row header would.

I got some info on one USB bootloader, I believe the one Microchip has released, and it depends on a 20 Mhz crystal to run at 48 Mhz clock frequency. So, thatā€™s what I think we need to do - raise the clock frequency to 48 Mhz for the 4550.

It is interesting because it has a full 8 channels of 12 bit A/D. There are actually at least four different memory capacities up to 256kB (1024x8) in the EEPROMS. I have several of the 256Kb and 512kB parts ready to use. Itā€™s possible to have eight of these on a single I2C bus, and that fits right in with a feature I want to add to WALTER.

Yes, I have it all on one breadboard along with 9 LEDs for the production circuit. There will be another 9 LEDs at least for the development circuit for heartbeat and output from the MCP23017. I am not using timers right now. I am depending on Peteā€™s code to get all the timing right. I have the chips (4550, 4011, and 23017) for my development circuit all wired for power , reset, and I2C lines now, and am ready to proceed with checking out Peteā€™s code as soon as I get crystals for the clock circuits of the 4550 and dsPIC4011.

I spent quite awhile tonight with Grasshoppah and we worked out a bunch of stuff. All the timing is already handled in Peteā€™s code and raising the clock frequency to 48 Mhz (20 Mhz crystal) will not upset his code. I wonā€™t have the crystals until the first of next month.

That was just a thought, but not one I want to implement. I am quite happy to run at full 48 Mhz speed, even though it will likely mean a heavier power draw. All the delays and such are handled by Peteā€™s code quite nicely.

As soon as I have verified that I can successfully use Peteā€™s I2C routines to control and use the MCP23017, I want to see what it will take to speed up the dsPIC. :slight_smile: If the code is like that for the 4550, it should not be too difficult to do.

8-Dale

113

Actually, KM6VV is right. The UBW project uses a slower external crystal. He uses a 4MHz resonator (ceramic w/ built in caps). BUT it can still hit the 48MHz that full-speed USB requires. Its a weird thing, but it works. I personally would rather use the 20MHz w/o caps because it seems more accurate.

Personally, if I were you, I would not use the UBW as a backbone of your dualPIC system. You CAN, and I recommend it, look through the user.c like KM6VV mentioned and look at how Brian does things. Some VERY nice stuff. I will be borrowing Brianā€™s command reading system :slight_smile: But the project has a ton of crap that you simply donā€™t need for your project. The UBW project is mostly designed so you can control/read the i/o via a GUI on your system. You donā€™t need that, at all.

I would recommend you start from a blank project. Get that 20MHz crystal and set the proper config bits so it runs at 10MHz like the original project. Rewrite whatever pin definitions you need and see if the program runs like it should. If it does, increase to 20, then to 40, and then to 48MHz. Once that all works, pop on the MicroChip (DEFAULT, regular stuff, NOT UBW!) USB Bootloader. As a basis for the firmware, use either the COM example (iā€™d suggest it. You can print to terminal for debugging <ā€” programmerā€™s best friend.), or you can use a plain firmware without HID or COM or MMS enabled.

Then slowly rewrite the entire code to fit into the new firmware. This part will take a bit of time. In fact, a lot of time.Once the USB Bootloader is on board, some of the vector address change. (iā€™ll help you out with that! I spent a week getting it to work so I know exactly what youā€™ll need to do to get it to work!)

You may actually have to modify a bit of the original code. If the interrupts take up tooo much time, then USB wonā€™t get enough time to do its stuff so windows will return errors and scream that the USB device has failed. Not a good thing =P

For the most part, it wonā€™t be very hard. Iā€™ve used the 4550 for a few months before so I can help ya out if you have any questions. Iā€™m online almost 24/7 =P

Happy Sailing, young PIC explorer!
-robodude666

114

Ahhh, OK. Well, 4 MHz is just going to be too slow for me. :smiley: I want to use the 20 MHz crystal too, and I ordered 5 of them so I would have them for future projects too. I will use 2 of them for my current breadboard circuits (two 4550ā€™s).

OK, UBW is out then. :smiley: I will definitely look into user.c though. It sounds interesting.

I agree. We donā€™t need any excess baggage. I want as much program memory available as possible for robot stuff. :slight_smile:

This is what I have done. I created a new project for my i2cleds program. Then I added a few of Peteā€™s files for the i2c and sci stuff. I have my circuit all wired up and ready to go when I get the crystals. In fact, I have a 4550, dsPIC4011, and MCP23017 wired up.

I plan to start out at 10 Mhz, then move up to 20 Mhz, then 40 Mhz, and finally 48 Mhz with Peteā€™s original code before moving on to work with the USB stuff. This is important in case something starts failing at a higher speed, I will have a better idea where when it starts failing and can work to deal with that before moving on.

Yes, I use the print method a lot for debugging.

Is it just the vector addresses that change, or are there more major changes that will have to be made? We donā€™t really have to use ALL of Peteā€™s code, just the important stuff for sci, i2c, etc if that will make this easier. I already have the sci and i2c stuff brought into my i2cleds project.

I will keep this in mind when I get to a point I can start working with the USB stuff. Assuming for now that everything will work at 48 MHz, interrupts should not take too long considering the original code is designed for 10 Mhz. :slight_smile:

You are the reason I decided to try and go for the 4550 instead of the 4620. I know the 4550 has a bit less program memory, but I think USB is a very desirable upgrade to Peteā€™s design. I am going to create the MCU schematic in Eagle using the 4550 instead of the 4620, which I donā€™t have a symbol for right now.

Your help with this USB stuff is appreciated, Grasshoppah. :smiley:

8-Dale

115

Awww :blush: Your welcome!

I was searching around the SF forums earlier today and guess who I saw posting? =P Hows that USB Bit Wacker - 18F2550 PTH Kit coming for your KM6VV? I am thinking of putting together the 44pin TQFP 18F4455 version of the UBW as a small development platform for future projects. Not to mention its a good chance to learn SMD soldering! But I will use the regular microchip bootloader rather than UBW.

Oh, one thing I forgot to mention. If you are interested in the UBW project and want to test it out for the hell of it, then go get SparkFun UBW schematic off of the SF website. Their version uses the 20MHz crystal. It is almost identical design, actually it IS, to the microchip bootloader. They just have UBW SF bootloader on board which gives i/o and other functions.

-robudude666

116

Did you see Pete or Alan?

Cool! Iā€™ll have to start spending some time on the Spark Fun forums. Iā€™ll get that schematic for sure. I am interested in bootloaders in general, but not necessarily for this project except for the Microchip one possibly. I am more interested in USB for use as a device connected to a Linux (or even Windows ) PC for robotics. I wouldnā€™t use Windows for robotics though, except for Roborealm.

8-Dale

117

Does that give you a hint? :laughing:

118

Hi ?, Dale,

Youā€™ve got it right. Good explanations! I might suggest that the program can simply use a #defined constant for the 20000000 etc frequencies. then one simple equation:

#define XTAL_FREQ 40000000
ā€¦

#define DIVIDER (((XTAL_FREQ/4)/(156*16))/10 = 480.7)

Using #defines for various board configurations or processor types

#if defined QUICK_FLASH_BOARD | PICDEM_USB_BOARD
ā€¦

#if defined (_18F452) | defined (_18F4620) | defined (_18F4550)
ā€¦

But you probably know all that!

Alan KM6VV

119

Yes, for sure. Whatā€™s his user ID over there? You can tell me in private if you want.

8-Dale

120

Hi Dale, all,

I canā€™t keep up with this thread!

I like to run FAST crystals. Helps for baud rate also.

I could have used the high-res A/D for a HAM radio project! I like the EEPROMS, yeah, all different sizes.

Good show! If Pete was using the hardware I2C, then it shouldnā€™t be too much of a problem. Humm, I do have both types of EEPROM, I could use that to test out the I2C code. I implemented SPI EEPROMS on the ARM7 board I did. And I think I can find an old PIC SPI EEPROM project as well.

That long a wait? Yes, In good code, you shouldnā€™t have to do a re-write in order to change a few parameters.

OK, more current, and sometimes you want the RFI kept to a minimum. I just test out the equations at the different clock frequencies, then comment out the #defines for the other frequencies.

I hope so. Iā€™ve ordered some 28 pin dsPICs, although I probably should have ordered 40 pin parts. No matter, easier to mill up a board!

Alan KM6VV