Forum Rule: Always post complete source code & details to reproduce any issue!
Page 4 of 36 FirstFirst ... 2 3 4 5 6 14 ... LastLast
Results 76 to 100 of 886

Thread: MicroMod Beta Testing

  1. #76
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,967
    @Paul - @defragster
    More on QSPI FLash.

    In the beta7 core libraries its dying right after it enters begin:
    Code:
    LittleFS Test
    QSPI flash begin
    Code:
    	Serial.println("QSPI flash begin");   <----- prints this and it dies.
    
    	configured = false;
    
    	uint8_t buf[4] = {0, 0, 0, 0};
    
    	FLEXSPI2_LUTKEY = FLEXSPI_LUTKEY_VALUE;
    	FLEXSPI2_LUTCR = FLEXSPI_LUTCR_UNLOCK;
    	// cmd index 8 = read ID bytes
    	FLEXSPI2_LUT32 = LUT0(CMD_SDR, PINS1, 0x9F) | LUT1(READ_SDR, PINS1, 1);
    	FLEXSPI2_LUT33 = 0;
    
    	flexspi2_ip_read(8, 0x00800000, buf, 3);
    
    	Serial.printf("Flash ID: %02X %02X %02X\n", buf[0], buf[1], buf[2]);   <---- never reaches here
    For Micromod are we using FLEXSPI2?

  2. #77
    Senior Member
    Join Date
    Sep 2015
    Posts
    123
    Quote Originally Posted by mjs513 View Post
    MISO is COPI (12)
    MOSI is CIPO (11)
    That seems like a problem - MISO should be CIPO, and MOSI COPI, right? Since Master -> Controller and Slave -> Peripheral in the new naming scheme.

  3. #78
    Senior Member
    Join Date
    Dec 2016
    Location
    Montreal, Canada
    Posts
    3,700
    With SPI on T4, you can swap MISO and MOSI pins around via the CR register

  4. #79
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,967
    Quote Originally Posted by ecurtz View Post
    That seems like a problem - MISO should be CIPO, and MOSI COPI, right? Since Master -> Controller and Slave -> Peripheral in the new naming scheme.
    Oops my dyslexia is showing - got it backwards
    MISO -> CIPO
    MOSI -> COPI

    Sorry.

  5. #80
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,967
    Quote Originally Posted by tonton81 View Post
    With SPI on T4, you can swap MISO and MOSI pins around via the register
    That one was my fault and typing too fast and seeing it correctly

  6. #81
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,913
    Quote Originally Posted by mjs513 View Post
    @defragster
    No PSRAM - try switching to DMAMEM. Ran into that as well.

    Still can figure out why QSPI Flash isn't working - I can't mess the wiring up on that one.

    OK got SPIFlash working - had wiring backwards.
    MISO is COPI (12)
    MOSI is CIPO (11)
    ...
    Those NEW SPI names will take a bit to 'read' ... forget already what the 'C' stands for ...
    >> Great it works on properly wired SPI !

    MM.T has QSPI? How?

    Working test here with above xxxADD's was:
    Code:
    //EXTMEM char buf[MYPSRAM * 1024 * 1024];	// USE DMAMEM for more memory than ITCM allows - or remove
    DMAMEM char buf[490000];	// USE DMAMEM for more memory than ITCM allows - or remove
    That had MM.T on Display board just now - hassle to swap it around ... what carrier in use there ?

    It will work with EXTMEM up to limit of DTCM as code finding no PSRAM points to DTCM:
    Code:
    EXTMEM char buf[390000];  // USE DTCM for more memory than ITCM allows - or remove

  7. #82
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,967
    Quote Originally Posted by defragster View Post
    Those NEW SPI names will take a bit to 'read' ... forget already what the 'C' stands for ...
    >> Great it works on properly wired SPI !

    MM.T has QSPI? How?

    Working test here with above xxxADD's was:
    Code:
    //EXTMEM char buf[MYPSRAM * 1024 * 1024];	// USE DMAMEM for more memory than ITCM allows - or remove
    DMAMEM char buf[490000];	// USE DMAMEM for more memory than ITCM allows - or remove
    That had MM.T on Display board just now - hassle to swap it around ... what carrier in use there ?

    It will work with EXTMEM up to limit of DTCM as code finding no PSRAM points to DTCM:
    Code:
    EXTMEM char buf[390000];  // USE DTCM for more memory than ITCM allows - or remove
    Yep was using the following with the error I posted
    Code:
    LittleFS_RAM myfs;
    // RUNTIME :: extern "C" uint8_t external_psram_size;
    //EXTMEM char buf[MYPSRAM * 1024 * 1024];	// USE DMAMEM for more memory than ITCM allows - or remove
    DMAMEM char buf[490000];	// USE DMAMEM for more memory than ITCM allows - or remove
    Damn - I'm dumb that flash chip on the bottom of the board is system flash ? Guess was wishful thinking.

    It will work with EXTMEM up to limit of DTCM as code finding no PSRAM points to DTCM:
    Thanks for reminding me. Now to go and find my Qwiic stuff and get something to eat. Think my blood sugar is getting low.

    EDIT: I am using the ATP Carrier board.

  8. #83
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,913
    @Paul - Note: HANGS after UPLOAD when no PSRAM switches to DTCM and requested EXTMEM alloc is too big.
    >> Not expecting this is MMOD specific - never tried it on T_4.x

    Odd thing is it does not trigger FrankB's HARDFAULT like this does?
    Code:
    #if 1
      int *badPtr = 0;
      *badPtr = 42;
    #endif
    If it is over using DTCM shouldn't it be faulting?

    From above this runs fine on MM.T with no PSRAM for LFSIntegrity RAM_DISK:
    > EXTMEM char buf[390000];

    But this HANGS on restart after Upload without triggering a Fault?
    > EXTMEM char buf[490000];

    for ref:
    Code:
    Memory Usage on Teensy MicroMod:
      FLASH: code:76360, data:10600, headers:7212   free for files:16420900
       RAM1: code:98304 (70504 used), variables:21184   free for local variables:404800
       RAM2: variables:502720  free for malloc/new:21568
    PS: I can quickly see from above "(70504 used)" I have about 28KB free in ITCM block - so losing ~4KB would save me a block of ITCM ( that was PR#4 in Teensy_Size )

  9. #84
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,913
    Quote Originally Posted by mjs513 View Post
    Yep was using the following with the error I posted
    Code:
    LittleFS_RAM myfs;
    // RUNTIME :: extern "C" uint8_t external_psram_size;
    //EXTMEM char buf[MYPSRAM * 1024 * 1024];	// USE DMAMEM for more memory than ITCM allows - or remove
    DMAMEM char buf[490000];	// USE DMAMEM for more memory than ITCM allows - or remove
    Damn - I'm dumb that flash chip on the bottom of the board is system flash ? Guess was wishful thinking.

    Thanks for reminding me. Now to go and find my Qwiic stuff and get something to eat. Think my blood sugar is getting low.

    EDIT: I am using the ATP Carrier board.
    - Yep I just ate and this was in the middle of that - now have an errand to run ...

    But for "T:\arduino-1.8.13_t54\hardware\teensy\avr\libraries\LittleFS\ src\littlefs\lfs.h" REF :: LFS_ERR_NOSPC = -28, // No space left on device

    LFS Integrity could monitor for that "-28" and make the error clearer

  10. #85
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,967
    Quote Originally Posted by mjs513 View Post
    Ok ran the following test on I2C QWIIC connectors and a Sparkfun QWIIC Keypad:
    1. SDA - Wire
    Code:
    Qwiic KeyPad Example
    Initialized. Firmware Version: v1.0
    Press a button: * to do a space. # to go to next line.
         88888888880009632147 0854
    012456789 777775555 00008888555
    All good. Keypad found and operational

    2. SDA1 - Wire1 (keypad1.begin(Wire1))
    Code:
    Qwiic KeyPad Example
    Keypad does not appear to be connected. Please check wiring. Freezing...]
    No good not recognized so SDA1 not equivalent to Wire1.

    3. SDA1 - Wire2 (keypad1.begin(Wire2))
    Code:
    Qwiic KeyPad Example
    Initialized. Firmware Version: v1.0
    Press a button: * to do a space. # to go to next line.
    00088855522233366699
    
    99552211
    9966555 88855223366997744331
    So SDA1 = Wire2. So do we change this?

    Ok - have to test the rest later when I find the rest of my QWIIC stuff.
    As an update to the above.

    4. Wire1 on pins 16/17 work using Wire1, again this is using the QWIIC Keypad as a quick and dirty test.

    5. Wire3 on pins 40/41 work:
    Code:
    Qwiic KeyPad Example
    Initialized. Firmware Version: v1.0
    Press a button: * to do a space. # to go to next line.
    88855522336699999771155
    
    
    55522211177755566677711

  11. #86
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,967
    Went back to playing with I2C on the MicroMod. I broke out our old I2C test board and wired up the ATP Carrier board to the i2cTestboard:

    Hook up
    MM Wire -> Teensy Wire
    MM SDA1/SCL1 -> Teensy Wire2
    MM pins 24/25-> Teensy Wire1
    Here is a photo but TMM has my fingers covering it until released by Sparkfun
    Click image for larger version. 

Name:	IMG-0337.png 
Views:	19 
Size:	746.0 KB 
ID:	24270

    Bottom line up front:
    BNO080 fails on Wire/Wire1/Wire2
    LidarLite Fails on Wire1/Wire2


    BNO055, MPU9250, MB85, SSD1306 and SHT31 (QWIIC Connector on Wire2) all work without an issue. I also attached the T3.2 to the MM on Wire and it works transferring data (blinking on both the MM and T3.2 using EasyTransferI2C.

    ToDo List:
    1. Test Wire3 on the MM with those devices
    2. Investigate the issues with LidarLite and BNO080.

    UPDATE: Put almost everything on Wire3 including BNO080 and LidarLite:
    Code:
    #define _MPU9250_port Wire3
    #define _BNO055_port  Wire3
    #define _BNO080_port  Wire3
    #define _LIDAR_port   Wire3
    #define _MB85_port    Wire3
    #define _SHT31_port   Wire3
    To my pleasant surprise Lidar and BNO080 both work on Wire3!
    Code:
    =======================================================
    ==================  LOOP 100  ==========================
    =======================================================
    ============ MPU9250 =============
    MPU9250: 0.208306, 0.232249, -11.042621, -0.000907, 0.000421, 0.000133, 7.516276, 33.024639, -12.204796
    
    ============= BNO055 ===============
    BNO055: X: 0.19 Y: -2.81 Z: -0.56
    
    ============= BNO080 ===========
    BNO080: 0.03,-0.01,0.91,0.41,
    
    ============= Lidar V3 ==============
    LidarLiteV3: 179
    LidarLiteV3: 
    
    =========== MB85 =============
    MB85 Read Done - array loaded with read data
    ...... ...... ......
    Data: true, 1.3574999571,  314159, 142, 0x50
    Data_5: The Quick Brown Fox 
    
    ============= SHT31 =============
    Temp *C = 27.74, Hum. % = 36.85
    
    ============ T32 Slave ===============
    Sending Data to T3.2 ====>
    UPDATE: 4/2/21 - 0730EST
    Ok did some more testing this morning concentrating on the BNO080 and LidarLiteV3.

    BNO080 - started working on Wire - Wire1 - sometime still die with the Timeout as we saw before. Have to do more with just a BNO080 off the board to see.
    LidarLiteV3 - Working on all Wire ports. Was a sketch issue and not a hardware issue.
    Last edited by mjs513; 04-02-2021 at 12:16 PM.

  12. #87
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,913
    Quote Originally Posted by defragster View Post
    ...
    Just ran 15MB Little FS test - write not speedy? - but it works and reads 5X better:
    Code:
    Start Big write of 2048000 Bytes.........................
    Big write /0_2MBfile.txt took  4.11 Sec for 2048000 Bytes : file3.size()=2048000
    	Big write KBytes per second 498.90 
    
    ...
    
    Delete with read verify all #bigfile's
    	Verify /0_2MBfile.txt bytes 2048000 : ..................................................	GOOD! >>  bytes 2048000
    	Big read&compare KBytes per second 2606.02
    <edit>
    'R' - Teensy reset data survives, of course
    'f' - format unused works quickly without data or integrity loss, of course
    'new program' - wipes disk, of course
    Ref this "NOT SPEEDY" quote to LittleFS QSPI NAND Flash just posted on the thread - not saying this is the nest compare with larger NAND versus onboard NOR:
    Code:
    Start Big write of 130920448 Bytes.......
    Big write /0_bigfile.txt took 47.47 Sec for 130918400 Bytes : file3.size()=130918400
    	Big write KBytes per second 2757.89 
    
    Delete with read verify all #bigfile's
    	Verify /0_bigfile.txt bytes 130918400 : ..................................................	GOOD! >>  bytes 130918400
    	Big read&compare KBytes per second 2475.46
    So here is a 7MB T_4.1 PROGRAM memory disk - okay it isn't far off ...:
    Code:
    Big write /0_bigfile.txt took  6.95 Sec for 3643392 Bytes : file3.size()=3643392
    	Big write KBytes per second 524.42 
    
    Bytes Used: 3661824, Bytes Total:7340032
    
    Delete with read verify all #bigfile's
    	Verify /0_bigfile.txt bytes 3643392 : ..................................................	GOOD! >>  bytes 3643392
    	Big read&compare KBytes per second 2707.35

  13. #88
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,447
    Quote Originally Posted by defragster View Post
    Pulled that library and not seeing it work in IDE with p#64 sketch?

    Getting various moving errors with attempts to fix
    ...
    Sorry, my post #64 was unclear. Currently this is not an Arduino library. The idea is to just copy the two files MicroModT4.h and MicroModT4.cpp into your sketch folder.
    I also fixed the 'MM32' bug you've observed and added a mmBus singleton for easier use. Here the current files:

    https://github.com/luni64/TeensyHelp...r/src/MicroMod


    And here a hopefully running :-) usage example:

    Code:
    #include "MicroModT4.h"
    
    using namespace MMT;
    
    void setup()
    {
         // name mapping MicroMod -> TeensyPins
        pinMode(D0, OUTPUT);                      
        analogWrite(PWM1, 128);
        int vBat = analogRead(BATT_VIN);
        // etc
    
    
        // 8bit Bus (G0-G7)
        pinMode(mmBus, OUTPUT);          // set pinMode for entire bus
        mmBus.pinMode(OUTPUT);           // same
    
        mmBus = 0x12;                    // write 8bit value to bus
    
        pinMode(mmBus, INPUT_PULLUP);    
        uint8_t val = mmBus;             // read 8bit value from bus
    
    }
    
    void loop()
    {
        digitalToggleFast(D0);
        delay(1);
    }
    In case you want to try it: I'd be interested if the bus thing works.

  14. #89
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,913
    Quote Originally Posted by luni View Post
    Sorry, my post #64 was unclear. Currently this is not an Arduino library. The idea is to just copy the two files MicroModT4.h and MicroModT4.cpp into your sketch folder.
    I also fixed the 'MM32' bug you've observed and added a mmBus singleton for easier use. Here the current files:

    https://github.com/luni64/TeensyHelp...r/src/MicroMod


    And here a hopefully running :-) usage example:

    ...
    In case you want to try it: I'd be interested if the bus thing works.
    Yes, I did copy the files locally - but seeing SRC folder - like the IDE - I unzipped to Libraries and then the IDE saw it. But even the local sketch files were not working right to explain this to the compiler: using namespace MMT;

    Not sure what I should see? What's a D0 {constexpr uint8_t D0 = 4; // GPIO9-06} Nothing is blinking or showing?

    Oh wait - there it is - found a wired LED - LED blinking - Yes that works.

    Not yet read the SFUN Silkscreen - and sorry I tried ... those white inverse tabs do a good job of hiding small RED font with big red background - especially when the cable has the board upside down ... WHERE's the CARD
    Code:
    #include "MicroModT4.h"
    
    using namespace MMT;
    
    void setup()
    {
      // name mapping MicroMod -> TeensyPins
      pinMode(D0, OUTPUT);
      analogWrite(PWM1, 128);
      int vBat = analogRead(BATT_VIN);
      // etc
    
      while (!Serial && millis() < 3000) { }
      Serial.println("\n" __FILE__ " " __DATE__ " " __TIME__ );
      Serial.println(vBat );
      Serial.println(LED_BUILTIN );
    
      // 8bit Bus (G0-G7)
      pinMode(mmBus, OUTPUT);          // set pinMode for entire bus
      mmBus.pinMode(OUTPUT);           // same
    
      mmBus = 0x12;                    // write 8bit value to bus
    
      pinMode(mmBus, INPUT_PULLUP);
      uint8_t val = mmBus;             // read 8bit value from bus
      Serial.println( val, HEX );
    
    }
    
    void loop()
    {
      digitalToggleFast(D0);
      delay(1); // much blinkier that (1)
    }
    Compiles and uploads - only these warnings:
    Code:
    MMhelpLuni: In function 'void setup()':
    MMhelpLuni:10: warning: unused variable 'vBat' 
         int vBat = analogRead(BATT_VIN);
             ^
    MMhelpLuni:21: warning: unused variable 'val' 
         uint8_t val = mmBus;             // read 8bit value from bus
                 ^
    edited code above shows this for output:
    Code:
    T:\tCode\T4_MM\MMhelpLuni\MMhelpLuni.ino Apr  2 2021 01:19:59
    535
    13
    12
    I DID notice when I changed to pin 13 == LED_BUILTIN that the D0 was also DIMly lit ??

  15. #90
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,447
    Not sure what I should see? What's a D0 {constexpr uint8_t D0 = 4; // GPIO9-06}
    This just translates the Teensy Pin names to official pin names from the MicroMode spec. You can of course use Teensy Names as well but then you have to look up in a table where they end up on the carrier board (like the one KurtE showed at the beginning of the thread). You find the spec of the micromod connector here: https://www.sparkfun.com/micromod#tech-specs


    WHERE's the CARD :-)
    This https://learn.sparkfun.com/tutorials...dware-overview might help (but the image quality is not the best...)

    535 for vBat/3 seems wrong. I would have expected something like (battery voltage 3V) -> (3V / 3) / 3.3V * 1024 = 310 counts...

    Does the value 0x12 show up on the 8bit bus? (i.e. on G0-G7)?

    I DID notice when I changed to pin 13 == LED_BUILTIN that the D0 was also DIMly lit ??
    Weird, hard to tell without hardware :-(

  16. #91
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,913
    Quote Originally Posted by luni View Post
    This just translates the Teensy Pin names to official pin names from the MicroMode spec. You can of course use Teensy Names as well but then you have to look up in a table where they end up on the carrier board (like the one KurtE showed at the beginning of the thread). You find the spec of the micromod connector here: https://www.sparkfun.com/micromod#tech-specs



    This https://learn.sparkfun.com/tutorials...dware-overview might help

    535 for vBat/3 seems wrong. I would have expected something like (battery voltage 3V) (3V / 3) / 3.3V * 1024 = 310 counts...

    Does the value 0x12 show up on the 8bit bus? (i.e. on G0-G7)?

    Weird, hard to tell without hardware :-(
    Sorry - trying to get off this thing for Zzzz's ...

    The D0 was a total mystery until I looked in the header ... and then read the silkscreen ... left it to be funny ... because you are mapping to be helpful and it just left me with added ... because I had to find the right board pin and an LED.

    Where's the CARD was also a PLUS to PJRC for sending the physical card for each board that is readable and full of needed info. Thanks for the SFun link - I've seen that - but it isn't a PJRC like CARD

    I did not test the 8bit bus voltage values - just had time to add printing it ... so it must be there right ... will check later when I move the T.MM back to the ATP board.

    ONLY having ONE is 'hard' too ...

  17. #92
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,447
    ONLY having ONE is 'hard' too
    I got myself one of those

    Click image for larger version. 

Name:	Screenshot 2021-04-02 110521.jpg 
Views:	3 
Size:	7.5 KB 
ID:	24273

    to replace the original tiny screw. Makes swapping much easier :-)

  18. #93
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,967
    Quote Originally Posted by luni View Post
    I got myself one of those

    Click image for larger version. 

Name:	Screenshot 2021-04-02 110521.jpg 
Views:	3 
Size:	7.5 KB 
ID:	24273

    to replace the original tiny screw. Makes swapping much easier :-)
    Thats a good idea - have to go pullout my box of standoffs

  19. #94
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    24,086
    Quote Originally Posted by luni View Post
    In case you send to Europe, I would be *really* interested.
    I will send you one soon.

  20. #95
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,447
    Great, thanks

  21. #96
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    24,086
    Quote Originally Posted by KurtE View Post
    Was curious about which pins hooked up to camera.
    The tentative plan for Himax HM01B0 camera support is to use FlexIO2, similar to AN12686. I'll attach the PDF to this message.

    Code:
    HM01B0 pin      pin#    NXP     Usage
    ----------      ----    ---     -----
    FVLD/VSYNC      33      EMC_07  GPIO
    LVLD/HSYNC      32      B0_12   FlexIO2:12
    MCLK            7       B1_01   PWM
    PCLK            8       B1_00   FlexIO2:16
    D0              40      B0_04   FlexIO2:4
    D1              41      B0_05   FlexIO2:5
    D2              42      B0_06   FlexIO2:6
    D3              43      B0_07   FlexIO2:7
    D4              44      B0_08   FlexIO2:8  - probably not needed, use 4 bit mode
    D5              45      B0_09   FlexIO2:9  - probably not needed, use 4 bit mode
    D6              6       B0_10   FlexIO2:10 - probably not needed, use 4 bit mode
    D7              9       B0_11   FlexIO2:11 - probably not needed, use 4 bit mode
    TRIG            5       EMC_08  ???
    INT             29      EMC_31  ???
    SCL             19      AD_B1_0 I2C
    SDA             18      AD_B1_1 I2C
    Attached Files Attached Files

  22. #97
    Senior Member+ Frank B's Avatar
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    8,281
    Are there enough remaining resources to emulate I2S via flexIO? If my questions makes sense.. not sure as there would be no board for cam&audio.. and if there would be one, it had the cam on other pins?

  23. #98
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    24,086
    It is unfortunate the way Sparkfun connected the microphones.

    When(if) the camera is working in 4 bit mode, perhaps we can convince them to make another base board with the camera using only pins 40-45 and connect the I2S pins properly?

    Somewhere I have a confidential datasheet with the I2C register info for that camera. I really should dig that up and write a little code to put it into 4 bit mode and turn on MCLK using PWM, so we can start trying to capture the camera data.

    The camera also supports a 1 bit mode, which I believe could allow use with only 3 FlexIO pins, 1 PWM pin, 1 GPIO and 2 I2C. But 1 bit mode is limited to slow frame rates. 4 and 8 bit modes allow all speeds, so there's really no advantage to using 8 bit mode.

  24. #99
    Senior Member
    Join Date
    Apr 2014
    Location
    Germany
    Posts
    1,447
    This
    Click image for larger version. 

Name:	Screenshot 2021-04-02 143848.jpg 
Views:	10 
Size:	44.3 KB 
ID:	24276
    is probably a typo? Shouldn't it be SPI_COPI1 / SPI_CIPO1? If so, which one is which?

  25. #100
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    6,967
    @luni
    They did that on the SPI_SDO and SPI_SDI pins as well if you look:
    Name:  Capture.PNG
Views: 94
Size:  9.6 KB

    So
    SDO = COPI
    SDI = CIPO

    I think

Posting Permissions

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