Holy Thread Revival! Alright, so it looks like I finally have some time and cash at hand, so I will be ordering the 28 Pin Board w/20MHz crystal - PIC18F2550 from Spark Fun to experiement with. Are there any good books or online resources that are good to start with? I don't have the ability to go to school for this, although i wish I did. O well, the other thing I need to know for is a good book to learn electronics with. Any suggestions would be helpful!
microchip have great resources on their site, everythihng you need really, but if it dosen't www.piclist.com does the rest. Art of Electronics is pretty much the equivilent of PDR(Phyciscians Desk Referance) for electronics, but not the best book to learn from, sites like play hookey explain quite a bit of the fundermentals, but once u've learnt ohms law, kerchof's and got ur head round silicon junctions there is little to be learnt thats any more than an art form!
Thanks for the advice Animus, I've been a bit busy with school but I'll post once I get a couple projects together, I really want to be able to transfer between a CF card and a laptop HDD. I've found a few projects with people doing this. Have you ever used a MP3 Decoder with a pic? or seen a project involving one?
yup n there are loads of designs on the net, my advice would be getting a DAC + MPEG decoder in one chip solution, some surfice mount soldering might be needed, but its large surfice mount, and you can always buy adaptors.
yea i've been lookin into the mpeg+dac decoders and board size and space would definitely point to all in one solution. Now I was thinking, or rather pondering, what would be the best way of implementing the following: 1) Transferring to Hard Drive from CF 2) Transferring to CF from Hard Drive 3) Driving Dual 4x20 Displays 4) Drive SPI Interface controls (qprox gear) 5) Talking to the microcontroller in the batterypack (charge info) 6) Handling reading MP3s from either the CF or Hard Drive 7) Talking to the USB port at 2.0 speeds (mass storage device) I was wondering about using the SPI bus to have a smaller PIC(master) talk to the USB, and controls, one pic to drive all the hard drive/cf functions and pass data to the usb PIC and a PIC to handle the media playback. (Yes I know this sounds confusing so heres something to help: USB PIC(Master) HD/CF PIC(Slave) MP3 PIC(Slave) I imagine that the hd/cf and mp3 functions could be handled by one PIC, so what would be the fastest way to have the slave talk to the master for transfers?
erm not using a PIC, as much as it pains me to say it! PICs just aren't fast enough at only 8bit to be able to move data fast enough for that kinda thing, Sure you can use an 11mbits USB speed, and do all of the above (appart from 7) using a PIC, but it would be sloooow. Most ICs capable of doing this, aren't easy to use or design with. best way for making a "home made" mp3 player, is letting the transfer to CF or HDD be done by a docking adaptor on ur desktop. A PIC can move data around fast enough to be played, but not much faster! (but you would have some aditional external RAM).
are you sure that the pic can only handle it at 8? I could have sworn that I've seen projects using it at 16 bit. Hmmm, I find it odd tho that Microchip would develop a microcontroller capable of usb2.0 speeds and not be able to utilize the bandwidth. The Controllers with usb2.0 speeds run at 48mhz, and as for the 8bit vs 16bit, etc. I'm not sure. Don't get me wrong, I'm not trying to argue, I just want to ask as many questions as possible because I'd really like to be able to do this. What should I be looking at to determine the speed of the pic for writing to the drive? I'm looking at a pic using 16 data lines, and 8 d. lines to talk to a display that I know is 8 bits. Does that mean that the number of data lines used determines the bitrate? The next question I have is the flow of data. Now, I'm assuming that since the hdd and cf would run at different speeds, so ram would need to be used to buffer the flow between the two, right? And if thats true, it would be necessary to buffer the flow to the usb port as well, correct? Do you by chance know if I have to use all the address lines on a ram chip, since all the examples I've seen used 16 address lines.
USB oh how i hate its naming convention originally (v1) it was low and high speed. low been whats used by most devices, high been used by high bandwidth things (11mbits high bandwidth!) then when v2 came outh (480mbits iirc) then they called it FULL SPEED to run at that, low speed still the same as v1, just only it was certified not to course problems with v2 (which its not ment to as its back complient). so High Speed isn't 480mbits, or is it full speed thats not? Heh i can never remeber, its all on the USB website, which if i wasn't so lazy, i'd check for you. So the 18serie PICs with USB built in, whilst are 480mbits okay (they can sit on a bus thats at that speed) there not really using it. 18series are 8 bit, but have a larger instruction word, but been proper RISC chips, only one word is ever used for any instruction. They run at 48mhz, but theres a 0.25IPC (instructions per clock) so you only get 12mhz instructions per second. At 8bit this isn't *that* much for moving HDDs around designed for 16bit access. (HDDs are so similar to ISA in talking to). Now there are the dsPICs but they are another matter. I'd look at ARM chips for this, depending on your budget. There are many brandings of ARM from intel (see XScale) to Atmel (ARM9 thumb). Atmel's are easy to get into, but the most exciting of their chips they won't let me play with at the uni (MEANIES!). Most ARM9's have a real IPC of about 0.8 Lynx tells me, but they should be a better bet. Esp as some you can run arm linux straight on, so you can write in C, the filesystem been taken care for you. hope you've got a big budget for this project
yes, if its not overkill, i'd look at getting a dev board, but first you really do need to formalise your specification, otherwise u'll be pissing money away.
lol idiot response time: huh? do you mean exactly what i want it to do and how its going to do it? Parts wise?
There may be better ways of doing it, ie there are specially designed chips which all they do is hard disc to USB, take apart an external USB enclosure to find one. If you had one of those you could get the uC to "switch it in" as it were when the device was plugged into a computer and when it is not plugged in, "switch" the chip off the bus. This would save you a lot of headache because then a lot (if not all) of the other stuff can be done by a cheap uC... Rod
exactly what it is your wanting it to do, how long you want it to take you, how much money you have to spend? this is hobbiest yeh? erm, Rod10k. No, in a word. HD to CF is the problem, USB SIEs aren't as hard as that.
I don't really see (maybe that is because I am stupid) what the problem here is? Interfacing with a hard disc using an 8bit atmel uC http://www.robs-projects.com/techdocs/IDE_Interfacing.html Interfacing with a hard disc using an 8bit PIC and a mid-range one at that http://home.nikocity.de/andymon/hfg/Alya/alya.html Now as I see it the main issue is going to be speed and that is something which will be limited by your code effeciency and speed of uC. Rod
Alright, I'm thinking: Musts: - Transfer to and from HDD and CF - USB 2.0 Speed for tranfers to and from the PC - One 20x4 LCD - Simple Controls - Small Size - Minimal Number of components - USB Mass Storage Device compatible - High Speed Copying between HDD and CF Optional: - MP3 Playback (With ID3 Reading) - Second LCD Time doesn't matter, and if this develops into a sellable project, so be it. Otherwise, it's just a crazy hobbiest Idea
Just to check, you do know that there is stuff on the market which does this already? http://www.landisgyr.com.tw/VSV18A_Spec.html I think this is going to be the problem, the high speed bit rather than the copying Rod
Yes Rod, I know they exist. The point is, I want my own. Its just something to tinker with, and just something I've wanted to do for awhile. If we only bought the things other people come up with, why would we need these forums? As for the speed, I'll just have to see how it goes when it gets built. Thanks for the link btw. If it does become a marketable product, I could offer smaller versions using 1.8" drives (forgot those were out)
hey rod as someone whos been reading BT for as long as i've honored the place with my presence, you should know i don't take kindly to people not reading my posts. the ONLY problem is the speed, say you can manage to read from the HDD, and write to the CF in only 24 cycles. (16bit address remeber, thats 4 cycles, just to set that enless your been very sly). So we're looking at 0.5mbits ie, the same speed as naff ADSL. Not very attractive really. (this is USB low speed thou). acdfire look at ARM9/7's then, if you can afford to buy a dev board, do they very powerful if your wanting to learn high end uCs (hey and buy me one too!).
1) Smile 2) I think I may have misunderstood one of your posts when you said that HD was the only problem I took that to mean that actually reading the HDD was an issue rather than the speed. Hence the links posting. Reading it with another hat on I can see it the way you wrote it. 3) The message of how slow it will be was not actually coming through very clearly until your last post Rod
