Shop OBEX P1 Docs P2 Docs Learn Events
I2C SPI loop driver/objec — Parallax Forums

I2C SPI loop driver/objec

ErlendErlend Posts: 612
edited 2012-10-09 14:13 in Propeller 1
I am working on a project where the Propeller is communicatiing with 3 SPI devices (RTC, ADC, IrSensor). I addition I have a large number of sensors and devices connected - almost using up all Pins.
All three SPI sensors seem to need specialized SPI drivers, judging from what I can find on OBEX - causing 3 sets of i/o pins to be used. How can I put all sensors on one common SPI loop / network?
I am fairly good at high level programming, but not so at low level, such as communication protocols.

Can anyone help, or point me to some resources, please?

Comments

  • MagIO2MagIO2 Posts: 2,243
    edited 2011-12-29 05:10
    Hi Erlend, welcome to the forum!

    You should at least name or better set a link to or upload the drivers you are using, so that you can also get help from guys who did not have exactly this problem before.

    As much as I know from SPI, it's a fairly easy protocol and should leave a lot of free space in a single COG. So it should be possible to create some code out of the 3 specialized drivers which runs in one COG. Easiest way is simply copy all into one DAT-block with some little changes in the command-interface. More sophisticated and maybe needed because of the limited COG-RAM would be to find out the common part of all 3 drivers and extract it into sub-functions.

    In any case you would then have a SPIN to PASM interface where you have different "functions" for the different SPI drivers.

    With some resistors or some glue-code which keep the pins in a defined state during takeover it would also be possible to exchange the drivers in one COG. So, if you want to read device 1 you'd load code 1, if you want to read device 2 you'd load code 2 .... Of course this wastes some time for reloading the COG, but here no changes are needed in the original drivers. So, it depends on your bandwidth-needs whether it is a practical solution or not.


    PS: As far as I remember SPI devices have a chip select, right? So, starting from 3 attached devices it might make sense to add a shift-register to the propeller to create the CS-signals.
  • MagIO2MagIO2 Posts: 2,243
    edited 2011-12-29 05:30
    How is your Gaspresso doin? Do you have internet access at that location?

    I think it would even be funnier to also add a spinneret which gets the messages from the internet. So everybody can add a message on the internet and you'll see messages you did not 'invent' by yourself. This increases the long-term-fun-factor.
    The plan would be that the spinneret from time to time loads the latest messages with the main-board falling back to buildin messages if there is no alternative message at all.

    "Evacuate the dolphins - water tank runs empty!"
  • JonnyMacJonnyMac Posts: 9,108
    edited 2011-12-29 08:49
    @Erland: Being SPI devices they can certainly share the same set of SCK, MOSI, and MISO pins. I recently coded an industrial device that used a SPI ADC, four thermocouple readers, and a CAN interface chip (MCP2515). In your case you should be able to do this with six pins and if your objects are defined in the same cog you don't have to worry about buss collisions. Each object should be able to handle the details for each device.

    If you list the devices we can give you code examples.
  • ErlendErlend Posts: 612
    edited 2012-01-04 03:52
    this is for test only - my long reply disappeared during posting...
  • ErlendErlend Posts: 612
    edited 2012-01-04 04:09
    Thanks folks for giving me hints to a solution and for encouraging me to work on it. I will start working on stitching together a generalized driver. I guess where I will struggle is how to address the individual devices, which are: the IR sensor MLX90614, the DS1302 RTC, the MCP3208 ADC, and the Parallax SD card reader. Do I understand it right that these can all be bus'ed, or do they need some pins to be individually wired (CS?) to avoid voltage clash?
    The IR, RTC, and ADC will be cyclically read (by one COG I hope), whereas the SD will only be read occasionally to get 'permanent' global variables, and to play wav files (the machine is speaking!). Speed is not an issue, except for the SD - which I think should be left alone.

    My Gaspresso project is progressing nicely, and is growing more and more fun - and funny eventually. Sorry, I did write a full-report-post now, but it got lost in space, and so I need time before I want to write it again. Sorry II , I have not updated my web, but that's because SPIN has been a learning exercise which has taken priority.

    About the spinneret idea, i do not even mean what it is, I have to read up on spinneret first.

    E
  • ErlendErlend Posts: 612
    edited 2012-01-04 04:22
    -oh yeah, now I get it (did not understand what spinneret was) - what a great idea!

    The Gaspresso has grown too 'large' to be left alone in my cabin (where there is only threadwidth internet), so it will also create fun in a more urban setting. How fun it would be to let it speak on behalf of the whole world!
    The list of 'core messages' is defined - like "Water low warning" - but they can be phrased wildly different. Similarily I have established a list of moods - like Sad, Grumpy, Indifferent,etc - but the list can be expanded a lot. The machine will decide a mood at power-up, but some events will later cause it to change mood.
    Mainly, the fun part is in the speaking, but the 20x4 LCD will also show an occasional odd message. Normally though, it is used for 'rational' communication with the user.

    E
  • MagIO2MagIO2 Posts: 2,243
    edited 2012-01-04 05:58
    CS means Chip Select. Usually CS signals are active-low which means that if that pin is high the chip will not drive any output pin and won't accept any input. For that reason you can not bus the CS signals.
    If you have more than 2 devices on the bus it makes sense to drive the CS signals of the different devices with a shift register. Such a shift register has 2 inputs at least (a clock- and data-input and maybe an ENABLE also makes sense) for shifting in a byte or a word depending on the size of the shift register (connected to the propeller) and then has 8/16 output pins (connected to the CS pins of your devices). This way you can shift out the 8-16 CS signals which saves you some propeller pins.

    As far as I remember the FSRW (SD-card driver) in a later version is eating up all the COG-RAM, so this will need to run in it's own COG anyway, so if you can afford those extra pins (CS is then not needed on propeller-side - you can simply fix it to low) it's fine. Otherwise you'd have to implement some takeover/release - code for the bus.
  • ErlendErlend Posts: 612
    edited 2012-01-04 06:14
    Thanks for the advice to permanently ground the CS for the SD - I'll do that. If the number of SPI devices increase I may choose to use a shift register as you suggest, but it means another pcb job, so I won't do it now.
    As regards the SD, you just gave me another reason to leave it alone - using it's own SPI and it's own COG.
    E
  • Duane DegnDuane Degn Posts: 10,588
    edited 2012-01-04 11:13
    Erlend,

    Are you familiar with the C3? It has some nice tricks with its SPI devices. It uses a counter chip (I'm not sure what it's really called) to pull different CS lines low based on how many pulses it receives. I thought it was a cool way to save a few pins.

    I'm pretty sure the C3 schematics are available from the product page.
  • ErlendErlend Posts: 612
    edited 2012-01-05 00:40
    Hi,

    I had a look at the C3. Maybe I should have used that one in the first place, or maybe I will use it when I port the prototype to a permanent solution (everything soldered), but right now I think it is too much for my needs. Already I've been given ideas that will free up quite a number of pins, so I don't think I will run out of IO for this project. For larger projects I would have preferred a single-wire bus to communicate with sensors and other devices (CAN bus?), but for now my Gaspresso project is plenty enough to keep me busy.

    I also got the idea that if i keep 3 separate comms lines for the 3 SPI devices, I could permanently pull down the CS of each, saving 3 pins - right?

    Erlend
  • Duane DegnDuane Degn Posts: 10,588
    edited 2012-01-05 11:43
    Erlend wrote: »
    I could permanently pull down the CS of each, saving 3 pins - right?

    Some (a lot?) of SPI chips use the CS line in the communication protocol. I'm pretty sure not all SPI devices will work with their CS lines tied low.
  • MagIO2MagIO2 Posts: 2,243
    edited 2012-01-06 10:45
    Yep ... sorry for the confusion about that ... I was to sure that a CS in SPI is similar to a CS on 74xxx chips - more thinking would have helped! Reading in Wikipedia then revealed to me that "normally" the CS goes high after transmission.
    So, it's a better idea to have CS connected to the propeller (separate for each device) and MISO/MOSI tied toghether than tie CS to low and have separate MISO/MOSI on the propeller!

    But the Wiki-entry is nice and shows several ways how to use SPI.

    All in all it is very important to read the specs and find the differences of all devices attached to the same pins to find out if there is away to code a general-purpose driver for all - and to find out whether CS=low tricks will work.
  • JonnyMacJonnyMac Posts: 9,108
    edited 2012-01-08 12:29
    Think of it this way: pins_required := 3 + n_devices.

    You can share the SCK, MOSI, and MISO pins (the three above), but each device sharing that bus will require its own chip select.
  • ErlendErlend Posts: 612
    edited 2012-01-12 00:21
    Ok, I've learned a couple of things now - and that is really a great part of the fun of this, the never ending learning. I will rewire as advised, except: for both the RTC and the ADC the drivers dictate the MOSI&MISO are wired together, obviously running simplex and switching the pin from input to output. The SD card however, uses separate pins for input and output.
    nfortunately I obviously had a bit of foggy mind when I assumed the Ir sensor was also SPI. It's not, it is SMBus, needing two pins only.
    Another thing I've learned is that I2C has nothing to do with SPI, they are entirely different interfaces. You guys should have flamed me for that surely?

    Erlend
  • Duane DegnDuane Degn Posts: 10,588
    edited 2012-01-12 06:45
    Erlend,

    The drivers that share the input and output lines were likely done just to save a pin. I doubt it would be hard to modify the objects to use two separate pins. If you post a link the drivers, maybe someone here would change them for you.
  • ErlendErlend Posts: 612
    edited 2012-01-17 12:27
    Thanks Duane, but it would be the last resort to give up and ask someone else to do the coding for me :cool: I am reading up on PASM now, so that I can modify code as needed. I will never be an assembler guru, but I would like to at least be able to read the code that has been written by others. Since I want the I/O scanning to go on in the 'background', I've been looking for the method to keep updating global variables without PUB Main having to bother about it - and have discovered LONGFILL and WRLONG. It works : )
  • ErlendErlend Posts: 612
    edited 2012-10-08 01:02
    -how do I remove the X Unsolved flag?
  • Duane DegnDuane Degn Posts: 10,588
    edited 2012-10-08 06:22
    Erlend wrote: »
    -how do I remove the X Unsolved flag?

    Edit the top post. "Go Advanced". Select "Solved" from menu (I think it's on the left above the edit window).
  • Mark_TMark_T Posts: 1,981
    edited 2012-10-08 11:17
    MagIO2 wrote: »
    CS means Chip Select. Usually CS signals are active-low which means that if that pin is high the chip will not drive any output pin and won't accept any input. For that reason you can not bus the CS signals.
    If you have more than 2 devices on the bus it makes sense to drive the CS signals of the different devices with a shift register. Such a shift register has 2 inputs at least (a clock- and data-input and maybe an ENABLE also makes sense) for shifting in a byte or a word depending on the size of the shift register (connected to the propeller) and then has 8/16 output pins (connected to the CS pins of your devices). This way you can shift out the 8-16 CS signals which saves you some propeller pins.

    Well if you have enough SPI devices to warrant collapsing CS pins via a shift register you are likely to have at least one you want to go fast - and clocking the shift reg then latching it will become a bit of a bottleneck - might be better strategy to use a 3 to 8 or 4 to 16 active-low decoder? Poss problem with output glitches though.

    BTW preventing SPI bus clashes is a perfect match for a Prop lock...
  • frank freedmanfrank freedman Posts: 1,983
    edited 2012-10-09 09:52
    JonnyMac wrote: »
    Think of it this way: pins_required := 3 + n_devices.

    You can share the SCK, MOSI, and MISO pins (the three above), but each device sharing that bus will require its own chip select.

    This is how I understood SPI to work. If erlend uses a shift register he would need to read sequentially or add an additional pin to enable shift register to the /CS lines taking the count to 3 + shclk, shdat, and oen (optional if just cycling sequentially). Or use a 7438(?) 3-8 or 74154 4-16 line decoder for 8 or 16 devices.

    @jonnymac do you know of a good thread to understand I2C? I thought it was a different method than SPI, but have not used this method yet.
  • SRLMSRLM Posts: 5,045
    edited 2012-10-09 12:43
    @Frank

    These are the two sources that I learned from:
    http://www.robot-electronics.co.uk/acatalog/I2C_Tutorial.html
    http://www.esacademy.com/en/library/technical-articles-and-documents/miscellaneous/i2c-bus.html
  • frank freedmanfrank freedman Posts: 1,983
    edited 2012-10-09 14:13
    @SLRM, More reading thank you. Looks good at a glance so now to see if I have any devices I can put to learning mode. ..........
Sign In or Register to comment.