I'm looking for a cheap system for communication/measurement purposes. I'd expect a few I/O ports, 1 - 4 A/D inputs, and some communication port(s).
I've already looked at PICs, AVRs, and lately the ARMs. Now I've got the following problems/questions:
- I'm expecting to transfer up to 32kBytes (256kBit) fullduplex.
- USB is no good on longer distances - I'm expecting up to 50m. How is CAN or I2C in this respect?
- USART/RS232 won't work, as it has to be some bus. I'd like to use simple 4 wire telephone cables (ground, Vcc, 2 communication), but maybe CAT5 is also ok.
- Ethernet would be possible (and would provide very much bandwidth reserve), but there a few controllers available - or at least not cheap ones.
- I wouldn't mind if the ICs had only 14-20 pins - just power, communication, and I/O pins.
PICs are "just slower" AVRs (a bit overstated, but you get my drift), but the development tools are available. ARMs have much better performance - but are there Open Source compilers or assemblers? Using an embedded linux would be simpler, but does have much higher cost than the simpler AVRs with only 64kB Flash.
Yes, I'd look at serial. For a bus take RS422, that is a pair of RS485 drivers, one for each direction connected to the internal UART. Each direction is a differential pair. This would take
6 wires when the GND and +5V are included. At least the GND is required for reference. PIC and AVR are 8 bit machines, while ARM are a different story. What performance do you need ?
At what speed, as that is only a data quantity stated there. If that is the 'block' size of data how often is it repeated?
Cannot comment directly on CAN, I have opinions on I2C for this but needs answers to above first.
That is contradictory, unless you are using V24 (ITU.T) specifications of RS232 to drive a modem, the RS232 is just a signalling level. Simplest RS232 is - TX, RX, signal ground. Running power (DC) down 50m of cable will be 'interesting'.
Work out what you are trying to achieve EXACTLY and what part of the system is doing what THEN think about comms method and what electronics where. You seem to be very wooly at the moment as to what you want and thinking about technology BEFORE knowing what you are trying to achieve.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
GNU H8 & mailing list info
For those web sites you hate
Sorry, I didn't make myself clear. I need to transfer 256kBit per second in both directions simultaneously, in short bursts of about 16-128 bytes.
I read CAN can do 500kBit/s on 100m - that should work.
It won't work because I need to connect more than two devices. So there has to be some bus arbitration and/or collision detection etc.
The goal is to have some wall-mounted devices which allows voice communication to other, identical devices. Maybe my best bet is to use the two remaining wires in analog form, and to do just access control to these with some other means.
But then I'd need more than 4 wires, and some additional electronics (analog switches, amplifiers) - I hoped that it would be mostly a single-chip solution.
Can I make standalone binaries that don't need some runtime environment like libc etc.? Does gcc include the startup-code for ARM, so that I simply program the I/O ports as needed?
Analog phone wires are graded for 20 to 30 KHz typical signal. Jamming a 500 KHz digital signals on it is just wishful thinking. It's difficult to transfer more than 100 Kb/s without compression. With compression, your memory and CPU resource requirements go up rapidly.
USB is just a form of I2C.
Perhaps on short messages. Not for constant data at that rate.
You are probably looking at mid-range ARMs.
(from another message) Thinking about display also and you are looking at high end ARMs.
You won't be building a single-chip solution anyway - all off-board digital communication uses driver chips of some sort (i.e., if you go for CAN and use a micro with a CAN controller, you still need a CAN driver).
If you are talking about building some sort of intercom system, you'd be better off using one of the wires for analogue sound, and a wire pair for a simple low-speed (say, 9600 baud) RS-485 bus for control and to synchronize which node is powering the analogue line. Trying to convert the voice information to digital and sending it along a network like this is a very inefficient way to do it.
Since you are talking about full duplex, this would imply a point to point connection.
Up to 50 m CAN could operate at 800 kbit/s and since the CAN frame can only carry 8 net bytes and since the total frame size is slightly over
100 bits (125 us) you might be able to transfer 6-8 frames/ms or 48-64 kBytes/s, so this link would not be able to carry 2 x 32 kByte/s, since realistically some overhead would be required to check e.g. assembly of the individual frames into a single application message.
Why don't you use RS-485, which runs nicely on two wires (and a signal ground or some special termination tricks) and assign one station as the master that polls the other station (slave).
The RS-485 common mode range is -7 V to +12 V, so if the current supply return connector is also used as a signal ground, the permissible voltage drop in the power supply return would be 7 V and assuming equal conductor sizes, the supply voltage wire drop could also be 7 V, so if the remote device with internal regulator requires at least 8 V, a 24 V power supply at the local site would be sufficient.
With long wires and large numbers of station, put all stations in series and use 48 V or similar voltages to power the devices. In this case it would be easier to implement the data using a current loop with all the receivers and transmitters in series over the same 20 mA current loop :-)
This is your forth posting and just now you get out with a fundamental requirement !!!
How do you expect any meaningful answers ?
OK, so you have 10-20 devices (or whatever, since you did not specify the number) connected on the same bus, each constantly transmitting
256 kbits/s to each other, thus the net throughput needed would be
2,5-5 Mbit/s and adding the overhead, the bus throughput would be close to 10 Mbit/s. Even the 10BaseT Ethernet would be hard pressed to work with the maximum number of stations.
What is so special about that ? Assign one station as the master and the other as slaves (or use one dedicated unit as master with no other obligations and all the other as slaves).
With Ethernet, the controller does most part of the collision detection, even if no master/slave relationship exists, but the timing would be unpredictable.
What kind of rusty barbed wires are you using as telephone lines in your part of the world :-)
When you see such specifications, you should first check who made such specification and for what purpose. You should look at the impedance levels and maximum allowed attenuation.
Those figures sounds like trying to run high quality audio at a nominal 600 ohm level through a telephone grade twisted pair, in which the frequency response is limited by the cable distributed capacitance in a voltage feed system.
However, if you drive the cable as a transmission line system with the generator and load impedance matching the cable characteristic impedance (about 100 ohms), the attenuation is mostly due to dielectric losses due to the wire insulation and thus much less frequency dependent.
Ordinary telephone pairs have been used to feed broadband signals for quite a while, video since the 1930's (BBC 405 line out-of-brodcast camera feeds from the streets of London), for a few decades to carry T1/E1 digital telephone over two pairs (24/30 calls 1.5/2 Mbit/s). Although out of specs, even the 10BaseT (10 Mbit/s) works in quite a few practical situations. All of these use quite simple envelope signals and at least in the video case needs a simple frequency equalisation.
More complex modulation methods, such as OFDM, can run to several megabits/s at several kilometers (ADSL) and tens of megabits below 1 km (VDSL). These distances are mostly limited by crosstalk between different pairs in a thick cable, which limits the transmitter power and hence the allowed attenuation and bandwidth.
Even if a cable may work at a very limited bandwidth in some applications (high quality audio), the same restrictions might not apply in a different situation with different requirements. Paul
Either you know nothing about USB, or you know nothing about I2C, or you would be just as happy with the statement that "Ethernet is just a form of HDLC." Or some combination thereof.
FTR: The only thing USB has in common with I2C is that it involves electrical signals changing over time.
It's not just the wires. The taps (or phone jacks) are creating little inductors everywhere.
Yes, you are talking about carrier frequencies. But RS232,I2C and/or USB don't use carrier frequencies. At 1 MHz, the corners of such signals would be terriblely distorted.
Again, these are broadband signals, not baseband.
Yes, if you place enough equipments (and money) on it. You can run any distance you want.
But frequency response does matter in simple baseband transmittions. Why do you think I2C and USB are limited to a couple of meters? Sorry, my mistake to lump them together, but they are in the same class.
and put whatever system dependant initialization you need in init. The purpose of the usual prequel is to set up such things as the malloc arena, the file system, glob command lines, implement redirection, etc. All you really need for an embedded system is to set up the initial stack and program counter. That probably means a few assembly instructions starting from wherever a system reset puts you. You can customize the rest in an init function.
If you look at the normal loading mechanism in gcc, you will see that it usually loads a standard module before the main program. This does the initialization, and calls main. It may contain or call a lot of code. Use the -v switches to watch what gcc does. You will probably see some references to crt0.o module.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Sounds like what POTS telephone service has been doing for well over a century, using a single pair.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
POTS pairs have an impudence (spelling deliberate) of about 600 ohms at voice frequencies, but become a pretty good 100 or so ohms by 1 Mhz. The losses (and thus attenuation per unit length) become greater at the higher frequencies. We have been able to resolve picosecond timings over several hundred feet in the past (30 years ago), as shown by the S/N of PWM modulated audio, and repeaters extend this almost indefinitely.
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
What on earth would length of messages have to do with that? If you want to squeeze the highest possible throughput out of a CAN bus, short messages are exactly the wrong way of doing that --- per-message overhead would kill your performance.
CAN at 500 kBit/s can give you an average payload data transfer rate of somewhere around 250 kBit/s using *long* messages, depending on which identifier format you use, and whether you also stuff data in the CAN ID or only in the "data" part.
It'll still be a very tight squeeze for 2 x 128 kBit/s of payload data rate, of course. But if you don't need to go all those 100 m, you can switch to 1Mbit/s CAN to get even more data through.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Which, in turn, invokes the "everything is a line" mantra. This ties Ethernet, HDLC, USB, I2C, RS485, and the telephone together quite neatly. :-)
--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
I meant sending short data messages, not short payload on the BUS. Anyway, sound like the OP is trying to make a digital intercom/telephone on the cheap. Can is not exactly cheap for this purpose.
Perhap if you only have two devices on it and ideal conditions. Your assumption is totally error free communications.
And special CAN connectors and cables, not POTS wires and jacks.
If you don't spent the money on data processing (compression, modulation/demodulation), you will be spending a lot more in communication hardwares.
A branch in the transmission line becomes significant only when it is more than 1/10 of the wavelength. Even with the total 50 m cable length specified by the OP, this would correspond to 500 m wavelength and 400 kHz (vf=0.66), thus the bus would definitely need termination at both ends. However, branches from the main bus would certainly be much less and thus a 1-3 m branch that might be typical for an indoor systems, the critical frequency gets much higher.
The dielectric losses are usually proportional to the square root of the frequency i.e. 3 dB/octave (while simple RC attenuation would be directly proportional to frequency i.e. 6 dB/octave) so indeed, the corners of the square wave would be rounded and thus, the eye pattern would be reduced.
To get something resembling a square wave, you would have to include at least the 3rd and possibly also the 5th harmonic of the baseband signal. Also note that when using NRZ (which the usual UART signal is), the highest frequency when sending the ...01010... sequence is f/2, thus if the data rate is 500 kbit/s, the highest base band frequency is 250 kHz and the transmission medium should pass the 750 kHz frequency quite accurately and also pass the 1.25 MHz frequency with some fidelity.
The waveform can become badly corrupted if there are long, unterminated stubs (branches), which will mess around the group delay.
Just wondering what your definition of broadband is :-). At least over here it has been mainly a political question.
The video signal is definitively baseband, since it is just a level shifted version of what comes out of the camera tube (or whatever toys they use these days :-). The T1/E1 is some kind of three level pulses to avoid any DC components, but otherwise quite baseband. On other networks, using some kind of Manchester coding does not IMHO prevent calling it baseband.
In the 1980's use of the word "broadband" would indicate that an RF carrier is modulated by the digital data stream, thus ADSL, COFM-VDSL and cable modems would fit this definition.
The primary problem is the voltages used and thus the driver power required. Also ground potential issues becomes critical in longer cables.
Ask yourself, what is the difference between a telephone cable (CAT 3) and a CAT 5 cable.
For the CAT5 cable the characteristic impedance is specified as well as turns/m and losses at some specific frequencies (thus dictating the isolation material). For a random selection of existing (installed) telephone cables, no guaranties are available of their high frequency performance. In some installations e.g. 10BaseT will work, but in other, it does not work.
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.