Connect with us

MCU with CANbus + 10-bit ADC

Discussion in 'Electronic Components' started by Mochuelo, May 26, 2006.

Scroll to continue with content
  1. Mochuelo

    Mochuelo Guest

    Hi,

    Which is the cheapest MCU that you know of, with
    (Flash) AND (CANbus) AND (10-bit ADC) AND (EEPROM OR I2C)?

    Is there any web page with a database where I can look for an MCU with
    a certain set of characteristics? It should cover as many
    manufacturers as possible.

    Thanks in advance,
     
  2. PIC18F2480, around $5 for single quantities.
    Try digikey's webpage and search for "Microcontrollers".
    They have a parametric search.
     
  3. Mike Noone

    Mike Noone Guest

    I haven't seen any cheap CAN uCs. Cheapest solution I can think of
    would be your choice of uC that has SPI and a Microchip MCP2515. In
    single quantities you can get a MCP2515 for $3 and an Atmel ATMEGA48
    for $2.50. Obviously in larger quantities price will decrease
    substantially. Cheapest part with CAN integrated into it that I know of
    is the Microchip PIC18F2480 at about $10 in single quantities.

    -Mike
     
  4. Mike Noone

    Mike Noone Guest

    Where are you seeing this price? Digi-Key lists the cheapest PIC18F2480
    for $9.73.

    -Mike
     
  5. Well,

    you can use an 8-bit PIC or a 32-bit ARM7 device for the same price.
    The LPC2119 at Digikey is $9.50 with 128k Flash, 16k SRAM, 10-bit ADC
    and runs up to 60 MHz.

    An Schwob
     
  6. Oliver Betz

    Oliver Betz Guest

    a Freescale 9S12C32 is "cheap".

    There might be also cheaper 9S08 or newer HC908 derivatives with 10
    bit ADC.

    Oliver
     
  7. TI has ARM7TDMI core devices with CAN for similar prices ($5/1K). Most
    of these devices will require you to use an external SPI or I2C
    SEEPROM, if you want true EEPROM which you can erase one byte at a
    time.


    Best regards,
    Spehro Pefhany
     
  8. Microchip Direct -- $5.76. Mouser has the
    PIC18F248 for $5.99.
     
  9. This press release

    http://www.eeproductcenter.com/micro/brief/showArticle.jhtml?articleID=180204117

    mentions "the XC886/888 goes for about $2.68" /10K
    so you'll need to enquire for a more exact price, as not all XC886
    family members have CAN enabled.
    -jg
     
  10. Mochuelo

    Mochuelo Guest

    Yes, that was my impression (and frustration), too. I bet the reasons
    have more to do with marketing than with manufacturing costs.

    Anyway, strugling my mind I realized that maybe I can make it without
    CAN. This was for a long, linear array of sensors, about a hundred,
    and 3 m apart, for which I initially thought of a bus topology, but
    maybe it is not so bad a point-to-point channel from each sensor to
    the following one. Instead of CAN, I just need an MCU with (at least)
    two UARTs, which happens to be much cheaper. Each sensor would
    generate its own data, and would act also as a repeater, for the
    packets going to and from the sensors "to its right." This application
    does not need to transfer lots of data, and does not have to react in
    very very short times, so I think I can live with the added delays of
    this topology.

    The LPC2103 seems to be a good candidate for what I need, but I've
    seen that Rowley Associates Crossworks for ARM does not explicitly
    support it (it does support the 2104, though). That's why I'm posting
    a new question in another thread.

    Thanks again,
     
  11. You do not need 2 uarts for the link - is the 2nd uart used locally ?

    We have done similar systems using what I call a 'twisted ring' loop.
    In this, the 9th uart bit acts like a johnson counter, and every node
    extracts as many bytes as it needs, from the leading 9th bit edge, and
    inserts its size-matched reply, with the 9th bit low.
    All other bytes are simply passed-on.

    Thus each stage extracts adjacent packets, and the host can auto-count
    slaves, by looking for when the replacement-domino finishes.

    Works best with some deadband between bytes (wider stop bits ).
     
  12. Mochuelo

    Mochuelo Guest

    I forgot to say that the sensors also receive data from the control
    station, so each sensor needs to be able to transmit to its left and
    to its right, and to receive from both sides too. That's why I
    mentioned "packets going to and from the sensors 'to its right.'" So I
    need two UARTs.

    Best,
     
  13. Anyway, strugling my mind I realized that maybe I can make it without
    You might want to consider the AT91SAM7S32/S321 as well.
    The DMA on the UARTs + other nice features like RS-485 support should make
    it quite attractive.
    (Did you consider RS-485 instead of RS232?)

    You can get a free IAR Kickstart edition which will support the SAM7S32/S321
    Maybe the same with Rowley, but I do not know.
     
  14. Hal Murray

    Hal Murray Guest

    I'm not sure you need a second UART. Think "ring". Everybody
    sends to the left and listens to the station on the right.
    To send right, you go left all the way around the ring.

    I'm not saying that's a good way to do it, just another idea
    for the collection.
     
  15. The problem with using every node as a repeater is that a single
    hardware or software failure near the control unit will take out
    nearly the whole system.

    I would suggest a simple RS-485 multidrop bus with the control unit
    addressing each unit at a time. The only single node failure that
    could take out the whole array is that the node transmitter remains
    active all the time, but this could be prevented by some kind of
    watchdog timer.

    A bus systems with about one hundred nodes will have 2-3 times the
    number of connectors, so the connector reliability is essential. This
    applies to CAN as well as RS-485 networks.

    The one hundred RS-485 nodes could be handled if each node had 1/4
    unit load transceivers, however, with standard RS-485 transceivers
    only 32 nodes (e.g. one master and 31 slaves) can be connected to a
    single line.

    The array should be split into 4 sensor segments, each driven by an
    RS-485/RS-485 repeater. The other port of each repeater is connected
    to an other RS-485 bus, which is also connected to the control unit.
    Thus, the control unit could poll all 100 nodes one at the time.

    A better solution is to use four RS-422 ports on the control unit and
    connect separate cables to four RS-422/RS-485 repeaters driving their
    own sensor segments. In this way, the line speed would be only 1/4
    compared to the previous case, since the nodes on each segment can be
    polled in parallel.

    One might even consider using four Ethernet/RS-485 converters to drive
    the sensor segments, but the converter latencies should be studied
    carefully. It might be hard to access all 25 nodes in each segment
    within a second regardless of the segment line speed :).

    Paul
     
  16. Correct.

    I have also seen two-ring designs (which would use 2 UARTS),
    and with that, you gain ring-break tolerance, as with a single break
    anywhere in the circle, there is still a 2 way path to the master, and
    the master can also deduce where the break must be, and report it.

    -jg
     
  17. Mochuelo

    Mochuelo Guest

    You are right, I don't need two UARTs :)
    For one single array of sensors I would prefer using MCUs with two
    UARTs than having to run a second 300 m cable (to connect the control
    station to the furthest node, and so close the ring), but it turns out
    my linear arrays of sensors will have to be installed by pairs[*], so
    I can create rings without running separate cables. This means even
    longer delays, and lower reliability, but also cheaper nodes and
    cables (which need one less wire).

    [*] The sensors detect the presence/absence of vehicles in covered
    parking lots. There are two lines of sensors per aisle, one at each
    side. On each pair of lines, the lines are separated by about 10 m, so
    closing the ring is relatively cheap.

    I don't know if I will use it, but thanks for the idea.

    Best,
     
  18. Mochuelo

    Mochuelo Guest

    You also mentioned rings. Sorry, I don't know why I did not realize at
    the time of answering you that they could be another option for me. I
    started involuntarily discarding rings because I had in mind only one
    long line of sensors. When you said I needed only one UART I thought
    it was because I hadn't explained that the control station would also
    need to send data. Thanks, too.
     
  19. Stef

    Stef Guest

    In comp.arch.embedded,
    You don't need a separate 300 m cable for that. Just leave one conductor
    in the cable free for the return. Let each node just pass that conductor
    through and on the last node place a 'terminator' connector that loops
    the serial channel back to that free conductor.
     
  20. Mochuelo

    Mochuelo Guest


    I've been thinking more about this. It is a pitty that using one UART
    per node makes more complex the flow control. By flow control I mean
    how a transmitter knows that the receiver to which it has sent some
    data has already processed it and is ready to accept more. I don't
    want to use extra wires in the cables to implement hardware flow
    control, because that means more connectors and less reliability. With
    two UARTs per node, I was thinking of using some kind of
    acknowledgement data to immediately signal the transmitter that the
    receiver is ready to accept more data. However, with one UART per
    node, the acknowledgement should travel around the entire ring, to
    reach the original transmitter, and that can be a hell of a protocol
    :)

    Some options that I see:
    1) Not to implement flow control, and assume, from the point of view
    of each transmitter, that the corresponding receiver is infinitely
    fast. I'm a little bit worried, because the MCU needs to be cheap, and
    the amount of RAM will be very limited.
    2) If 1) gives problems at peak times, I could insert forced wait
    times until problems disappear.
    3) The system could start with zero wait times, and slowly and
    dynamically adjust them, in case problems are detected. For this, the
    UARTs need to signal that a new word has been received before having
    read the previous one, which I think is a standard feature. Sounds
    vague and complex, but might work, though maybe not efficiently
    enough.

    Any ideas?

    Best,
     
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day

-