ugh... had to retype this... lol Well, firstly I would like to thank Hazer for his design which has inspired me to do this. his thread here. Well, I suppose you want a description of what I am planning on doing huh... I will be using a basic stamp to interface with a graphical LCD/VFD. It will have a separete region for each channel. Each channel will be a separete space that has little dots flying into the middle. Kind of like the windows starfield screensaver. The dots will be moving faster as the output level is higher for each individual fan channel. I will be using one button to control which fan is currently being controlled by the other. The other button will be go through the fan speed settings. I hope to make it so that the speed it bounced back and fourth. eg "1,2,3,4,5,4,3,2,1" That way it will be easier for turning the volume of airflow up and down. I will have a border around each region of the display to separate the fan channels, then make the border thicken by one pixel all the way around for the selected fan. Well, actually the border will grow thicker by widening inwards, if you know what I mean. I hope that all makes sence, been answering phone calls lke crazy while writing this. But I managed to get this far Feel free for to post any comments and suggestions. I will have more time to research this next month, as I am working full time right now. I wouldn't mind hearing some ideas as to what typer of LCD/VFD to use. Keep in mind I am on a bit of a budget and live in Canada. I don't mind ordering from the US though... I think I hope to make this fit in one 5 1/4" bay. I hope thats possible, since I need to have two buttons there. edit: Thanks for any help. edit2: maybe use this LCD from allelectronics.com. Anyone use this before?
Hey i think there are going to be 3 main issues with your current plan (sorry!) The first which basically is them all, is the mcu choice, the MCU you use should always be determined by which will be easyest to solve the problem with, for this, it won't be a stamp these are in essanse, a crippled pic with some eprom on the end. if your doing PWM, then you have problems using the fan sensor built in. My prefered way round this is to not use PWM in the first place, it sounds worse than running the fan at full speed normally. A cheap serial DAC with a darlington pair, or a variable power regulator are often the best bet, interfacing these with a stamp, is going to be easyer in ASM (precise timing needed). The LCD its a matter of preferance, i prefer the SED133x to the Tosheba, but that shouldn't be a problem, thou its size might be fitting that one in a bay that small! Animation, from stamp basic to a graphical LCD with a simple partical effect like that, well its adventurous i will grant you that. And last but not least, sensing the fan speed, once again the MCU will make this hard, as you'r animating the LCD at the same time. Doing this on ONE PIC18Fxxx would be a challenge, an Atmel ATmega128 might be a better bet.
one last thing, this is a me thing thou, i wouldn't trust some interpreted language, to run my CPU fan. I would feal safer leaving a 10 year old boy in jacksons wardrobe. At least the kid would only be given drink, rather than slowly cooked from the inside out. You might find it better if you use more than one micro, one for the LCD and user input, and one for the fan control. This way, if you used the hardware SPI for communication, you would find it much easyer to logic anailse, and bust bugs in the fan control, add emergancy FAN0 has stalled, slam full power on code etc.
Good idea.. actually, I was just thinking that too. thanks for the advice. and yeah, I know what ya mean... my p4 is oc'd by around 940MHz.. I will have to implement an emergency on for the fans. and make it so that they all start up at full power, then go to a stored variable. that is of course if I can figure out how to use the write back feature on the pic I choose, if indeed it has it. Or maybe use an external circuit... Still looking for an lcd display to use. I just noticed that the dimensions for the one I posted are way to big for one bay. have googled 128x32 graphic lcd, have found one I might use... not sure yet. edit: I also came accross that I will need a data rate of around 37K/s. I will need to see if this is possible on the basic stamp. most likely in parallel.
i still think in the long run your going to be making it painful for urself using the basic stamp, but each to their own. Yeh storing the users last choice in EEPROM is good idea, if you have a FAN0 idea, one that can never go below, 60% or somthing, that would be "safe-ish" there should be no need to actually set the fan speed high before reading your saved values, i can't see it taking more than 50 cycles to retreve them into data memory. (20mhz clock, that would be 0.00001th of a second) As for LCD crystalfontz have a nice blue one, parrallel interface, and its small, i was thinking of using one of these for a fan bus project miself!
Alright.. sorry, never read your first post, since the page showed up on the second one... I think I'll take your advice and use something other than a basic stamp. And yup, the limit of not going below 60% is a good idea. Thanks for all your help so far will google those pics you suggested. edit: also forgot to mention that I won't be using the sense on them, and also be using a voltage regulator of some kind, like you suggested. I should have proof read my post a second time
hehe no worries! If your using a regulator, that gives a stable DC stylee output (not sure on the propper name but non-PWM) then you can use the built in sensor on the fan, and still let the mobo use it too! Normally you can't just cut into the speed sensor cable, becuase its open-state you don't know what voltage the mobo will be pulling it too. But through the magic of open state comptability, you can! well, you break the connection to the mobo, pull it upto 5v with a 10k resistor and read it as any normal pin! To get a singal back to the mobo, you need to provie another open state output, you can do this with a transistor or opto-iscolator. Mesuring the speed is quite simple, a port change interupt can be used, and remeber its 2 square waves per rotation!
Cool... thanks saved me some research. I think I will add a feature that will display text on the LCD that sais "Fan x has failed!" and beep or something similiar. Would be cool. maybe have small text that shows the fan speed underneath the flying pixels, or maybe sort of blended in with them. like when a pixel flys over it, it inverts or something.
1: Thanks for the props and taking advantage of my design. Thats why I put it there. 2: This is not a PWM controller. Its an interesting way to control the voltage using digital latches, so the PIC is perfect for this. Ive never used a Stamp before (its just a PIC on a custom made PCB, so I stick with the original hardware). 3: The LCD from allelectronics does not have a controller. I would ditch that. On the otherhand, heres one thats not expensive $32USD . 4: controlling the fans will be easy. Its simple code. Ive never used a Stamp, so I have no idea how much memory is wasted. Doing a graphical interface would require you to store the image data on (preffereably) an EEPROM. Im playing around with I2C EEPROMs and the PIC, using the I2C module. Again, I have no idea if the stamp can handle that or not. It doesnt require much code though. You have the PIC constantly retrieve the byte data for the graphics and sending it to the LCD. In order to change the image, you simply change the block address of the EEPROM. Different blocks will have different image data. example: You have lets say 128x64 LCD screen. Thats 8K pixels. 1KByte of EEPROM space will hold one screen worth of data. If you want ta have 8 different screens to switch from/to, you get an 8KByte I2C EEPROM (like the AT24C64, or M24C64). Put the first screen of data at address A0:15 = 0x0000. The next screen data block will begin at 0x0400. The next screen at 0x0800 etc etc. In your routine to retreive the data, just increment the address. The good thing about I2C EEPROMS is that they only use 2 pins. The bad thing is speed. Most 16F families can only go 400KHz. This means that it can retreive 1Kbyte of info roughly every 30ms. This does not include the time it takes to transmit the data to the LCD (which should be faster, but you still have to wait to get the data from the EEPROM). Dont let this deter you from trying it though. Its not as hard as you think. If you have any questions about the fan control design, just give me an email.
Thanks for the heads up. I think I will ditch that lcd in my first post... As for the graphic to be displayed.. I never thought of doing it in memory.. I was thinking of using a mathematical formula to calc were a pixel should be at what time. Just randomly draw pixels on the display near the edge, and store it to eeprom.. then "pull" the pixel inwards by 1 or 2 pixels each frame. I'll have to play with it though. but as for your method, it would most likely use less power... but one thing though. Not sure how much eeprom is in a pic, but would there be enough for say 10 frames and 4 channels... since 4 will fit on the screen... so roughly 4*10=40*1K/frame = 40Kb... I was looking at the specs of this: Atmel ATmega128 looked good for what I want.. maybe too much.. but will look into it more.... Also, I do have room to use 2 drive bays, but no more... would using a bigger screen be better? I was hoping to make square or round fans... and use 4.. but making 8 channels would be better I guess... and divide the screen up into 8 instead of 4 like a 128x32 would do. I think that sit for now.. will do some searchin now.. may post again tonight (or edit my post lol) EDIT: I just got how the animation would work... each fan has the same animation.. just read different parts of the eeprom for each fan as needed... I can't beleive I never thought of that before.. and I'm the one out of all my friends and all the people I know to cut corners like that I guess I just got confused from what I was thinking
Hey, if you've got enough "spare" pins i would recomend using an 8bit parrallel EEPROM, much much faster than the I2C. The problem you will have with LCD animation, will be flicker, basically, when you write to the LCD controller, set these 8 pixels to xxxxxxxx your actually setting some (normally) SRAM, the controller is continually refreshing the LCD with the values in the SRAM, as such you have read write timming fun. That is to say, you can't write to the SRAM, when the controller wants to read from it, if you do this, the controller will skip the update for as long as your writing to the SRAM, but while the controller isn't updating the screen, its still incrementing its "pixel pointer" (ok, i made that name up) and as such you will get a flicker, that is, for one of the refresh cycles, the pixels won't be dark that should be. Because of this, you can either wait until its clear to write to the display memory, or you can turn the display off, write then turn it back on. The dispoff dispon method is generally the fastest for your micro, as implementing a wait until bus says you can write to LCD is hard. This is y. on the SED133x i think its pin6 from memory, that is used to indicate when the LCD is busy, you could of course just wait (block) in your code, until this pin says its ready. This can make the timing of your code go tits up! Other way is to use an interupt on that pin, so that when its state changes, you write the queued data (just a simple FIFO stack). That takes memory, and what do you do with stack overflow etc. Hope that helps with some of the problems you will be having for a first edition, i would try just using text + fan control, no animation. Then just try animation, with the fan control, before writing both.
Yup, I think that last part on what you said is what I will be doing. That way I can also get used to the coding of the pic I choose. And for the timings.. yeah, they will be hard. I am still intersted in the mathematical approach to it. Do you know if that atmel chip will handle it? Oh, and from what the specs point out on the atmel, it looks like I may have enough spar pins. It sais that there are "53 Programmable I/O Lines." So that should do it huh? lol. As for programming the animation graphically, IF my TI-83 plus can do around 10 fps on a 96 by 64 LCD running at 4 MHz, then I think this should be able to handle it running at 16MHz. It is supposed to be 16MIPS max. It should do it. Although, I would like to get a chance to use some external memory chips. Is there any way to interface with those old 30 pin ram chips... I have 8 1 meg sticks lying around somewere....
yup but if its not SRAM its not realy worth the effort, for a project i am doing i am emulating a C64, i thought of pulling the ram chips from that, until i looked how small each one was, and i can get half a meg for £0.50! as for pins, yes you should have plenty. for the maths, oh easily, just avoid floating point, a simple vector movement should be no difficulty. You might wanna try nocking one up in your favourate RAD using only BYTEs first thou, give you an idea of what you've let yourself in for
lol... will do.. and I not sure what RAD stands for.. I assume it has something to do with a mathematical simulator??? I will be trying out some simulations from there site. I think I saw one anyways... will look at program code options, then write pseudo code, then try out a sim. then build schematics and such, then test circuit, then real thing.
RAD = rapid application devolopement This can be any language thats fast to write in but often not suiteable for release, such as visual basic, MFC, CamlLight etc. Just to work out how your going to do your code, when you have the abillity to trace each line (i am assuming you don't have an ICE lieing around!) (ICE = In Circuit Emulator, damn nice things, but expensive)
I have a trial version of nvisage and tools... and for RAD.. I rmember now.. one of the reasons I got vb 6.. LOL hmmm... and digital works is kind of nice, digital only though. then there is eagle PCB... I had another progy that was fairly powerfull, but didn't know how to use it, and have since reloaded windows and haven't bothered to load it again too... will dig into my software chance once I get a chance.
i don't think eagle will be much use for early design simluation, because its all in the micro realy. The basic idea is to make sure your 100% certian how to impliment your animation, then you will know which program method to keep your animation flicker free will best suite.
True. I think I shall do the software way, since it requires less components and is therefore cheaper. Also, it is expandable if I ever want to change it to make it look different. Will post will updates later on, when I have come up with something. I will not have time to do it until this weekend most likely.
If you're considering the Atmel chips anyway, you may like to have a look at the 8535 and 8515 AVRs - they're basically smaller (cheaper) versions of the megas anyway, and they come in handy DIP packages. They also have all the usual bells and whistles built-in (SPI, in-circuit programming, UART, hardware and software interrupts, A/D (8535), etc). Writing I2C or single-wire (Dallas chips, mostly) handling code is easy, since you can download libraries with all this I would definately go with the multi-uP approach here, since that way, you'll know the timing and fan control is working. You should also look at hardware latching for start-up - something like a relay with its NC contacts holding the fan at full power, that the uP switches off once it's ready to take control. You could also add in a temperature monitoring sub-circuit, that latches the relay back on when the temperature goes too high. Atmel are great chips to work with, and are my uP of choice. <ASBESTOS KNICKERS>Far better than those silly pic thingies </ABESTOS UNDERWEAR>... Sounds like a fun project, all in all
more chips are for girlies. If you can do the code to keep it in one so much the better, thou it is more complicated. Atmels are often more powerful, but just lack the diveristy of microchip's range, i only tend to use atmel for middle of the road projects, ARM 710 if its high end, or a PIC if its low end (PIC12F629 VERY low end ) The problem with atmel's range is mainly the cost, and that they just don't have such a parifinalia of perphirals like the pic's sorry dude!
