[2.0.x] [FR] Implement SPI in a Library format for LPC HAL

[psavva]

Dear Marlin Team,

I would like to request support for the TMC2130 drivers, which is implemented by @teemuatlut on his Marlin branch.

To do so, we need to have a SPI Library for the LPC MCU.

The include should work as per the other SPI Libraries, and must follow the same interface as the SPI libraries for AVR/Due/Teensy.

Once done, we would hopefully wait for a pull request from @teemuatlut on the TMC implementation using the SPI Interface

[tcm0116]

If the TMC2130 driver utilizes the Arduino TwoWire class to perform the SPI communications, then the TwoWire class I wrote in the LPC1768 HAL in my branch just might do the trick.

https://github.com/tcm0116/Marlin/tree/2.0.x-TwoWire

[teemuatlut]

No it uses the standard SPI library that is included with many of the Arduino framework compatible cores. Also the TMC library cannot use the functions that are inside Marlin only. Thus the need for an SPI library.

[Bob-the-Kuhn]

I've written a cheap & dirty SPI.h for the LPC1768 but Platformio won't connect to the https://github.com/teemuatlut/TMC2130Stepper.git library.

When compiling for the Arduino boards we can connect properly to the https://github.com/teemuatlut/TMC2130Stepper.git library.

I've seen this before with the ARM tool chain in Platformio. The GIT method of providing a library just doesn't work. The only method I'm aware of that works is to register the TMC2130Stepper library within Platformio.

@teemuatlut - can you register your TMC2130Stepper library?

It's a fairly straight forward process. My only stumbling point when I did it was providing the proper link to the library.json file. You can use https://github.com/MarlinFirmware/U8glib-HAL as an example. To register this library I entered the following command in a Platformio terminal window: platformio lib register https://raw.githubusercontent.com/MarlinFirmware/U8glib-HAL/master/library.json

The following are links to creating & registering a library. http://docs.platformio.org/en/latest/librarymanager/creating.html http://docs.platformio.org/en/latest/userguide/lib/cmd_register.html

[teemuatlut]

I don't understand why I'd need to register when the PIO library manager already finds my lib. This is maybe my 20th time trying the PlatformIO IDE (or Atom) and it seems to just get worse and worse every time. Constant restarts, lockups and error messages.

Teensy35 finds the library and builds OK. It's not the ARM toolchain. The reason the LPC1768 platform can't find the TMC2130Stepper library is because the library dependency is given as a git link. And I really don't have any idea why it's been given like that in the first place. Add the dependency and it'll work:

[env:LPC1768]
lib_deps        = CMSIS-LPC1768
  U8glib-HAL
  TMC2130Stepper
  Or maybe just add ${common.lib_deps}   ?

Or at least you'll get to the next problem...

[psavva]

I find fully deleting Atom and reinstalling does the trick for me. We really should find a user friendly alternative to PlatformIO

[Bob-the-Kuhn]

Yes, PlatformIO has it's fair share of "quirks".

@teemuatlut - thanks for pointing me to TMC2130Stepper. That's exactly what was needed.

Now to work through all my logic errors and compile errors.

[tcm0116]

I did some messing around, and I got the TMC2130Stepper library to compile with Marlin 2.0. Here's a link to my branch if anyone wants to see what I did:

https://github.com/tcm0116/Marlin/tree/2.0.x-tmc2130

I did have to modify TMC2130Stepper.h from the TMC2130Stepper library in order to get it to compile:

- //#if defined(ARDUINO) && ARDUINO >= 100
  #include <Arduino.h>
- //#endif

Please note that I didn't test anything as I don't have any TMC2130 steppers. However, I was curious to see if I could get it to compile. Maybe someone can take this and see if it works.

[Bob-the-Kuhn]

Here's another attempt at providing a functional LPC1768 TMC2130. Definitely not ready for prime time. https://www.dropbox.com/s/p7xkwxzpvoxma5v/TMC2130%202017-11-09.zip?dl=0

It uses a soft SPI. You can set the SCK, MOSI & MISO pins in the file LPC1768_TMC2130.cpp.

I did verify that the SPI pins wiggle appropriately. Looks like it sends a 6F 00 00 00 00 every 5 seconds. The SPI runs about 1.2-1.3MHz.

I also had to modify the TMC2130 library. I used SPI.h to get all the needed items linked/defined. Unfortunately the LPC1768 SPI.h gets included in lots of places so I initially had lots of "TMC2310 SPI duplicate definition" errors. To get around that I added a define to TMC2130Stepper.cpp.

7    #else
+      #define INSIDE_TMC2130STEPPER_CPP
8      #include <SPI.h>

I also couldn't test it because I don't have a TMC2130.

It would be nice if this one could also be tested.

---

@teemuatlut - looks like there needs to be a change to the TMC2130 library to allow the non-Arduino systems to hook in. Suggestions?

[Bob-the-Kuhn]

@tcm0116 - I couldn't get your branch to compile for the LPC1768 even after I applied a few of the fixes from my work.

I didn't find a file Arduino.h in your branch. The closest I found was the lower case "a" one in HAL_LPC1768/include. Perhaps you had a custom one that filled in all the missing items?

[tcm0116]

@Bob-the-Kuhn hmmm. I renamed arduino.h to Arduino.h and updated my branch, but I don't think that'll fix it. I wonder if it's because I have the Arduino IDE installed on my Mac and PlatformIO is somehow finding Arduino.h from there...

[tig33r]

Here's another attempt at providing a functional LPC1768 TMC2130. Definitely not ready for prime time. https://www.dropbox.com/s/p7xkwxzpvoxma5v/TMC2130%202017-11-09.zip?dl=0

Excuse me @Bob-the-Kuhn for stupid question but how to compile it? There is not platformio.ini file...

I can't compile @tcm0116 fork 2.0.x-tmc2130 too.

[psavva]

Hi @tig33t. I can see the platformio.ini file... It's there.. It's in the root folder.

[tig33r]

LOL my archive wasn't download completely. I'm kinda retard cause I didn't notice that.

[psavva]

I'm also busy downloading it now on my laptop to try and compile :) I'll make a separate branch for this on my account.

My drivers don't have the headers on them yet, so I'll have to solder the headers on in December (going to Mexico for another 2 weeks)

[psavva]

@Bob-the-Kuhn , I tried compiling the branch you supplied, I get this error:

.
.
.
platformio.ini
README.md
You can focus the GitHub tab with Ctrl+8
58.5 s
platformio run --environment LPC1768
void SilentStepStick2130(uint16_t mA);
^~~~~~~~
compilation terminated due to -fmax-errors=5.
In file included from .piolibdeps\TMC2130Stepper\src\source\TMC2130Stepper_CHOPCONF.cpp:1:0:
.piolibdeps\TMC2130Stepper\src/TMC2130Stepper.h:10:7: error: 'uint32_t' does not name a type
const uint32_t TMC2130Stepper_version = 0x10100; // v1.1.0
^~~~~~~~

.piolibdeps\TMC2130Stepper\src/TMC2130Stepper.h:14:26: error: expected ')' before 'pinEN'
TMC2130Stepper(uint8_t pinEN, uint8_t pinDIR, uint8_t pinStep, uint8_t pinCS);
^~~~~
.piolibdeps\TMC2130Stepper\src/TMC2130Stepper.h:17:20: error: 'uint16_t' has not been declared
void rms_current(uint16_t mA, float multiplier=0.5, float RS=0.11);
^~~~~~~~
.piolibdeps\TMC2130Stepper\src/TMC2130Stepper.h:18:3: error: 'uint16_t' does not name a type
uint16_t rms_current();
^~~~~~~~
.piolibdeps\TMC2130Stepper\src/TMC2130Stepper.h:19:28: error: 'uint16_t' has not been declared
void SilentStepStick2130(uint16_t mA);
^~~~~~~~
compilation terminated due to -fmax-errors=5.
Linter
Severity    Provider    Description Line 
PIO Build (LPC1768)
git+
TMC2130_LPC1768161 files

[psavva]

Maybe this will help resolve some of the compile issues we see? https://github.com/MarlinFirmware/Marlin/pull/8452

[thinkyhead]

//#if defined(ARDUINO) && ARDUINO >= 100

I think we can probably lose that at this point in history. Marlin won't even try to build on Arduino before version 1.6.8. There might be better ways to query the build environment now too. (#if PLATFORMIO?)

because I have the Arduino IDE installed on my Mac and PlatformIO is somehow finding Arduino.h

PlatformIO will only look where you tell it to. As far as I know it doesn't include any "provisional" search paths (such as the default Arduino Sketchbook folder). I don't use PlatformIO from within Atom, but only from within Sublime Text 3 (via Deviot), and PlatformIO definitely lives within its own sandbox under that arrangement.

[tcm0116]

PlatformIO will only look where you tell it to.

What's strange is that PIO will include files in Marlin when compiling external libraries. In my experience, libraries are usually compiled in their own sandbox with their open dependencies, and then the dependent project will then use the artifacts provided by the library. In this case, the dependency can depend on the dependent, which makes my brain hurt.

[psavva]

Any suggestions on how to fix the compilation on PlatformIO, I would like to test, and give Bob feedback if/how it works out

[tig33r]

Are latest changes #8464 in bugfix2.0 enough for proper tmc2130 work?

[psavva]

They is how Bob had it in the dropbox link. Ie, removed the git link and instead included only the TMC Library, similar so to what is done... It seems the TMC Library it's still expecting the header from Arduino, which doesn't seem to work...

Can someone else try to compile using PlatformIO to confirm this behaviour?

[tcm0116]

@tig33r #8464 only fixes compilation for AVR in PIO. Per my comments in that PR, pretty much none of the external dependencies will compile on LPC1768 due to their dependencies on Arduino.h.

[tig33r]

Regarding @Bob-the-Kuhn last files I have exactly same error as @psavva

I dont know is it matters but in TMC2130Stepper.h in two first lines teemault probably have mismatched definitions, should be TMC2130Stepper_h instead TMC2310Stepper_h

[teemuatlut]

I dont know is it matters but in TMC2130Stepper.h in two first lines teemault probably have mismatched definitions, should be TMC2130Stepper_h instead TMC2310Stepper_h

Yeah that's a typo but it doesn't really affect anything as it's only an include guard.

[Bob-the-Kuhn]

I was able to re-produce the compile error. It is caused by using the standard TMC2130 library rather than the modified one that was in the dropbox link.

Here's a ZIP with all the modified & new files.
The two LPCxx ones go into the HAL_LPC1768 directory SPI.h goes into the HAL directory The TMCxx ones replace the ones in the library.

Don't forget to do a clean after modifying the library. PlatformIO won't pick up the changes until after a clean is done.

LPC1768_TMC2130.zip

[tig33r]

Now firmware is compiling successfully and motors are working however I didn't print anything yet.

My settings:

in lpc1768_tmc2130.cpp:

  #define TMC2130_SCK_PIN P2_12
  #define TMC2130_MISO_PIN P4_28
  #define TMC2130_MOSI_PIN P1_23
  #define TMC2130_CS P2_11
  #define TMC2130_CS_ACTIVE HIGH

added #define X_CS_PIN P2_11 in pins_mks_sbase.h

defined HAVE_TMC2130 and X_IS_TMC2130 in Configuration_adv.h

cable connections:

SDO -> p4_28 CS -> p2_11 SCK -> p2_12 SOI -> p1_23

As i have hypercube evolution (corexy) cables for both stepsticks are connected to same motherboard's pins.

[psavva]

I'll be back home after a 2 week visit to Mexico. I'll start testing this again when I get back.

[psavva]

I managed to finally solder the headers. Hope this looks ok. I'm planning to test it asap with the changes by Bob-the-Kuhn.

@Bob-the-Kuhn If it works, what do you need to get it mainstream?

[tig33r]

Try tcm build

[teemuatlut]

Maybe now is a good time to tell that I've got a solution of my own that I like more but differs a bit from the one given here. But it's on my other computer and I won't be able to upload it until Wednesday.

[Bob-the-Kuhn]

@psavva - see issue #8334. Looks like tcm0116's comment on Nov 9 will work with the current TMC2130.

[tig33r]

Tried his branch and it is compiling succesfull but motors does not work.

[psavva]

Ok then.. :). I guess I'll have to wait until Wednesday. I'm looking forward to it.

[psavva]

Thanks @teemuatlut

[vilsed]

Hello.

I'm getting compile errors using Bob-the-Kuhns TMC2130 library patches.

What gives?

`Compiling .pioenvs\LPC1768\lib\TMC2130Stepper_ID1493\source\TMC2130Stepper_GCONF.o .piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper_COOLCONF.cpp:16:6: error: prototype for 'void TMC2130Stepper::sgt(int8_t)' does not match any in class 'TMC2130Stepper' void TMC2130Stepper::sgt( int8_t B ) { MOD_REG(COOLCONF, SGT); } ^~~~~~ In file included from .piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper_COOLCONF.cpp:1:0: .piolibdeps\TMC2130Stepper_ID1493\src/TMC2130Stepper.h:167:11: error: candidates are: uint8_t TMC2130Stepper::sgt()

uint8_t sgt(); ^~~ .piolibdeps\TMC2130Stepper_ID1493\src/TMC2130Stepper.h:160:8: error: void TMC2130Stepper::sgt(uint8_t) void sgt( uint8_t B); ^~~ .piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper_COOLCONF.cpp:27:8: error: prototype for 'int8_t TMC2130Stepper::sgt()' does not match any in class 'TMC2130Stepper' int8_t TMC2130Stepper::sgt() { ^~~~~~ In file included from .piolibdeps\TMC2130Stepper_ID1493\src\source\TMC2130Stepper_COOLCONF.cpp:1:0: .piolibdeps\TMC2130Stepper_ID1493\src/TMC2130Stepper.h:167:11: error: candidates are: uint8_t TMC2130Stepper::sgt() uint8_t sgt(); ^~~ compilation terminated due to -fmax-errors=5. *** [.pioenvs\LPC1768\lib\TMC2130Stepper_ID1493\source\TMC2130Stepper_COOLCONF.o] Error 1 [ERROR] Took 281.17 seconds`

[teemuatlut]

https://github.com/MarlinFirmware/Marlin/compare/bugfix-2.0.x...teemuatlut:LPC_TMC2130

Basically all it does is redirect calls to the class member functions to the ones we already have. I'd rather not see multiple implementations of SPI communication for a platform. I also think the actual implementations should live in the class, contrary to how it is on my branch here. Further, I think the whole SPI implementation should be moved to frameworks/CMSIS/LPC1768/lib/, assuming that files inside aren't compiled for other platforms. This would get us quite close to an actual SPI library for LPC. But the LPC HAL isn't my main focus so I don't want to mess with it too much alone.

[vilsed]

Still getting the same compile errors...

[psavva]

I'll compile it tonight to see if i can replicate your issue.

On Thu, 28 Dec 2017, 12:03 vilsed, notifications@github.com wrote:

Still getting the same compile errors...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/8334#issuecomment-354263121, or mute the thread https://github.com/notifications/unsubscribe-auth/ABYypkJuiquY16e1Zy8NNXj93ym19KfKks5tE2dpgaJpZM4QWzGh .

[vilsed]

Thank you. Will be waiting for feedback

[psavva]

@teemuatlut

I had enabled

define HAVE_TMCDRIVER

as well as

define HAVE_TMC2130

together with X stepper driver for both...

I have several issues when trying to compile: 1) TMC26XX is not included in the dependencies for the LPC Build in PlatformIO, which it is referenced in stepper_indirection.cpp I have have included: https://github.com/trinamic/TMC26XStepper.git

2) Upon including the TMC26XX library, I had an issue where "boolean" was not recognised, so I changed that all to "bool" instead in the TMC26XX library.

3) Upon the change of boolean -> bool, I again faced compile issues due to the setCurrent function signature not matching in the library vs the implementation. ie: in TMC26XStepper.cpp, it's defined as: void TMC26XStepper::setCurrent(unsigned int current) in the implementation it's called like this: setCurrent(st.getCurrent(), R_SENSE, HOLD_MULTIPLIER)

I'm sure that the wrong setCurrent is being used here, as it should have been that of your library, and not of the TMC26XX library. Hence: the definition in your library: void TMC2130Stepper::setCurrent(uint16_t mA, float R, float multiplier)

It became apparent that I should NOT enable both HAVE_TMCDRIVER if i'm using the TMC2130 Driver...
I simply undid all my changes above, and only enabled the TMC2130 Driver (with HAVE_TMCDRIVER).

I was able to Compile Successfully after this....

I think a Sanity Check is in order here :) We should not enable both libraries...

@vilsed , Please Advise on your configuration, and steps you are taking to compile this for the LPC1768?

As I am able to compile @teemuatlut branch just fine, I would expect your would be able to do so too... Some Notes: in configuration.h you must change the Motherboard:

define MOTHERBOARD BOARD_RAMPS_14_RE_ARM_EFB

Don't Forget the EFB Part at the end, some sanity checks only say you must select BOARD_RAMPS_14_RE_ARM which is not entirely correct, if you try to compile with PlatformIO, without changing the MB.

in configuration_adv.h, you must change only #define HAVE_TMC2130, together with the the axis you are using: Example: #define X_IS_TMC2130

and Compile in PlatformIO using the PIO Build(LPC1768) at the bottom left hand corner. Note: Don't bother using the build button, as you will notice it picks up the mega board instead!

[tig33r]

Is stepper working good? I compiled succesfully but motors did not work. Mks sbase here with spi on J8 connector.

[psavva]

I'll have to test it tomorrow. I still need to build my harness to try...

On Thu, 28 Dec 2017, 23:37 tig33r, notifications@github.com wrote:

Is stepper working good? I compiled succesfully but motors did not work. Mks sbase here with spi on J8 connector.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/8334#issuecomment-354361747, or mute the thread https://github.com/notifications/unsubscribe-auth/ABYypkE5b3gAis8qPYOqnfC47wkIP-pGks5tFAoxgaJpZM4QWzGh .

[vilsed]

@psavva My setup is Re-ARM (LPC1768) with Ramps 1.4 EFB on a delta printer. I'm already past the hurdles of having correct pins definition enabled, I have built 2.0 previously for that board using generic A4988 drivers. Besides getting compile errors while having enabled features like babystepping, filament change and a few others (which I frankly can't remember), and having some weird action going on with SPI in general (poor RRD full graphic controller update rates while printing from SD card), I had the printer up and running. Decided to upgrade to TMC drivers and there comes the problems :)

From the beginning I had enabled only HAVE_TMC2130, so I did not have the errors you mentioned. Although today there were other problems with missing classes in TMC2130Stepper.h (Bob_the_Kuhn updated TMC2130 library, not stock arduino one). Somehow managed to fix all those up and I'm still back at missing classes in TMC2130Stepper.h for TMC2130Stepper_COOLCONF.cpp, as I had in the beginning.

I'm a mechanical engineer by trade, just getting my toes wet with coding now (besides commenting and uncommenting lines in Configuration.h :) ) so please, bear with me :)

Hope to have some time tomorrow to try and compile a fresh copy of teemuatlut branch. I may have messed up something unknowingly...

[psavva]

This is the branch you can test: https://github.com/teemuatlut/Marlin/tree/LPC_TMC2130?files=1

[vilsed]

PlatformIO updated today, and this branch doesn't compile at all. Although main 2.0 branch does try to compile. At least as much as it did yesterday.

`Error: Traceback (most recent call last): File "c:\users\vilius.platformio\penv\lib\site-packages\platformio__main.py", line 120, in main cli(None, None, None) File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py", line 700, in call__ return self.main(*args, **kwargs) File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py", line 680, in main

rv = self.invoke(ctx)

File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py", line 1027, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py", line 873, in invoke return ctx.invoke(self.callback, ctx.params) File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py", line 508, in invoke return callback(*args, *kwargs) File "c:\users\vilius.platformio\penv\lib\site-packages\click\decorators.py", line 16, in new_func return f(get_current_context(), args, kwargs) File "c:\users\vilius.platformio\penv\lib\site-packages\platformio\commands\run.py", line 102, in cli for k, v in config.items(section): File "c:\users\vilius.platformio\penv\lib\site-packages\platformio\util.py", line 53, in items items.append((option, self.get(section, option))) File "c:\users\vilius.platformio\penv\lib\site-packages\platformio\util.py", line 60, in get return self.VARTPL_RE.sub(self._re_sub_handler, value) File "c:\users\vilius.platformio\penv\lib\site-packages\platformio\util.py", line 66, in _re_sub_handler return self.get(section, option) File "c:\users\vilius.platformio\penv\lib\site-packages\platformio\util.py", line 57, in get value = ConfigParser.get(self, section, option, **kwargs) File "C:\Users\Vilius.platformio\python27\Lib\ConfigParser.py", line 618, in get raise NoOptionError(option, section) NoOptionError: No option 'build_flags' in section: 'common' `

[psavva]

There is probably some problem with your PlatformIO installation...

Try delete it totally, and reinstall atom and PlatformIO from scratch. I build the branch just fine. I will test the Re-Arm with the drivers installed today.

On Fri, 29 Dec 2017, 11:52 vilsed, notifications@github.com wrote:

PlatformIO updated today, and this branch doesn't compile at all. Although main 2.0 branch does try to compile. At least as much as it did yesterday.

`Error: Traceback (most recent call last): File "c:\users\vilius.platformio\penv\lib\site-packages\platformiomain.py", line 120, in main cli(None, None, None) File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py", line 700, in call return self.main(*args, **kwargs) File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py", line 680, in main

rv = self.invoke(ctx)

File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py", line 1027, in invoke return _process_result(sub_ctx.command.invoke(sub_ctx)) File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py", line 873, in invoke return ctx.invoke(self.callback, ctx.params) File "c:\users\vilius.platformio\penv\lib\site-packages\click\core.py", line 508, in invoke return callback(*args, *kwargs) File "c:\users\vilius.platformio\penv\lib\site-packages\click\decorators.py", line 16, in new_func return f(get_current_context(), args, kwargs) File "c:\users\vilius.platformio\penv\lib\site-packages\platformio\commands\run.py", line 102, in cli for k, v in config.items(section): File "c:\users\vilius.platformio\penv\lib\site-packages\platformio\util.py", line 53, in items items.append((option, self.get(section, option))) File "c:\users\vilius.platformio\penv\lib\site-packages\platformio\util.py", line 60, in get return self.VARTPL_RE.sub(self._re_sub_handler, value) File "c:\users\vilius.platformio\penv\lib\site-packages\platformio\util.py", line 66, in _re_sub_handler return self.get(section, option) File "c:\users\vilius.platformio\penv\lib\site-packages\platformio\util.py", line 57, in get value = ConfigParser.get(self, section, option, **kwargs) File "C:\Users\Vilius.platformio\python27\Lib\ConfigParser.py", line 618, in get raise NoOptionError(option, section) NoOptionError: No option 'build_flags' in section: 'common' `

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/8334#issuecomment-354423993, or mute the thread https://github.com/notifications/unsubscribe-auth/ABYypncnqPXAcJ0KSL-FSpRb9fOmOW9lks5tFLZSgaJpZM4QWzGh .

[vilsed]

Somehow I managed to download a wrong Marlin fork. Figured it out. It compiled successfully, will try uploading to the board this evening.

[psavva]

I am now trying to figure out which pins I should be using on the Ramps board for the SP.

ifndef SCK_PIN

#define SCK_PIN           P0_15

endif

ifndef MISO_PIN

#define MISO_PIN          P0_17

endif

ifndef MOSI_PIN

#define MOSI_PIN          P0_18

endif

ifndef SS_PIN

#define SS_PIN            P1_23

endif

How do I now figure out which Port/PIN maps to which PIN on the Ramps board? How do I map this?

[psavva]

I found that Panucatt has the Mapping on their Schematic. I'm using this as a basis. The current configuration actually maps to the Hardware SPI pins, which is used by the LCD.

I was under the impression that different Pins should be used for the Software SPI, as not to conflict with the LCD SPI?

I think I'm missing something here... Can someone guide me as to how this should be done?

Do I understand correctly on the Re-ARM that the Software SPI will always be used, Ignoring the fact that the hardware SPI is defined on these pins? Or should I define any new pins for the SPI?

[vilsed]

@psavva I'm currently trying to figure this out too. As I understand, SPI is a parallel interface, so we should be able to use the same pins as LCD is using (0.18, 0.15 and 0.17). Could be wrong though