Thanks for reply.
There is also another weird thing happening.
Periodically I get the "Autoplay" running for no apparent reason.
I have not looked at it in any details, since it always happen when I do develpment. Than I do not want to futz with it then.
What really bugs me - after total power down the original disk name will be back.
But it makes me nervous because the first time this happend it never came back with the original drive.
But it definetly affects USB devices only.
I'll have to learn more about USB.
What you are describing would be consistent with my previous post. Many USB disks have an auto-play INF that installs device drivers for encryption or other purposes. I *highly* recommend that you disable auto-play.
The reason your auto-play prompts you randomly is probably because; 1.) have auto-play enabled and 2.) one of your disk devices is becoming detached/attached. When the hardware arrival event fires auto-play will probably prompt you if you have it configured in this way.
The reason your USB disk device is randomly attaching/detaching could range from faulty USB connector... all the way to driver conflict. In the past I have seen this happen when a security product would scan for USB devices.
I've just inherited a setup at my new job. I formatted and installed Windows 7 Ultimate from scratch, then updated my display driver, a Radeon HD 2400 Pro, but my one monitor remains blank. It is wired correctly, as when I updated the driver, I had a few moments when it was live, showing Windows desktop background, and on a few other occasions it does this as well, but it always goes blank after a few seconds and stays like that until the next brief event.
i trying to build up a program that send a bitmap to the lan printer directly to the ip address
i'm looking for code (c#,c++) that can make the job like the printer driver do.
something that can "talk" with the printer and send directions and data.
i have a service that sends thousands printings to several printers (lan & wan) and it's take long time until the page go out,
getting the driver from the print server, init the printer, spooling (in the server that spool the printer hardware...)
i realised that if i install simple driver(PCL5 etc..) for advanced printer it's work faster!
where i can find piece of code that send to the printer ip some instructions for start ?
I have got old drum machine with 240x64 LCD screen,
What I want to do is send signal from ribbon LCD to PC and encode to see all information on PC screen(240x64 is very tired to looks for 4-8 hours when I work in the studio)
This ribbon coming from drum machine mother board after lc7981
How to connect to PC ?(USB board or pallalel)
ON that ribbon I have got this data:
pin on LC7981 and data:
5.MB LC drive signal
10.FLM Frame signal
11.CL1 Display data latch signal
46.CL2 Display data shift clock signal
47.D1 Display data Upper SCreen
do I need anithing more?
Any LCD simulator in PC or Mac ?
Or I need to read my program ?
Thank You for your answer ))
It is no easy to find musician on this platform
This is old sampler Akai Mpc 3000
I am looking for some info how rebuild or reverse existing LCD to VGA board (very fussy works only with few monitors because 31.5 kHz/ 59hz )or build new one.
I have got schematic and good pictures (but use peel18cv8 and 22v10 with security bit on
It means not POsIBILE to copy).
I am not sure about SDK for Akai?
If some one can help me
I've seen interfaces to do from a PC to an LCD but I haven't seen anyone go from from an LCD to a PC. There are a number of practical problems you would have to overcome.
Rather than trying to do something after the LCD controller chip, you might be better off picking off the the signal between the micro-controller and the LCD controller chip. The interface will be simpler. Between the central micro and the LCD controller the interface would likely be 7 to 12 pins depending on if they implemented half-word or full-word interfacing. If you can identify the data pins (Usually D0 thru D3 or D7) and the clock pin, you could probably program you own micro-controller to emulate the LCD control chip (and hence the whole display). Starting with the pin-out on the LCD control chip would be a good place to begin. (Actually, the manual on that chip would probably be required to have half a shot at making this work) However, you'll need to break out a logic analyzer and you'll probably need to write your own emulator using something like an Atmel AVR micro. Those chips would work well because they have a USART that you can connect back to a PC to pass in the display data as a serial data stream. Then you would just need to craft something on the PC to receive that data stream and display it in a 'virtual lcd' on screen.
Hello, Guys. Again , thank You for answers.
How I can see it is no point to works with LC7981(LCD controller).
For beginner like me, probably I need some more advice:
-which avr xmega interface (board) for controlling LCD (virtual in PC )
With USB and parallel port can I use for this project(links or full item name will be
-which connectors have to read (obtain) from MCU.
I know data bus(D0-D7) , CS/, R/W and which more? To
Connect to xmega interface or o'scope?
Most any of the Mega chips would probably work. The Tiny stuff won't likely have enough pins so you could probably skip it. I've been working with the Mega128 recently on a project and find it to be fast enough with plenty of memory for my needs. And I am driving an LCD with it that has the HD44780 controller chip using just the half addressing (to keep pin count down) while also reading a serial data stream at 250 kbps and pulse-width-modulating an output at a 10 us duty-cycle. All while clocking the chip at just 16Mhz. (It goes to 20Mhz)
You will need a programmer and Atmel Studio 6. The software is available on their web site for free. You can save some money by purchasing the STK500 programmer (which will program the Mega128) or you can find a third-party programmer that implements ISP (In System Programming). And buy a few chips... they are cheap and you'll likely lock yourself out of at-least one. Everybody does at some time or another.
I think that you could probably have good success with this chip. You would need to identify the pins on the LC7981 that are connected to the microcontroller and figure out which is which. The good thing is that the LC7981 will only be connected to two things; the microprocessor and the LCD, so figuring out what is what should be pretty easy with the manual for that chip.
You *should* be able to set the pins on the AVR to high-impedence input mode and be able to pick-off the signals in-circuit... at least while you are testing and debugging. For a permanent install I would suggest desoldering the LC7981 and wire-up the pins on the Mega128 in its place. This is where a logic analyzer will be a big help. You'll need an acquisition rate at least twice the clock rate of the CPU in the device (likely 8Mhz but you may have to decode the information on a crystal to know for sure.) The analyzer will let you see the electrical signals as they happen in-circuit. The manual for the LC7981 chip should address the timing sequences for the pins which you should be able to verify with a logic analyzer. The manual will also talk about the initialization sequence and what, specifically, the chip will do for the different command modes. All this has to be provided so the guys writing the software on the micro side know how to drive the controller chip properly. The LCD controllers don't take serial commands... it is all at the bit level and driven by the clock... very low-level. But the manual for the LC7981 will cover all of that. Your task would be to write code for a Mega that would emulate this behavior. If I were attacking this I would likely figure out a way to execute an ISR (interrupt service routine) on the CS line. When the Mega sees this go high or low (depending on which is the 'valid' state), then the Mega can read/decode the data lines. Making it interrupt driven would be the way to go in my opinion.
There are some libraries out there for the Mega's that will drive various LCD controller chips. Looking at some of them might help you understand that side of the equation. You might also read up on http://avrfreaks.net and post some questions there. Note that the people there don't suffer poorly asked questions very well. You should make sure you have a well thought out and to the point question before you post over there.
There are also a lot of tutorials on sending serial data from an AVR chip to a PC. You will need that to send the data from the Mega to the PC. If I were you, I would probably try to keep this simple. Assuming the LC7981 works like most other controllers, the micro will load a character at a time onto the interface and clock it into the display controller. There are also control codes to clear the display, move the cursor, etc. I would turn those into similar control characters that could be send over the serial link while passing alpha characters as-is. If you do it this way, you could 'debug' the PC side of things using just hyperterm or something like that to read the stream of characters coming in. If the letters, numbers, and control characters are transmitted to the PC as they arrive at the AVR, you can pretty it all up in an app later.
You might also check and see if you have a hacker-space in your area. You can probably find someone there like me that knows the AVR stuff and might want to take this on as a project with you. This is the kind of novel project that guys like me are always looking for to take on as a personal project... out of the mainstream and yet very intriguing. I think the idea is cool and I could actually see something like this being useful beyond your project.
There's really no good reason this drive isn't being detected. It's probably a safety feature of the computer since booting off CD or USB is an easy way to get to the files in the HDD. Look through the BIOS settings as already recommended.
It may also be possible that your booted OS doesn't understand the file system of the HDD OS. This would only be a problem if they're different operating systems. If it can't understand the file system, it probably wouldn't attempt to mount it since you can do permanent damage mounting a drive with an incompatible file system.