Issue with definitions of MOSI, MISO and SCK

Guys,

When using the Adafruit Max31855 library (for thermocouples), I ran into an issue with the way that the pin numbers for MOSI, MISO and SCK are defined in libmaple, which conflicts with their use in the Adafruit library.

The crux of this is that on AVR and SAM cores, MISO is a global variable e.g.

static const uint8_t MISO;

However in libmaple, MISO is defined using #define, i.e a preprocessor macro.

So that when the preprocessor runs on the Adafruit lib, it screws up the library, because it attempts to replace the text inside the lib.

I think the best solution is to follow what the AVR and SAM cores do, and have vars for these, (even though its going to waste some RAM)

There may be a way of fixing this and still use a #define, but ultimately I think its best to do what the Arduino team do…

Hence I propose that I comment out these lines in wirish.h

#define SS BOARD_SPI1_NSS_PIN
#define MOSI BOARD_SPI1_MOSI_PIN
#define MISO BOARD_SPI1_MISO_PIN
#define SCK BOARD_SPI1_SCK_PIN

This is also how the ESP8266 – implementation defines MISO, MOSI and SCK. Though, they do also do it for the I2C – pins. Would anything break if you did it for the I2C – pins, too? Wouldn’t it be a good idea to follow the common conventions, even if we are not aware of any problems with the current approach now? I don’t know, I’m not in charge here or anything, but personally I’d probably still choose the common convention in this case simply for compatibility’s sake.

I think there are definitions for SCL and SDA in the Wire lib. So I’d have to remove them, but think its best to be consistent.

So after I’ve fixed it for SPI, I’ll fix it for I2C

BTW.

Putting the vars into variant.h does work.

It just helps if I select the correct board. For some reason the mouse slipped and I’d not selected the Maple mini – which is the only variant that I’d updated.

But now that I’ve selected the correct board, it looks like my thermocouple test program is working again.

So I I’ll just test it with an ILI9341 board (and libs) and if thats OK, I’ll change all the variants in the same way

somewhen i’ve seen a post about i2cand defines, pretty sure i replied to that thread.

http://www.stm32duino.com/viewtopic.php … i2c+define

discusses if — a user should have to edit or even if a user should be editing core files e.g. Wire.h to make a sketch work, specifically ‘SDA’ & ‘SCL’

stephen

I have an opinion, as usual, but I cannot remember what it is

But…
For over 18 months we have attempted to replicate the good and evil of the Arduino way of doing things. Heaven or Hell, I suspect we should continue consistently down that road for the F1xx. For the F4 stuff, the gurus of that platform probably should chime.

Ray

mrburnette wrote:For the F4 stuff, the gurus of that platform probably should chime.

The issue with I2C were just that SCL and SDA where defined to be the normal default pins for I2C, but the definitions are not used in the default constructor, as the constructor directly uses pin numbers.

So that particular anomaly can easily be addressed in the constructor by changing the pin number to the defined name.

With the SPI defines, I cant see any problem with using static const vars, because they would hopefully be compiled into flash, and even if they are put in RAM, its only 4 bytes.

The only downside I can see, would possibly be that the access to these vars may be very slightly slower than when using the #defines, but in practice they are not used very often or in time critical locations, and with the magic of modern compilers, there may be no difference at all.

static const uint8_t variables should end up in the .rodata section or turned directly into an immediate constant. They shouldn’t end up in ram. The advantage to using static const uint8_t vs a define is that you should be able to see the value in gdb.

Rick,

Thanks. I was hoping they would not end up in RAM

At the moment, Ive put the new vars in variant.h, but the other possible locations are board.h , but neither if then had vars in them before.
board.h has lots of defines, and variant.h was fairly empty and from what I recall, variant.h was added for compatibility with later versions of the IDE.

It may be possible to move the entire contents of board.h into variant.h, and remove one file ( as there seems to be duplication of what variant.h does with what board.h does), but I am not sure what else would need to be changed to do that tidy-up

Edit

It looks like I can move all the defined from board.h into variant.h and things still compile OK.

But I’ll do some more testing to confirm.

I have made the first set of changes so that all variants declare

static const uint8_t SS = BOARD_SPI1_NSS_PIN;
static const uint8_t SS1 = BOARD_SPI2_NSS_PIN;
static const uint8_t MOSI = BOARD_SPI1_MOSI_PIN;
static const uint8_t MISO = BOARD_SPI1_MISO_PIN;
static const uint8_t SCK = BOARD_SPI1_SCK_PIN;

Clarity! Good!

I encounted an ARM board of prominence that called the SPI signals DOUT, DIN. With respect to which end of the link?

To make it unambiguous the terms MOSI and MISO were established.

I have a problem with those definitions. I’m getting compilation error for a library Touch Screen STM as described here -> http://www.stm32duino.com/viewtopic.php … 019#p16019

Can You please check it out ?

The problem described in the other thread is not related with terms definitions described here.
MOSI = Master Out, Slave In
MISO = Master In, Slave Out.