spi on other pin

[bobricius]

I have custom boad with atsamd21e18 with micro sd card connected to
miso a19
mosi a16
sck a17
ss a18
I want try zero audio but I can change only ss pin, but I have no idea when I can use another spi pins. I think that all pins I used are another spi connected to edbg chip. thanks

[pixelpixi]

Hello. I also have a custom board based on the samd21e18a and would like to change the sercom device used by the Wire library. I think this is essentially the same problem that @bobricius has. (but Wire instead of SPI)

@cmaglie I would be happy to code a fix and submit a pull request, but wanted to check first to see if you have already started or if you have thoughts on how it should be done?

It looks like variant.cpp can define the serial objects (sercom0, sercom1, etc.) but can't change which handler is used by which library.

One simple idea I had is to allow variant.h to #define the sercom and handler names. So, ie, variant.h:

#define WIRE_SERCOM sercom0
#define WIRE_SERCOM_HANDLER SERCOM0_Handler

and in the wire library (with something similar in the other SERCOM based libraries) :

#ifndef WIRE_SERCOM
#define WIRE_SERCOM sercom3
#endif

#ifndef WIRE_SERCOM_HANDLER
#define WIRE_SERCOM_HANDLER SERCOM3_Handler
#endif

TwoWire Wire(&WIRE_SERCOM);

void WIRE_SERCOM_HANDLER(void) {
Wire.onService();
}

Please let me know if that sounds like an acceptable solution or if you have other ideas about how you'd like it to be done. Thanks a lot!

[aethaniel]

Hi @pixelpixi, @bobricius, why not creating your own variant?
You could easily derive it from the existing Arduino Zero by instantiating the appropriate handlers according to your hardware choices.
With the new board manager, your own variants could be pretty easily integrated, I guess.

[pixelpixi]

Hi @aethaniel. I have my own variant ( https://github.com/modulolabs/arduino-hardware/tree/master/samd ) but unfortunately the variant can't override which SERCOM is associated with which library. That's because the libraries themselves are hard coded to specific SERCOM numbers. ie, in Wire.cpp:

TwoWire Wire(&sercom3);

void SERCOM3_Handler(void) {
Wire.onService();
}

So I think the only way of doing it is to fork the entire core, which obviously I'd rather not do.

[aethaniel]

Hi Erin,

Indeed, these definitions shall be present in variant files and not in core API.

I will do some tests tomorrow and if OK transfer these lines to their right place.

Cheers,

T.

On 1 August 2015 00:26:41 CEST, Erin Tomson notifications@github.com wrote:

Hi @aethaniel. I have my own variant (
https://github.com/modulolabs/arduino-hardware/tree/master/samd ) but
unfortunately the variant can't override which SERCOM is associated
with which library. That's because the libraries themselves are hard
coded to specific SERCOM numbers. ie, in Wire.cpp:

TwoWire Wire(&sercom3);

void SERCOM3_Handler(void) {
Wire.onService();
}

So I think the only way of doing it is to fork the entire core, which
obviously I'd rather not do.

---

Reply to this email directly or view it on GitHub:
#3 (comment)

Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.

[aethaniel]

Hi @pixelpixi, @bobricius, @cmaglie,

Sorry to be late on this, it haven't been able to test before today.
In fact, it isn't as simple as I thought: SPI and Wire are libraries and thus the objects are instantiated only when these libraries are used by a given sketch. I understand this should have bring some benefits in reducing binary footprint on small devices.
The IDE seems to parse the sketch file to find matches on #include lines and then add according files to compilation.

My tests were to move definitions and instantiations into variant.[h|cpp] but link failed because of lack of class/function/symbols as SPI and Wire were not part of my test sketch.
Conditioning the objects declarations and instantiations would work only for either SPI or Wire but not for both due to dual inclusion protection of headers (good and expected).

In the current state, platform.txt and board.txt disallow me to add these files into the build but maybe @cmaglie would have a precise idea on how to force add some files.

My own personal opinion would be to move, for ARM devices, SPI and Wire files to core API folder but this could cause waves.

After discussing with a friend on the problem, some ideas emerged but all of them lead to some modifications in IDE behaviour:

• adding in variant specific files for declaration and instantiation, e.g. /[variant folder]/libraries/SPI/variant_SPI.[h|cpp] or maybe another file extension to avoid systematic compilation
• adding on command line some -D to propagate the information a specific library will be used, thus allowing conditional parts of code (this shall be the easier way to do as IDE parse for library header, e.g. -DLIBRARY_SPI)

Anyway, this must be solved to allow new variants to emerge without constraints, considering all muxing possibilities of SAMD21.

[aethaniel]

@pixelpixi, by the way, you shouldn't have to duplicate the whole core into your variant to obtain fast working result: did you try only to duplicate libraries/SPI, modified to match your SERCOM?

[pixelpixi]

Hi @aethaniel. Thanks for your work on this.

I didn't try duplicating just the library I need. I didn't realize that is supported. Neat! I'll give it a shot.

Too bad that moving the definitions to variant.cpp didn't work. That would have been an elegant solution.

How about my original suggestion of using macros in variant.h to define which SERCOM object each library uses? I think that would avoid the library dependency/inclusion problems you were having.

I can code it up further and submit a pull request if you like. Let me know.

Thanks,
Erin

[aethaniel]

Hi @pixelpixi,

If you can give a try about duplicating the library, it could be nice indeed. Warning: it is only an hypothesis. I'm clearly not sure if it would work.

By the way, after years it seems I'm still trying to provide a solution following the most complex path: your proposal is much more efficient in term of rework cost.

My previous work was here: https://github.com/aethaniel/ArduinoCore-samd/tree/wire_spi_instances_in_variant
I will work on another branch to implement/test your proposal!

[aethaniel]

Hi @pixelpixi, at first glance it should be OK for SPI to have the definitions into variant.
Having the same behaviour with Wire will need code update as pins are hardcoded into the class.

Investigation in progress, will come back to you later today, normally.

[aethaniel]

Hi @pixelpixi @bobricius @cmaglie,

I have something compiling nicely with Arduino IDE and bringing the customization you both need on either Wire or SPI:
branch: https://github.com/aethaniel/ArduinoCore-samd/tree/sercom_defs_in_variant
commits: https://github.com/aethaniel/ArduinoCore-samd/commits/sercom_defs_in_variant

3 commits are present: one for variant file update, one for SPI and one for Wire:
aethaniel@a780f1f
aethaniel@7fbd665
aethaniel@b81bc46

Could you please update your local files and tell me if theses updates fit your needs or if I missed something?

If OK, I will submit the PR to Cristian.

Thanks

[pixelpixi]

Hi @aethaniel. I tested this for the Wire library and it works great for me! Thanks for coding the fix and let me know if there's anything else I can do.

[cmaglie]

Fixed by #24.