Split The Job

Status
Not open for further replies.
heh nice work on that adapter. I dont do my own boards so cant test it as of now lol. (if i had the chip)

I will try this FatFS thing and see if it works well and is usable

Here is a picture of my sd card it was a smd part but i bent the pins and they fit a .1" spacing :
 

Attachments

  • sda.jpg
    569.1 KB · Views: 295
  • sdb.jpg
    461 KB · Views: 266
never tried microchip glcd library but mikroC glcd library works with pic16F* chips without a problem... do not see why microchip requires pic24/pic32 to run ????

driving GLCD directly (check examples):
**broken link removed**


driving GLCD via SPI (check examples - there's also schematic for the adapter board):
**broken link removed**
**broken link removed**
**broken link removed**

The SPI driver actually uses SPI port expander (MCP23S17) instead "uC with firmware to drive the GLCD"

 
Last edited:
If i decide to use the PIC then the "Microchip MDD File System" is my choice...

If i get deep into it and use a ARM7 uC then i will use the FatFs code since its more portable. I might be able to port the MDD FileSystem from Microchip to the ARM7 uC but will be more work i think lol
 
One additional info about the "split the job" .. I often do it, sometimes I use I2C sometimes SPI, I2C is not slow if you have uC with hardware i2c and there's no "bus contention" as you have only one master that speak with only one device at a time anyhow... I do not know uC with hw i2c support that cannot support 400Kbps, I managed software i2c at 100Kbps, and most of them support the 3.4Mbps anyhow ... even 100Kbps is enough for 99% of applications (yes, even for GLCD if you do not send "picture" from the main uC but just "commands" to the slave uC that will draw lines, circles, arrows, txt... that will load pictures from [ee]prom ...) ... Having a "interrupt" line is sometimes necessary, sometimes you can OR all interrupt lines from all devices to one and "ask all devices which one triggered alarm" or you can use multiple input lines to fetch them (thanks microchip for "change on portb").

In case you need more then 100Kbps, think are you sure you are splitting the job properly (why draw line on main uC when you can send command "draw line" and slave uC can spend time drawing it).

For example, I have small uC driving motor's (pwm). The same uC fetches the signal from encoders and automatically adjust the pwm dc, has 2 proximity detectors, receives the commands from the main uC via i2c. The commands are "full speed ahead until obstacle", "go right while obstacle" etc. The commands can be "stacked", "purged" etc ..
 

Cannot help you there, nor give advice, I use MMC cards to "log" stuff that is "much more data then eeprom can hold" or when "usb interface to computer" is not feasible (device is unmovable, computer is not near .. etc)...

As I log *mine* data to the card, I will need *mine* application to read that data and present it (for example the temperature and pressure for last 6 months measured every 15minutes - the recent project, final version is with 2 eeproms but first version was with mmc card).... As *mine* application is reading the data, data does not need to be "on fat disk in text file" I write data directly to MMC card, raw, with checksum (even double it sometimes for safety), then I write app to read that data directly from the card on windoze side...

The benefit is:
- full control over the data
- no overhead to implement fs functions (code on uC is smaller)
- speed of execution (code on uC is faster)
- speed of development (code on uC is written very fast)

The downside is:
- you have to implement low level IO read from card so you are somehow limited by the languages accessible (you cannot raw read the card from perl/php/java on windows for example)
- you have to have client application installed on the computer to retrieve data, you cannot use "any" computer to backup the content of the card
 
You said what the parts were but not how they would be used. Without that all the info given is based on what the responder see's in his own head.

If you use the memory card to hold images for the display it would be better to place them on the same processor. Get one processor fast enough to handle them both and avoid the extra overhead of TX and RX the data.
 
I was thinking about making my own File System. It was to be called AtomFs lol laugh its ok

I was going to base it off the FAT system but with less headaches. I just dont know how i would access the data from windows. I would have to make it plug into my PC via Serial or USB or Serial to USB adapter which i use now.

Then i would have to make a program in C Express or VB Express. Which sux if you ask me; its over complicated lol.

I have to actually think this over very well. Ill post back soon with a choice. If i decide to create a Fs i will make it OpenSource of course. It wouldnt be special but heh it would probably help alot of people.

Im thinking tho.....

What is a good way to make a Serial to USB device. Like what IC? I dont want to write code for it. Im already overwhelmed and heh im lazy too.

I heard something about a FTxxxxx or something i forgot tho.

EDIT:
USB to UART Bridge - FT232RL

i think thats it. Is that a good IC?
 
Last edited:
arhi said:
never tried microchip glcd library but mikroC glcd library works with pic16F* chips without a problem... do not see why microchip requires pic24/pic32 to run ????
Click to expand...

Its just not supported natively. It'll work, but you have to rewrite some functions. The only thing you have to do with the library when using a PIC24/PIC32 is tell it the resolution of your screen, portrait or landscape, and init code. It uses the PMP to send the data. If you want to rewrite it to use some other peripheral you definitely can.

AtomSoft said:
USB to UART Bridge - FT232RL

i think thats it. Is that a good IC?
Click to expand...


I haven't used the FT232RL but I have used an FT232BQ and SiLabs CP2102. Both are good chips, but the FTDI part I used required an external crystal or resonator. I suspect that the RL is just as easy to use as the BQ so I'd say yeah its a good chip. I never had problems with either of them.
 
Last edited:
AtomSoft said:
USB to UART Bridge - FT232RL

i think thats it. Is that a good IC?
Click to expand...

It's a basic USB to serial connection chip. I've used it quite often. You can access the chip as a virtual com port using a term program, or there are dll functions that you can access with your windows programming language to talk directly through USB. There are examples on the FTDI website for access with Vis BASIC and C#.

It's technically the same as just using a USB to RS232 cable, but a little more sophisticated. Another chip that only comes in SMD, though.
 
I dont want to use the cable for 1 reason. If i mas produce something or just make a few for family i dont want them to reply on a special cable. I rather have it built in. Also the cable cost more than the IC lol (i assume because they have a similar IC in the cable)

In about 1 month i will start making my own boards. I will be using the Photo Method and i hear its perfect for SMD parts.
 
Last edited:
You need one chip per project and you only need one cable for multiple projects, but that's not the point. Obviously you want direct access if it's a final product. Like I've said, I've used the chips quite often. It's a good USB solution. The RL does not require any external components except some small caps.

The method of making the boards doesn't matter. Toner transfer, PnP, photo resist, they all make good boards for SMD work if done right. Use whatever you feel comfortable with. I just use standard toner transfer with picture paper.

I posted both these in other threads, but these projects use the FT232RL. I wrote a Vis BASIC program a long time ago to control the fan controller, and I played around with a C# program to do basic read and write to the LCD controller, but Windows programming isn't my thing and I'm not very good at it. pics attached.
 

Attachments

  • 20090123-lcd-backboard-003.jpg
    165 KB · Views: 306
  • fan-control-bottom-02.jpg
    199.6 KB · Views: 340
Last edited:
nice job!

"You need one chip per project and you only need one cable for multiple projects, but that's not the point."

If i give or sell some of these to family or friends then heh i have to get them all that wire lol
 
DirtyLude im having a issue with the TinyFatFs its in the Integer.h im sure most can solve this... i think at least most lol

Code: 
/* Boolean type */
typedef enum {FALSE = 0,TRUE = 1} BOOL;

Im getting a "integer.h:27:Error: syntax error"
 
If your compiler doesn't have enumeration declaration the same way, just get rid of that line all together and replace anywhere in the code that says 'BOOL' with 'char' or 'unsigned char'. They are just trying to be fancy.
 
lol ok. I fixed it with this tho:
Code: 
typedef char _BOOL;
#define BOOL _BOOL
#define FALSE 0
#define TRUE (!FALSE)
 
heh im too jumpy to try this lol id rather rip it apart and take usefull functions and make them my own. This including other stuff and the naming they use suck.

Id rather see how they do it somewhat and make one from scratch. Like this is very useful:

Code: 
/* Definitions for MMC/SDC command */
#define CMD0	(0x40+0)	/* GO_IDLE_STATE */
#define CMD1	(0x40+1)	/* SEND_OP_COND (MMC) */
#define ACMD41	(0xC0+41)	/* SEND_OP_COND (SDC) */
#define CMD8	(0x40+8)	/* SEND_IF_COND */
#define CMD9	(0x40+9)	/* SEND_CSD */
#define CMD10	(0x40+10)	/* SEND_CID */
#define CMD12	(0x40+12)	/* STOP_TRANSMISSION */
#define ACMD13	(0xC0+13)	/* SD_STATUS (SDC) */
#define CMD16	(0x40+16)	/* SET_BLOCKLEN */
#define CMD17	(0x40+17)	/* READ_SINGLE_BLOCK */
#define CMD18	(0x40+18)	/* READ_MULTIPLE_BLOCK */
#define CMD23	(0x40+23)	/* SET_BLOCK_COUNT (MMC) */
#define ACMD23	(0xC0+23)	/* SET_WR_BLK_ERASE_COUNT (SDC) */
#define CMD24	(0x40+24)	/* WRITE_BLOCK */
#define CMD25	(0x40+25)	/* WRITE_MULTIPLE_BLOCK */
#define CMD55	(0x40+55)	/* APP_CMD */
#define CMD58	(0x40+58)	/* READ_OCR */

Saves me time and effort lol
 
Last edited:
Whatever floats your boat, but the code is very robust. There is lots of internal error checking and optimization. I have no interest in playing with it beyond what gets my project done and it only took a few tweaks of the main code to get it to work under my compiler. My only issues were the hardware dependent part. I was also pretty surprised with the ROM usage. It's can certainly be trimmed down in terms of functionality if you want to get the codespace down. The full FatFS library takes almost 24K of ROM space and my development chip only has 24K total. The final board for the embedded web server I'll be using a 64K part and the TinyFatFS in read only mode, which I mentioned will use 13K of it.

So my webserver will serve up one page so far, but after that it gets stuck for some reason. I have no idea why. It wont close and listen on the port properly again. Oh well, no time to work on it now.
 
heh the code sample for FatFS is only for the full FatFs. The SRC for the both doesnt come with any initialization code for SD or MMC or ATA as i would have assumed.

Its basically a BARE and i mean BARE skeleton for it all. And for a skeleton to claim to offer alot it kinda sux. I still have to make the READ SECTOR, WRITE SECTOR and many other routines myself.

The Microchip version works well. It does take a lot of space but took me about 5 minutes to alter it for my 18F pic
 

Not certain what you are talking about. The MMC.C or DISKIO.C is the same for both FatFS and Tiny FatFS and is included in the PIC sample code. The only thing you have to write is the SPI initialize, read value, and write value routines, which for the PIC are already written. You certainly don't need to write any sector read or write routines.

Even I was able to take the MMC.C from the AVR sample project and just modify the hardware specific instances to get FatFS and Tiny FatFS working on my own uC.

If you have the Microchip code working, then that's all that matters. Go with what you know for sure.
 
Last edited:
Status
Not open for further replies.
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…