ADC/DAC supply range
Circuitsoft
Posts: 1,166
in Propeller 2
Is there any possibility of the ADCs and DACs working with I/O voltage at 2.5v? I'm looking to interface with a MAX2830, and the inputs/outputs expect/drive a common mode voltage of about 1.25v. While the receive outputs can drive up to a 1.5v common mode, the TX inputs won't take more than 1.3v common-mode.
Comments
You can parallel an extra resistance to bring the DAC voltage down further. The 75 ohm DAC is in fact just the 123 ohm DAC with a ~200ish ohm internal resistive load to make effectively a 2V 75 ohm DAC.
For the ADC I'd just leave it running from 3v3 and scale your incoming analog signal in software (if DC), or AC couple if this is an option.
For digital I/O, Chip has mentioned in the past that things like the 1v8 to 3v3 level translation gets slower and weaker as you drop from 3v3 VIO. Its not clear how slow/weak ( or conversely how much stronger things may be at 3v6)
Yes, partial range is no problem for both DAC and ADC. For digital I/O, though, you can go one better by using "bitDAC" for outputs and "compDAC" for inputs.
I probably should've clarified a little. The MAX2830 is an 2.4GHz modulator that has balanced/differential I/Q in/out. I was hoping to drive/listen to it with the on-chip ADC/DACs, but I'm starting to lean towards an external 8-bit DAC/ADC due to the differential requirement.
Do you plan on implementing WiFi and IP on top of this? If so, don't they have chips that worry about all the error coding, association, and encryption stuff for you, providing you with Ethernet frames over a synchronous digital interface, similarly to an Ethernet PHY or PHY/MAC?
I have half an IP stack that I've been testing with @ManAtWork 's Ethernet PHY add-on board, and it'd be nice if it could also be made to support other physical interfaces such as WiFi.
The thought was that this could support WiFi, Bluetooth Classic, Bluetooth LE, and possibly 2.4G 802.15.4. Yes, it'd be nice to provide a layer that your IP stack could cover, but it'd be nice if it could handle 6LoWPaN (802.15.4/BLE both) as well.
Work on my IP stack stalled once I had implemented everything I could that didn't need timers. Without timers, you can't do TCP retries, DHCP renewals, DNS caching, mDNS, ARP, etc. I want to rewrite it as an XBYTE-based protocol engine with first-class packet buffers (instead of Spin's objects) and data tables (e.g. IP-MAC-hostname mappings), and automatic event/timer dispatching. I suppose a single instance of this engine could simultaneously do other protocols like Bluetooth as well.
Handling retries should be relatively easy even without a general purpose timer object. You have a cog waiting for received packages. If you add a timeout to the waiting your cog wakes up frequently even if there is no incoming traffic. Then you can keep a queue of pending retries that are sorted in chronological order. Each time the waioting times out you check for events where the scheduled time has passed and process them.
Right, but the problem isn't just timers. When I do implement timers, they will work something like that. The real root of the problem is that the whole thing currently uses up 3.5 cogs (two for your PHY driver/MAC; one for my IP cog that handles received packets, sends immediate replies, and would handle timers; and a significant chunk of the application cog, which is responsible for constructing and equeueing all non-reply packets itself), almost half the chip! I'm hoping a dedicated protocol engine cog can help reduce that to only 2 or 3 cogs, maybe with PHY RX running in the highest-priority ISR of the protocol cog, if that doesn't take up too much of the protocol engine's time.
Would reducing the PHY driver to only one cog help? That would limit the link to half dulpex, though. As I said earlier, this shouldn't be a problem for most embedded applications that include usually only one server process or one client process. I wouldn't recommend it for a web server with multiple processes running simultanously or with dynamically changing user code running. But hey, the P2 is no work station nor a web server meant for high traffic.
I want full duplex. When I get back to this project, I'm going to go through your driver and try to combine its two cogs into one. Since I have a separate protocol cog, the worst case should be that I'll have to have the protocol cog compute TX checksums in advance, instead of having the TX cog do it on-the-fly.
We had this discussion before... Wether full duplex really has significant impact on performance depends on the type of application. I'd say there are mainly 4 types:
Control applications where, for example, sensor data or user input is polled. You basically have a question/response ping-pong data transfer. Because it's real time the full bandwith is not used and only small packets are transferred. You don't send another question before you have received the answer. So full duplex does not have any benefit at all.
Transfer of large files or streams. Here the TX/RX bandwidth ratio is highly asymetrical. You transfer large data chunks in one direction and only small acknowledge packets in the other. If (and only if) you use look-ahead with multiple buffers and a sliding window acknowledge strategy full duplex gives some benefit but only very little. I'd say 10% if you're lucky.
Server applications with multiple processes runing concurrently. Say you want to do (1) and (2) at the same time. I think with a clever priority scheme the performance penalty of half duplex can still be kept quite low as long as the traffic is predictable. Of course, if you have a general purpose OS where the user can arbitrarily start different tasks this won't work.
You need to transfer huge amounts of data in both directions at the same time. Say, you have a video host with a camera connected and you need to stream the data to a remote machine. Here you definitely need full duplex. But I think this case is rather rare, at least the P2 is not the ideal target for this. A RasPi or box PC can do this better.
But I don't want to discourage you improving and optimizing the driver. If you think it's worth the effort, go ahead.
I happen to be of the same view ManAtWork presents here.
A very informative discussion indeed...Worth it's own thread, perhaps ?
Would be easier to find when the right time comes.
There are different meanings to 'full duplex'.
To some, it means sustained sending at full rates in both directions. That can be tough.
However, there are SW handshake designs, that need to be able to receive while sending, but at very asymmetric data flows.
USB turnaround delays can also come into the mix, and those encourage some level of packet grouping.
Those unknown delays of OS and Buffering, mean it is hard to be 100% certain you really do have a cleanly half duplex design.
To me, being able to tolerate full duplex, even if never pushed, is a good idea.
Can one end limit it to half only? If it can then that's worth the simplification IMHO.
My Ethernet application needs to transfer potentially huge amounts of data in both directions at the same time, and a Pi or a PC won't work because it doesn't have smartpins or a streamer or that many ADCs/DACs, and generally can't do realtime stuff anyway - an FPGA is probably the only reasonable alternative. Moreover, I'm a naïve fool who hasn't yet bothered to spend the brainpower to prove to myself that a single cog can't do full-duplex, or if I did already, I forgot. And so I'm going to go ahead and try combining the two cogs into one until I prove to myself that it can't be done.
@Circuitsoft , sorry for hijacking your thread. Is there any chip like the MAX2830 that has built-in ADCs/DACs and provides a digital interface?
Right, that ethernet stuff is off-topic here. Please continue there.