Split The Job

[AtomSoft]

Ok I want to work on a project soon and it seems large... It will include SD(FAT32), GLCD(or TFT Color) and some other items which will demand alot from the PIC.

I was thinking about SPLITTING the work by introducing some small pics to control some of the other items. Like 1 pic to control all the tft or GLCD work and another for the SD work.

Then have 1 main pic controlling all the other pics. Hence a master. Would this be wise?

I see the benefits as having to code 1 pic with specific information and reducing overall code size in each pic.

I can program 1 pic for SD stuff and have another pic or the master send/receive data to/from it. I can setup multiple timers for each pic this way any time sensitive information is gathered well.

Understand? Would this be wise? Is it a good idea? I think it would also speed up the whole job as 1 pic is processing data another can collect more data and have it ready for when the other pic is free.

I know this will require some good cooperation between the few pics connected. I was thinking about having the master control the slave PICs by using I2C. Mainly because i can assign and use ADDRESSES on the PICs so i can identify them with out having a extra PIN tied up for each slave.

What do you think?

 

[kchriste]

It depends.
If you have one PIC controlling the SD card and another the GLCD, then you may saturate the IC2 buss when you want to display an image from the SD card. Personally, I would just use a single device that can handle the entire job. PIC32 or the ARM maybe?

 

[duffy]

It's called "distributed processing" and some people swear by it. Anything more complicated than a toaster usually has more than one processor in it anyway. There's a real economic advantage if you can do it because the cost of a chip increases GEOMETRICALLY with the size due to some complicated issues with point defects and yeild.

But in practice, it's a pain in the ass. It's like cleaning a window, the problem is always on the other side.

 

[bacterozoid]

You can do it - I'm doing this with two Atmel chips in a project right now - one chip controls a clock, most inputs, and displays, the other reads an SD card and streams MP3s out. I communicate between them with a few simple comm lines and SPI - the slave AVR checks to see if it's selected every now and then, then gets input from the master. I first send a status code to determine what sort of information is coming, then deal with it appropriately. It works very well and is very easy to expand.

You mentioned you plan on using FAT32 on your SD card...are you sure about that? I'm pretty sure some of the larger cards use FAT32, but I think maybe you meant FAT16. Good luck either way!

 

[AtomSoft]

Yes FAT32 because i tend to use 2GB cards with XP. And i know i can use FAT16 but FAT16 is becoming a dead thing now. I think i want to move up slightly which is FAT32.

There are already great code from Microchip and other places which i can utilize.

Duffy i like that comment...
"It's like cleaning a window, the problem is always on the other side."

Can i use it ? lol

For the price of 1 PIC32 i can but a few if not 4 PIC18Fs which can handle it all.

 

[Leftyretro]

Well I guess it's kind of a bipolar choice.

On one hand, man with one watch always knows the time, man with two or more watches never quite sure.

On the other hand, we don't write applications as one long series of lines of code, we break it up into separate functions and subroutines that can easily be tested and proved out independently of the larger application. Why wouldn't that work the same on a hardware module basis?

I also guess a lot depends on the inter-module communications protocol you come up with. It's more then just having the electrical paths connected and all being I2C networked, there has to be a reliable and rugged protocol that won't tie up the whole 'network' waiting for something that isn't going to happen.

Lefty

 

[AtomSoft]

lol yeah but thats also true with 1 PIC or ARM device. Like a forever loop. thats where the watchdog comes in. Or infact i can have a timer count. Not 1 thing should take a complete seconds to achieve. If something takes more than a second to complete reset or restart the operation. I can have something that resets the timer on a function.

In each function set the timer to 0. And have it count to 1 second and if it reaches 1 second then reset or restart the last operation.

Remember not every product is full proof out there. There are always bug so there will most likely always be bug fixes.

 

[Noggin]

PIC24 or PIC32 and use Microchip's Graphics library and SD routines. I'm doing a project right now with a PIC32, SD card, RF transceiver, and 320x240 GLCD. The only problem I've encountered is that displaying a full screen graphic takes longer than 5mS.

Synch_Time( void )
{
// this function waits for a 5 ms timer to expire
	if (timer_expired)
		loss_of_real_time_error = TRUE;

	while (!timer_expired)
		; // wait

	clear timer interrupt
	restart timer
}

void main( void )
{
	Synch_Time();	// synch to 5ms timer
	// run any functions that must be performed often here

	switch (task)
	{
	// run any functions that don't need to be performed often here
		case TASK_1:
			Service_Application();
			break;

		case TASK_2:
			Service_Sd_Card();
			break;

		case TASK_3:
			Service_Lcd();
			break;

		case TASK_4:
			break;

		case TASK_5:
			break;
	}
	if (++task > TASK_5)
		task = TASK_1;
}

void Service_Lcd( void )
{
	GOLDraw();	// function from Microchip Graphic's library that causes any objects that need to be drawn to actually be drawn
}

void Service_Application( void )
{
#define SPLASH_DISPLAY_TIME		3000/TASK_DELAY_MS	// TASK_DELAY_MS is 25 (each task runs every 25 ms) so this time is 3 seconds
	switch (app_state)
	{
		case APP_STARTUP:
			InitLcd();
			PutImage( (void *)splash_image );
			timer = 0;
			app_state = APP_DISPLAY_SPLASH;
			break;

		case APP_DISPLAY_SPLASH:
			if (++timer == SPLASH_DISPLAY_TIME)
				app_state = APP_CREATE_WIDGETS;
			break;

		case APP_CREATE_WIDGETS:
			StCreate( ..... );
			app_state = APP....;
			break;
		.
		.
		.
	}
}

 

[Nigel Goodwin]

I know this will require some good cooperation between the few pics connected. I was thinking about having the master control the slave PICs by using I2C. Mainly because i can assign and use ADDRESSES on the PICs so i can identify them with out having a extra PIN tied up for each slave.

What do you think?

I would say I2C is the worst possible choice you could make, it's complicated and it's slow - and your requirements don't need it. Assuming you want to use more than one processor?, just use a separate one for the display and send it serial data from the main PIC. You could also use the display PIC to read any keys, and send the keyboard information to the main device.

 

[Noggin]

just use a separate one for the display and send it serial data from the main PIC

I don't really like that idea. He's probably going to end up using a PIC24 or PIC32 to drive the GLCD as that is what Microchip's graphics library will run on. PIC32 can run at 80 MHz and has a 16 bit wide PMP compared to PIC24's 32 MHz and 8 bit wide PMP. The PIC32, in general, will be over 4 times faster than PIC24 for writing to the GLCD. Of course I don't know what his requirements are, but the PIC32 is probably fast enough to handle whatever he needs (so long as he can wait for a full screen to be drawn).

PIC32 with small flash are under $10 from Digikey, PIC24 is slightly cheaper. But if either of these are used to drive the LCD, there is a good chance (without knowing the requirements of the project I probably shouldn't make that claim ) that it can handle the rest of the project's demands.

 

[AtomSoft]

i will use a PIC18F4480 to run the GLCD and a PIC18F4620 to run the SD stuff.

Mainly for memory and not speed. I might use UART to send data. But now am thinking about SPI.

I definitely need a way to select a pic and determine if the master is busy. So i need to have a Busy Flag created so when its >0 i can tell the other pics to wait.

I will try to figure out what exactly i need in the project.

If i use a Color LCD it may be this:
SparkFun Electronics - Graphic OLED Color Display 128x128 - Carrier Board

As you can see it requires a lot of pins. which is another good reason to use seperate pics. I know i can use 1 PIC32 still but the DIP option is gone then. I cant prototype a QFN or LQFP right now. So its out of the question.

I will need to use a single PIC maybe the 18F4620 for that since it has more memory than the dsPIC30F4013. And just use SPI. SPI is nice because of the Chip/Slave Select stuff.

 

[3v0]

It makes sense to use a seperate pic for the display if you put the code to drive the display and the data to be displayed on that pic. Think of it as a custom display device. It would require little communication with the main processor because you only tell it what to display and no not how to do it.

 

[DirtyLude]

Just have a single master request info from the peripheral chips. This is no different than say the serial LCD backpacks, or serial controllers for graphic LCD's already out there. There's also serial chips for FAT32/SD card access. It's definitely not hard to offload tasks to these smaller chips and make them yourself.

That original LCD backpack I made up a couple weeks ago works as an I2C slave to control a simple text LCD. The concept is exactly the same, but your just working on a bigger scale.

 

[AtomSoft]

I wanted to do the SD/FAT32 Card stuff myself and not use a IC for it because of the price. I mean its going to kill me to have to buy those ics and then solder them.

I can use "Microchip MDD File System" and basically make my own FAT32/SD Card IC for a less then half the cost of that IC:

SparkFun Electronics - DOSonChip QFN

But then you see the features of it and like damn i can save alot of time and errors using this.

So my thought is i might use it since its a full featured items and can handle the SD and FAT32 stuff. And now it can handle the SDHC also so thats a wow. For $13 its not too bad. I dont know what do you recommend for the SD/FAT32 side? Should i just go for that "DOSonChip QFN" ?

I mean im sure i can make a adapter in eagle in like 2 minutes. and make it a SMD addon. Like the below picture . I love these SMD devices:

 

[DirtyLude]

I have the DOSonCHIP and I don't care for it. It's slow and if I want to use this stuff on more than one project I have to buy more chips. There's no actual protocol documentation for the DOSonCHIP, they tell you to look at the API that they wrote in C, if you want to find out how to use the chip. Heck, if you want the breakout board and chip that I made up you can have it.

I wasn't actually saying use one that you bought, I'm just saying the concept is already there. I used the FatFS open source library as the basis for my FAT32 routines and it's working well. I can make up a chip similar to the DOSonCHIP, myself and have full access to the firmware. Once you get the functionality working, you should be able to do the same.

 

[AtomSoft]

I swear i was thinking on learning that FatFs thing. They have a TinyFs also i think thats the name. I have downloaded the code also. Im not sure on how to implement it yet as i never really read it lol

You willing to share some knowledge on it?

 

[DirtyLude]

Ya, it wasn't that difficult after I got passed doing the stupid mistakes I do when starting every project. I don't use the same microcontroller you do, so I can't help you that much. There's actually sample code on the FatFS page for a PIC. I'm not certain what compiler it's using. You should be able to get everything working with the code only editing the hardware specific routines, which in the sample code is in MMC.C. If you are having trouble I would extremely simplify the main process of the sample code to just initialize the card, open a file, read the file, then close it. Get rid of all the confusing serial test interface stuff. This is the main I used when just doing simple testing:

void main ()
{
	unsigned char filename[40] = "TEST2.TXT";
	unsigned char res, b1;
	unsigned int result;
	unsigned int count_in = 10;
	unsigned int count_back;
	DIR dir;				/* Directory object */
	FIL file1, file2;		/* File object */
	FATFS *fs;

	//result = disk_initialize(0);
    f_mount(0, &fatfs);
	res = f_open(&file1, filename, FA_OPEN_EXISTING | FA_READ); 
    res = f_read(&file1, Buff, count_in, &count_back);
//	res = f_open(&file1, filename, FA_CREATE_ALWAYS | FA_WRITE);
//	res = f_write(&file1, Buff, count_in, &count_back);
	res = f_close(&file1);

}

FatFS, as far as C programming goes is fairly complex to follow. There's a lot of error checking built in to the routines as well. TinyFS comes in at about 12k of ROM space on my chip with only the read routines. The compiler I use does not optimize that well, so I don't know what it will come out to on yours.

The Logic analyzer was a big help with this. I could not have got it all working without being able to see the SPI back and forth, and the timings.

Anyway, I think you'll be happier having your own access routines than relying on a third party. I've gotten my SD card access routines ready and my HTTP server is working, so now I just have to tie them together to serve pages off the SD card and I'll be ready to make up a final board for my embedded server project, and I'll be happy.

 

[DirtyLude]

The DOSonCHIP breakout I made. It's already conformal coated, and I never bothered putting the time keeping crystal on it. The chip was soldered/unsoldered a few times, which is why it looks a mess. I kept thinking it wasn't sitting properly because I wasn't getting the right data from it, just garbage, then I found out the latest version of the firmware only supports a command packet structure, which is different than the original documentation they put out shows.

 

[AtomSoft]

wow good job!

Ill be sure to try that above code as a test thanks. It seems simple to use it but heh i am always mistaken lol

 

[Noggin]

Whatever micro you end up going with, still take a look at Microchip's library. It would make using PIC24/PIC32 almost a no-brainer once you get it set up but it should be portable to lower end micros as well. Even if porting it would be more difficult than rolling your own from scratch it can still convert any Window's fonts or bitmaps to compilable .c files for super easy inclusion to your project. If you have images on a SD card to be displayed the bitmap converter probably won't be of much use to you, but the fonts may be.