on a board with no uP and control it instead with an RS232 serial port from a PC. I thought at first I could do this with the MAX3110E:
formatting link
but after reading this spec sheet I notice that on both the MAX3110E and the MAX9939 the SCLK line is an input. Evidently both were meant to interface to a uP and not each other. How can an SPI peripheral be controlled from a PC's serial port?
Another possibility is the 8 Bits from the National Instruments PCI-6110 card connected to the board the MAX9939 will be on. I see there is no maximum spec for the tCSS parameter of the SPI bus. Does this mean the timing of the SCLK does not have to be a regular cycle so all three SPI lines can be driven by the PCI-6110 digital output lines?
--
To reply directly remove the sj. from my email address. This is a spam
jammer.
Have you though of dumping the MAX3110 and using a picaxe-28x for the interfacing. It is a microprocessor, but it supports both rs-232 (using either a rs232 driver chip or its own 0-5volt rs-232) and spi, programs in BASIC using a three wire interface and your existing serial port (no dedicated programmer needed). Or you could use one of the cheaper picaxe chips and use the provided source code to do the spi portion (see shiftin/spiin shiftout/spiout) but this is slower.
The serial port has two async lines, but you need three. Lets say you have async control over DTR and RTS, and use them to generate clock and data. I can see some hacks where you could generate the CS signal based on the clock signal not moving in a given time period. You could sense the inactivity of the clock signal with a one shot. This is just a sketch. You need to work out the details.
Actually, with a little luck in the data to be sent and some clever passives and a diode, it's possible to drive a 3-wire SPI interface using just a single wire.
CK (clock) is the only driven signal. The target reads data on the falling edge of the clock, so a "1" bit drives the clock high immediately and fills the bitcell except for a falling edge right at the end. A "0" bit stays low until almost to the end of the cell and then pulses high-low.
Enable charges directly from clock but a diode blocks it from discharging through that same path, so its falling time constant is much longer than its rising one. A long run of zeros could definitely be a problem, though. The slow ramp on the trailing edge might also make some peripherals unhappy.
Still, I thought it was a pretty nifty hack. Saw it used on the DAC control lines for a Flashy 100 Msps ADC board from KNJN . Wondered how the heck they were controlling the DAC's SPI with only one pin on the header. Now I know!
From the DOS system you can, if the target device is happy with slower SPI speeds (most are). From a "modern" Windows system I believe bit-banging isn't truly possible, IIRC the OS is too slow (latency), but I leave that up to SW experts. It certainly isn't possible with USB-Parallel adapters but people have sucessfully done it with PCMCIA-Parallel cards.
Personally I wouldn't use Maxim chips but that's up to you. May be ok if no production qties needed. Otherwise check LTC, they've got chips like this but I don't know if useful to you:
Of course, when is the last time you used a Maxim chip in a design? Perhaps the problems have cleared up. I noticed a certain VP has retired, and the replacement has got to be better. The Peter Principle is real life. So is Dilbert.
Regarding bit-banging, I don't see a latency issue since SPI is all static logic. When I was at Maxim, we would bit-bang SMB (similar to i2c) using the cheesy DOS mode of win98 and the parallel port. However, you could load any number of free versions of DOS these days. [DrDOS, FreeDOS, OpenDOS]
There was a library that would work in win98 that would allow you do program the registers of the UART directly, which you could set the handshake lines. It didn't work in anything more advanced.
One thing to investigate is DOSBOX. It plays old DOS games, something I never thought could be done. I'm playing Redneck Rampage on X64. It might have better latency than using a modern windows OS.
So far it doesn't seem to me that it has cleared up. The last time I designed out several Maxim chips was about a month ago. The usual, they had become unobtanium for the client.
On a positive note, this creates revenue for me :-)
Yes, usually it's static. But not always. I've seen memory chips of the EEPROM kind that really did not like excessive procrastination on the SPI bus.
On which OS are you planning on running DOSBox? It can't do any better than what the OS permits. If you're using any NT-based version of Windows (NT,2K,XP,Vista,7), direct access to the ports isn't available unless you write a kernel-mode device driver.
If you need direct port access, DOSEmu on Linux is probably the best option. Direct access to ports below 0x400 can be enabled via the CPU's io-port bitmap; once enabled, inb/outb instructions will access the port directly without involving a kernel trap or any kind of emulation.
Bit banging over the com port control lines should work using the windows API. I have used the control lines for slow speed stuff, so I cannot comment on how fast the windows API would be for this.
Well, I was hoping DOSBOX did some magic. The software I generally run alongside my dos app doesn't work well in wine. I will check out DOSEmu. I see the documentation is nonexistent.
I gather I'd have to chown the port to the user running DOESEmu to get direct access.
Maxim lost Micrel as a foundry, so many old chips are not available. This would not be the case for products designed in their captive manufacturing facilities. I've noticed one or two of my really old chips getting new layout for SO packaging, so clearly somebody is buying product in volume.
Trust me, I could write a book on this VP that is retiring as far as the person being a cog in the system. If I ever had the access to money to become a corporate raider, I'd find employees that quit of their own accord. These are the people that know where the bodies are located, that is, bodies that need to be dislocated. ;-)
There was/is a forum on yahoo where people followed Maxim stock. The insiders there were so much on the money it was uncanny. Even people who joined after I left figured out who in management is the problem. It's really a shame board members never get to talk to the people doing the work. It is so easy to snow these dumb ass members of the board considering must are friends of management and don't want to see evil, hear evil, and certainly not speak of evil regarding management. .
I/O ports don't have individual device files. DOSemu uses ioperm() to grant port access. DOSemu is normally installed setuid-root to allow hardware access (hence the dosemu.users file to control who is allowed to use it).
Because there were way, way too many occasions where Maxim could deliver a few sample but the first order of bulk quantities bombed. Lots of line-stop situations at clients and that is not a good situation at all. OTOH these materials management problems at Maxim have brought me some business, to design tem out :-)
I wish you good luck with the long term availability of you MAX chips. But I wouldn't bet on it.
You can configure DOSemu to redirect serial/parallel I/O the /dev/* files (or e.g. lpr for parallel), or you can allow it to access the ports directly. If you configure it to allow direct access, the /dev/ttyS* file doesn't come into it; "out 3f8h,al" will cause the CPU to write to the port without the kernel getting involved.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.