Forum Rule: Always post complete source code & details to reproduce any issue!
Page 74 of 74 FirstFirst ... 24 64 72 73 74
Results 1,826 to 1,838 of 1838

Thread: Project: SPI_MSTransfer

  1. #1826
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,605
    Nice! Good work Tony

  2. #1827
    Senior Member+
    Join Date
    Jul 2014
    Location
    New York
    Posts
    3,346
    @Robin. @tonton81 has a couple of other Teensy libraries of note:

    IFCT - Improved Flexcan Teensy Library (https://forum.pjrc.com/threads/52906...ight=canquitto ): He reworked most of the existing Flexcan code from scratch into a new library that supports current libraries and forks of collin80, teachop, and pawelsky, as well as a plugin for the MCP2515 library. It supports multiple mailboxes that are easily configurable as well as simplifies using filters - it does all the work for you.

    CANquitto
    CANquitto is a new canbus protocol library designed for teensy 3.x series MCUs. Currently in development stage, it has adopted quite a few features. This library takes advantage of IFCT and Circular_Buffer libraries when dealing with payload re-assembly.
    Forum: https://forum.pjrc.com/threads/53776-CANquitto
    • Multi-master design: nodes can control each other, and 2 or more nodes can control a single node.
    • Payload transfers: You can send payloads to other nodes which they'll receive in their callback.
    • GPIO controls, read/write/toggle/pinmode,analogread pins on any nodes
    • Serial/UART controls, full UART/USBSerial functionality combined with Stream class, allows pass-by-reference.
    • Also support SPI and i2c_t3.


    IMCTFD ( https://github.com/tonton81/IMCTFD ) - Improved Microchip CAN-FD Teensy FlexData Library (MCP2517FD). It uses SPI to communicate from the Teensy 3.x to a CAN-FD controller. So essentially you now can use a Teensy that will support the CAN-FD protocol.
    FORUM: https://forum.pjrc.com/threads/54323...ghlight=IMCTFD
    • This library was developed based on IFCT, libraries developed for and used on the Teensy 3.x platform. There are several benefits that are not even covered in the current Microchip API, or any other libraries.


    Respectfully
    Mike

  3. #1828
    Tonton (Tony):

    I've hammered my brains against the wall for (more or less) the entire day. I've been unable to get your basic examples to work.
    The ones I loaded were the SPI2WayExamples -> master, and SPI2WayExamples -> slave. They were loaded onto virgin Teensy 3.6-es, and the wiring is as specified (MOSI <> MOSI, MISO <> MISO, CS <> CS, SCK <> SCK) as 11, 12, 15, and 14, respectively (nice tip of the hat to Defragster!)

    The message that keeps coming back in the text window is as below, but repeats endlessly as the counter increments:
    Code:
    C:\Users\furys\AppData\Local\Temp\arduino_modified_sketch_764008\master.ino Feb 15 2019 17:51:58
    F_CPU	180000000
    DBG: [S_CS 15] CB Capacity: 8 Length: 250
    F&F (OT=0)micros() _time==99991
    F&F (OT=1)micros() _time==99992
    F&F (OT=2)micros() _time==99992
    F&F (OT=3)micros() _time==99992
    F&F (OT=4)micros() _time==99992
    F&F (OT=5)micros() _time==99992
    F&F (OT=6)micros() _time==99992
    F&F (OT=7)micros() _time==99992
    F&F (OT=8)micros() _time==99991
    F&F (OT=9)micros() _time==99991
    F&F (OT=10)micros() _time==99991
    F&F (OT=11)micros() _time==99991
    The text window for the slave shows this:
    Code:
    Teensy Online @ millis=5300
    
    D:\Users\rmartin\Documents\Arduino\libraries\SPI_MSTransfer\examples\SPI2WayExamples\slave\slave.ino Feb 15 2019 17:58:10
    F_CPU	180000000
    and nothing more.

    This is a picture of it. The master is on the left, slave is on the right.
    Click image for larger version. 

Name:	WIN_20190215_18_13_56_Pro.jpg 
Views:	22 
Size:	119.7 KB 
ID:	15920

    What on earth am I doing wrong? I'd have expected to see at least something; some transaction working; the failure message on the master repeats regardless of whether the slave is powered on (or even connected). I feel like this should be obvious, but...it's not.

    I tried lowering the bus speed to 16M, then 8M, but no joy at all on that; changed the wires (that's helped, before), moved board locations (this one is fairly new, so isn't so noisy yet). So it has to be something I'm missing.

    I went through your README, line by line. It's a bit confusing, because you mention that we need to cross the streams (MOSI <> MISO, MISO <> MOSI) but that makes no difference; neither does connecting the (slave's?) pin 2 to the master's pin 15 (your A_ConfigDefines file sets both ends to 15).
    Last edited by ariesboy571; 02-16-2019 at 01:57 AM. Reason: completeness...

  4. #1829
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,020
    slave pins used should be 2, 11, 12, and 14 for T3.x models

    the config file is for the master selected spi pins, the slave’s is fixed
    Last edited by tonton81; 02-16-2019 at 12:58 PM.

  5. #1830
    Quote Originally Posted by tonton81 View Post
    slave pins used should be 2, 11, 12, and 14 for T3.x models

    the config file is for the master selected spi pins, the slaveís is fixed
    Okay, using the examples files, again under SPI2WayExamples (master and slave).

    The A_ConfigDefines.h files are set up to use 15 for CS and 14 for SCK, but nothing's happening between them; those examples, out of the box, appear not to work.

    These are both Teensy 3.6es, brand new, and I've tested the boards, very little noise. The Saleae, however, is telling me that things are definitely not all right:
    Click image for larger version. 

Name:	screenshot.jpg 
Views:	19 
Size:	57.7 KB 
ID:	15981

    So, right now, it's set up as:

    Master Slave
    MOSI 11 12
    MISO 12 11
    SCK 14 14
    CS 15 2

    Swapping MOSI and MISO doesn't help a lot. It looks like it's trying to do...something, I guess. If it helps, the fastest I need this to go (at the moment) is 8MHz on the bus. And I'm okay using the default SPI0 pins. I'm getting the sense I haven't hooked this up correctly, although it sort of appears that there's progress...? I defer to your opinon on that...
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	screenshot.jpg 
Views:	16 
Size:	66.6 KB 
ID:	15979   Click image for larger version. 

Name:	screenshot.jpg 
Views:	12 
Size:	67.6 KB 
ID:	15980  


  6. #1831
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,020
    not sure why it wouldnt work, check common ground with the new setup? I will have to find time maybe day or 2 to setup 2 teensies

  7. #1832
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    8,605
    Unless tonton81 evolved this to a broken point rather than improving it - this code was working almost a year ago after this thread started with two T_3.6's doing SPI to SPI transfers of some 50 to 100 bytes very reliably a few hundred times/second and was at 24 or 32 Mhz. This was with the main T_3.6 throttled grabbing GPS and 9DOF motion data and the SPI was to offload some of the calc's to feed a monitor program to graph the results on a PC and sending the data to USB slowed it down and this let it work out 400-600+ 9DOF updates/sec gaining it a couple hundred data points processing per second. And that was before the T_3.6 was running at 256 Mhz so it wasn't tested there.

    i.e. … if the right setup is followed and programmed - it should work really well unless a tiny error was introduced.

  8. #1833
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,020
    most of the time it was bad grounding and cheap pololu cabling that caused no outputs due to corrupt crc data it may look like it’s doing nothing because of the wiring but it’s discarding the corrupt data while firing callbacks for valid data

    SPI2 for example on T3.5/3.6 was finicky with grounding as well, best results for SPI2 came from ground point located near it’s pads, but SPI/SPI1 should work fine with GND located next to pin 0

  9. #1834
    Junior Member
    Join Date
    Apr 2019
    Posts
    10
    Hi,
    I have a project in mind that would need some kind of high speed serial communication between a Raspberry Pi Zero W and a Teensy 3.6. I have already tested communication over USB, UART and I2C but the best I could get to run relatively stable was a UART connection with 1Mbit/s. Better than nothing but still to slow for how many data I have to push from the Pi to the micro controller. The main Problem is that the Teensy is already pretty busy with some time critical stuff and cant sit there just collecting the data, which would take with the speed I have achieved so far at least one or two seconds. So I did some research and was surprised how little support there is for custom SPI communication between these two boards, specially with the Teensy in slave mode. This library seems to be the only really usable stuff I could found, so I wonder if it would be possible to interface the slave part of this code with a master part on the Raspberry written in Python, or is this library only intended for Teensy/ Teensy communication and woud not work otherwise?

  10. #1835
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,020
    It’s won’t work because of chip specific registers and custom protocol for two way communication, a complete code rewrite is needed for the rasp pi, to be compatible with this, and it won’t be an easy task to achieve

  11. #1836
    Junior Member
    Join Date
    Apr 2019
    Posts
    10
    Quote Originally Posted by tonton81 View Post
    Itís wonít work because of chip specific registers and custom protocol for two way communication, a complete code rewrite is needed for the rasp pi, to be compatible with this, and it wonít be an easy task to achieve
    Thank you for your time. I see, so no easy way to make this work... Your lib looks great though. I now know where to look if I happen come across a fitting use case for your lib.

    At least I since found a way to solve my problem. Dramatically increasing the RX buffer in serial1.c and introducing a simple handshake to prevent overflow should do the trick for now. It's not pretty but will work for my needs until there are faster alternatives available

  12. #1837
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,020
    teensy supports RTS and CTS and has high baud rates, no need to implement it in software when itís capable in hardware. Not sure if rasp pi supports RTS/CTS but itís there on teensy side, it prevents overflow and buffers donít need to be adjusted

  13. #1838
    Junior Member
    Join Date
    Apr 2019
    Posts
    10
    Thanks for the advice, I haven't really thought about a hardware implementation. Indeed, I think the raspberry also has this feature and this would be definitely a simpler and less error prone solution to prevent overflow. But I will stick with the bigger buffer. There is plenty of RAM and it would keep the raspberry transmitting longer than without. Today, I also want to test some termination resistors and try to push the speed a little bit more, cause both IC's should normally be capable of much higher baudrates. Sadly I have no oscilloscope to actually test if signal reflection is really the limiting factor here.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •