Fair enough.freeskier89 said:Yeah it would be a lot easier to do on a PDA, but for what I am doing, it would look a lot better if I designed the thing from scratch, and not to mention, I learn a lot more by designing it.
freeskier89 said:About the SRAM/ I/O issue, I am going to be extremely tight on I/O. I have 65 to work with, and at the moment it looks like I will be using 65 :S. Potentially, I could hook up the data or address lines to a PISO Shift Register, but I that would make things more complicated, and would decrease performance considerably. Any thoughts? At the moment it looks like I will be fine on I/O, but as I come closer to actually drawing the schematics I am sure I will need more.I might have to hook up my status leds and such to the I2C bus lol, wouldnt that be fun. Here is the breakdown for what is using the I/O at the moment:
Well, there are CMOS sensors which have LCC style edge pinouts instead of BGA's. Those are easier to solder by hand.freeskier89 said:I too was concerned about the BGA soldering. Luckily with a bit of research, it looks like it isn't too daunting of a task using a hot plate and a professionally made pcb. I doubt it will be painless though. I think soldering the iCSP44 package for the camera will be a bit more difficult yet because I believe they have much tighter temperature tolerances.
freeskier89 said:I was planning on loading the font for the graphic LCD from the SD card to the RAM upon start up. The FPGA could then grab each character from the RAM when it needs it. I will probably use a simple, non-antialiased, 5x7 bit font to keep it simple. The graphics will be stored and used similarly.
The whole GUI is going to be very minimalistic and will be nowhere near the complexity of a cell phone. Pretty much it will probably incorporate a startup screen, and a page showing the preview from the camera(not mandatory), along with a few dynamic textfields. Thats about it.
I would like to stay away from a MCU other than a PIC if at all possible, mainly because I do not really want to spend more money on a new programmer and the like. What exactly makes UIs easier to do on MCUs?
Initially I was thinking of using PSRAM with an 8 bit bus, but I switched to the 16 bit bus after I never found ram with the smaller bus. I will have to look into that a bit more.hjames said:Well, I'd recommend that you switch to a 8 bit bus for the PSRAM - unless you really think you need the bandwidth. Or add some address latches on the high order memory bits(i.e. the ones you don't need to change often). Alternatively use a DRAM chip and just deal with the added memory controller complexity, but with only half the address lines.
The only 1.3MP SoC camera I could find with the LCC package was the OV9620. I have looked extensively on the net to find a place I can buy them to no avail. No one want's to sell them to a studenthjames said:Well, there are CMOS sensors which have LCC style edge pinouts instead of BGA's. Those are easier to solder by hand.
Hmm... So do you suppose I should use the fpga for the main image processing and not much else? Then I could use a powerful MCU to display info on the LCD and control the basic user interface. I do not believe PICs are quite powerful enough, no? Maybe some of the 18 series ones would work. What do you think?hjames said:Well, having a font 'bootloader' makes things that much more complex, plus trying to hit the RAM (which might be in the middle of an image operation) to update the display means having a pretty complex state machine setup along with the required addressing/oddball multipart DMA setup... Have you tried coding the HDL that would do this yet, because it'll be an insane PITA. (BTW, it would probably be a better idea to hardcode the font into the FPGA's SRAM blocks, but it would still be pretty painful, and I can imagine the logic to do this taking a good 30% of the FPGA to implement).
Generally one has a uC in the system to handle all the stuff that happens at "user" speed - UI controls (getting a FPGA which is running at MHz speeds to deal with sub Hz user interactions means a lot of large delays/counters), display updates (having 10's of lines of C code or 100's of lines of assembly is much less painful than trying to debug a FPGA). As well as things that a FPGA is just bad at - "allocating" space in the SRAM for image buffers, initialization command sequences for the flash/sensor, or just doing more complex actions - storing multiple images in multiple buffers at different resolutions at different times, clipping subregions, formatting the images on the SD card with the correct image headers, etc.
Well, that's easy- just don't connect them! (other than having some pull-ups of course). Alternatively, there's nothing wrong with having a non-standard bus width.freeskier89 said:Initially I was thinking of using PSRAM with an 8 bit bus, but I switched to the 16 bit bus after I never found ram with the smaller bus. I will have to look into that a bit more.
Digikey seems to have a couple MT9T001P12STC's in stock. (3Mpixel, LCC packaging). Mouser used to carry some of www.st.com 's image sensors, but they seem to have stopped. (Surprise, cell phone parts don't stand still...)freeskier89 said:The only 1.3MP SoC camera I could find with the LCC package was the OV9620. I have looked extensively on the net to find a place I can buy them to no avail. No one want's to sell them to a student. I think the iCSP44 package will be alright, again the hot plate "should" be alright. Hmm... So do you suppose I should use the fpga for the main image processing and not much else? Then I could use a powerful MCU to display info on the LCD and control the basic user interface. I do not believe PICs are quite powerful enough, no? Maybe some of the 18 series ones would work. What do you think?
I read you loud and clear nowhjames said:Well, that's easy- just don't connect them! (other than having some pull-ups of course). Alternatively, there's nothing wrong with having a non-standard bus width.
I checked out the MT0T001s but ruled them out mainly because it isn't a System on a Chip (SoC) sensor. I could do brightness/contrast/level adjustments on the FPGA, but I don't want to. I will be doing enough on it as it ishjames said:Digikey seems to have a couple MT9T001P12STC's in stock. (3Mpixel, LCC packaging). Mouser used to carry some of www.st.com 's image sensors, but they seem to have stopped. (Surprise, cell phone parts don't stand still...)
Alright thanks. I will definitely look into which PIC will be best for my needs. For storing the images/backgrounds, I was going to store this on the SD card. I know, I know, it sounds a lot like overkill. The reason is that it could be easily plugged into the computer to modify, and I could easily has it enumerate as a USB mass storage drive using a USB2229 from SMSC. SMSC distributors seem to not want to email me back, so I might not be able to use it. It might be a bit easier to have a smaller flash IC enumerate as a mass storage device using a USB compatable PIC (like the 4550), but to be honest, I do not have the slightest clue how to do that yet. I have not done a thing with USB. Does anyone know how feasible this is?hjames said:An external PIC would be the safer approach - FPGA resources are pretty limited, and using them to do UI can definitely be a misuse of resources. I think nearly any uC with at least a Kbyte of ram would be more than enough - a 5x8 character map needs ~.5KBytes of ROM space at most, and that can be trimmed down pretty easily. Bigger chunks of data(images/backgrounds) can be retrieved from the EEPROM, or maybe even the FPGA's configuration flash via the FPGA.
It's probably easier not to use the mass-storage interface. That implies that you know how to implement a VFAT style filesystem in firmware. Just put together your own RS232 type interface - send some commands to the FPGA and translate them to/from the SD card, (or some other SPI/I2C Flash storage).freeskier89 said:For storing the images/backgrounds, I was going to store this on the SD card. I know, I know, it sounds a lot like overkill. The reason is that it could be easily plugged into the computer to modify, and I could easily has it enumerate as a USB mass storage drive using a USB2229 from SMSC. SMSC distributors seem to not want to email me back, so I might not be able to use it. It might be a bit easier to have a smaller flash IC enumerate as a mass storage device using a USB compatable PIC (like the 4550), but to be honest, I do not have the slightest clue how to do that yet. I have not done a thing with USB. Does anyone know how feasible this is?
Dunno, calculate what sort of bandwidth you'll need and figure out where the display should be connected to. However, since you mention it's a SPI display, you'll probably want to connect it to the FPGA mainly because you'll be able to implement a faster SPI port on the FPGA than on the PIC. And if you use a byte-wide interface between the PIC and FPGA, you'll be able to pipe data into the display faster than if you connect it directly to the PIC.freeskier89 said:Hmm... I was just thinking about the PIC and the GUI. I haven't done the math, but out of just guessing, Between going from the Camera to FPGA to RAM to PIC to LCD, that really would not leave much room for a 15-20fps low resolution preview from the camera because the FPGA would have to dump all of the data into RAM then, the PIC would have to reread it then shove all of it to a region of the LCD. Most likely it would be a headache.
I agree. I believe I will just use serial flash storage and have a custom C# app on the computer control whats on it rather than the mass storage interface. One of these days I bet I will write some FAT libraries, but it might be a bit too time consuming for this project.hjames said:It's probably easier not to use the mass-storage interface. That implies that you know how to implement a VFAT style filesystem in firmware. Just put together your own RS232 type interface - send some commands to the FPGA and translate them to/from the SD card, (or some other SPI/I2C Flash storage).
I am actually using a Pluto III board from FPGA4Fun.com, so I really am limited to using the serial port for that.hjames said:I'd probably spend some time trying to figure out how to reconfigure the FPGA configuration device from the USB port, but that isn't too critical.
The LCD I will be using actually does have the option of becoming a parallel display, but I wanted to use SPI to save I/O. This is the structure I was thinking of using for displaying stuff on the LCD:hjames said:Dunno, calculate what sort of bandwidth you'll need and figure out where the display should be connected to. However, since you mention it's a SPI display, you'll probably want to connect it to the FPGA mainly because you'll be able to implement a faster SPI port on the FPGA than on the PIC. And if you use a byte-wide interface between the PIC and FPGA, you'll be able to pipe data into the display faster than if you connect it directly to the PIC.
Also be aware of the ram hierrarchy. You'll probably be able to keep the display framebuffer on FPGA without touching the external SRAM. Alternatively you might want to implement some sort of "overlay plane" to display monochrome text info (i.e. use 1 bit per pixel).
Yeah I was going to use a Regulated 5V Charge pump from TI (TPS60131), but you made me realize that I would just need a 3 or 3.3V boost converter, because I can't think of anything I would need the 5V for.hjames said:BTW, you have 5V supply scribbled down there - I'm assuming that you've got the other power supplies budgeted out as well? Nearly all parts require 3V power, and Lithium batteries have an annoying habit of droping below 3V when they're ~70% discharged - thus needing a buck-boost converter - or alternatively set make the main logic power supply run below the Lithium cutoff voltage.
No, not totally yetSo have you figured out how you're going to build this thing? A 4 layer PCB is the utter minimum required, and laying out a board like this would take me a week and some (and toss in a couple days to get the full schematic built up).
considering the amount of *fun* you're going to run into... I'm not sure if it's terribly humane of me...Thanks again for all of your guidance, it is really helpful to me
There is absolutely no place in town to do this (I live in a rural town of about 8000 people, in the least populated state none the less). I am going to hopefully talk over the phone to some EE/CE professors at the state university tomorrow who might be able to hook me up with someone.hjames said:If you can find some local place, you might be able to talk someone into just mounting the parts for you on the spot - it should only take a couple minutes to do it, especially if there's only 1-2 parts to do.
I tried working with 7 mil traces just now, and that should work fine. If you put the 8 mil holes and the 25mil copper pad in the optimal position between the pads (In the middle of the square that 4 pads form), it looks like I will have ~1.3mils of spacing between the pad and the via, which is hardly enough clearance. I was able to get all but 4 traces from the center away from the VFBGA package on a single layer. I will have to work at it a bit more I guess. All of the documentation I can find on escape routing focuses on normal BGA packages, not Very Fine BGAs or CSPs. I will try one more time now to get the traces away from the RAM.hjames said:You ~should~ be able to do everything using their cheap 4 layer service. I think the via's are almost small enough, and 7 mil tracks ~may~ be enough. If you can tent the vias close enough, it might work. In any case I'd budget ~$400-500 for the board by itself.
Thats a good idea.freeskier89 said:There is absolutely no place in town to do this (I live in a rural town of about 8000 people, in the least populated state none the less). I am going to hopefully talk over the phone to some EE/CE professors at the state university tomorrow who might be able to hook me up with someone.
freeskier89 said:I tried working with 7 mil traces just now, and that should work fine. If you put the 8 mil holes and the 25mil copper pad in the optimal position between the pads (In the middle of the square that 4 pads form), it looks like I will have ~1.3mils of spacing between the pad and the via, which is hardly enough clearance. I was able to get all but 4 traces from the center away from the VFBGA package on a single layer. I will have to work at it a bit more I guess. All of the documentation I can find on escape routing focuses on normal BGA packages, not Very Fine BGAs or CSPs. I will try one more time now to get the traces away from the RAM.
Edit: Wait a minute... PCBexpress says the 25mil copper pad around the via is the recommended size for through hole continuity. If I am using it as a via, wouldn't that not apply?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?