a hobby class on microcontrollers
in [Embedded]
|
Prev: STUDIOT::Re: low-power-cons, low-cost, uP+DSP combo for H.264 videoencoding & control/monitor application
Next: Multimeter Clock – Styled after the Simpson 260 Multimeter
From: linnix on 7 Jul 2010 13:15 On Jul 7, 9:53 am, Walter Banks <wal...(a)bytecraft.com> wrote: > linnix wrote: > > Yes, that's the plan. He will do one for the micro and I might (if I > > have time) do one on the PC. I might do a 6502 ICE on the PC, since > > the 6502 instruction set is in the public domain (I think). > > The real status of the 6502 instruction set is a little fuzzy. The > Western Design Center have made some patent related claims > that have now probably expired > > http://www.westerndesigncenter.com/wdc/ > > I have seen a lot of 6502 based processors pop up in asia in > some cases with opcodes swapped around for all the instructions > except for branches. Yes, indeed. We can order 6502 look alike embedded core in ASIC. They don't work truly like the 6502, but close enough. In fact, we need to build the ICE to target an OTP ASIC.
From: Frank Buss on 8 Jul 2010 23:15 linnix wrote: > No kidding, wasted whole night for this. I would ignore it. > > Anyway, I got it to restart at COM3, COM4, COM5 and COM6 on a USB > hub. WinXP even remember the order it was plugged in. Just hope that > I won't have to change the hub. > > I posted the new version of WDIP.EXE (Auto detect COM3 to COM11) > and UDIP1A.HEX UDIP1B.HEX UDIP1C.HEX at: > > http://linnix.com/udip When I open WDIP.EXE in a text editor, it seems like your are using "COM3", "COM4",... "COM12" for opening the COM port. Did you test it for "COM9"? This will fail on Windows. I'm using this C-code to open a COM-port: char buf[100]; sprintf(buf, "\\\\.\\COM%i", m_comPort); m_portHandle = CreateFile(buf, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); if (m_portHandle == INVALID_HANDLE_VALUE) ... Detecting which COM ports are available on a Windows system is difficult. The easiest solution would be trying CreateFile for some port range and testing the result, but this can hang the computer, if a driver is faulty (which is sometime possible for drivers of some cheap USB adapters), or for some Bluetooth drivers. But you can try one of the 8 other ways to test it: http://www.naughter.com/enumser.html In my application the user has to execute an auto detect function of the program manually when installing the hardware and then the port number is saved for subsequent program starts, which is the least trouble, and the COM port can be choosen without auto detect, if it hangs. If you don't have to use COM (e.g. if you need Bluetooth on Windows XP before service pack 2, you need the COM port interface, if you don't want to use a special Bluetooth stack from a company), use HID for your USB device, if you don't have high transfer speed requirements. I've written a Windows application with a HID device for Windows XP and it still works on Windows 7 without changes. If you use libusb or other drivers, you'll have to update your software for each new Windows version. -- Frank Buss, fb(a)frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
From: linnix on 8 Jul 2010 23:25 > When I open WDIP.EXE in a text editor, it seems like your are using "COM3", > "COM4",... "COM12" for opening the COM port. Did you test it for "COM9"? Why? Is COM9 special on window? > This will fail on Windows. I'm using this C-code to open a COM-port: > > char buf[100]; > sprintf(buf, "\\\\.\\COM%i", m_comPort); > m_portHandle = CreateFile(buf, GENERIC_READ | GENERIC_WRITE, 0, NULL, > OPEN_EXISTING, 0, NULL); > if (m_portHandle == INVALID_HANDLE_VALUE) ... Yes, I am using CreateFile to open them.
From: Frank Buss on 9 Jul 2010 01:09 linnix wrote: > Why? Is COM9 special on window? Sorry, COM9 should work, but the trouble starts with COM10, see "Communications Resources" at the manual page: http://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx That's the reason for my special code to open the COM port. You should test it with your program. Maybe you can change the port number of your device in the device manager. -- Frank Buss, fb(a)frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
From: Anders.Montonen on 9 Jul 2010 09:40
Albert van der Horst <albert(a)spenarnc.xs4all.nl> wrote: > I think this is a design error. If your system features serial > device on USB ports, they should have a fixed name for each > USB port. Then if there is no communication possible on the port > the driver should respond so during open, or just make the device > unreadable/unwritable. Out of curiosity, does the device you use feature a unique serial number? At least on Windows, a lot of annoying behaviour goes away once the OS is able to reliably identify devices. On Linux you can also use udev rules to control the created device names. -a |