Skip to content

cpu/fe310, board/hifive1: SPI support#10833

Closed
pyropeter wants to merge 4 commits intoRIOT-OS:masterfrom
beduino-project:pr/fe310-spi
Closed

cpu/fe310, board/hifive1: SPI support#10833
pyropeter wants to merge 4 commits intoRIOT-OS:masterfrom
beduino-project:pr/fe310-spi

Conversation

@pyropeter
Copy link
Contributor

@pyropeter pyropeter commented Jan 21, 2019

Please note: This is not tested as much as I would like. Please wait with merging until I had a look with an oscilloscope.

Contribution description

  • This implements periph/spi on cpu/fe310 and board/hifive1
  • Hardware Chip Select lines were not implemented, since they don't offer any benefit for transfers larger than one byte in size, due to limitations of the hardware. This simplifies the code.

Testing procedure

make -C tests/periph_spi BOARD=hifive1

Issues/PRs references

maribu and others added 4 commits January 21, 2019 15:11
@PeterKietzmann PeterKietzmann added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Area: drivers Area: Device drivers Area: boards Area: Board ports labels Jan 22, 2019
Copy link
Member

@maribu maribu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks pretty good to me. I have found something to nitpick about, though ;-)

Sadly I'm unable to test this. Maybe I should consider buying a board...

USEMODULE += periph_pm

# include common periph drivers
USEMODULE += periph_common
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

periph_common is added twice

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway, this is not needed, so just remove it.

/**
* @brief Allocation device locks
*/
static mutex_t lock;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it would make sharing the code with future versions of the CPU that could potentially have multiple SPI interface easier when you use something like that:

#define SPI_INTERFACE_NUM         1
static mutex_t lock[SPI_INTERFACE_NUM];

(I'm only suggesting this, not insisting on this.)


void spi_init_pins(spi_t bus)
{
(void) bus;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should not needed because of the assert(bus == 0); below. (I believe both GCC and clang should still be aware that bus was used even when NDEBUG is defined, but I'm not 100% sure about that. So please correct me if I'm wrong.)


int spi_acquire(spi_t bus, spi_cs_t cs, spi_mode_t mode, spi_clk_t clk)
{
(void) bus;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would make life easier to also add assert()s for bus and cs here, so that developers are supported in finding their bugs in using the SPI interface.


void spi_release(spi_t bus)
{
(void) bus;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again I would suggest to add an assert()

uint32_t rxdata = SPI_RXFIFO_EMPTY;
while (rxdata & SPI_RXFIFO_EMPTY) {
rxdata = SPI1_REG(SPI_REG_RXFIFO);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about

uint32_t rxdata;
do {
    rxdata = SPI1_REG(SPI_REG_RXFIFO);
} while (rxdata & SPI_RXFIFO_EMPTY);

@maribu maribu added the Platform: RISC-V Platform: This PR/issue effects RISC-V-based platforms label Jan 23, 2019
@stale
Copy link

stale bot commented Aug 10, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Aug 10, 2019
@stale stale bot closed this Sep 10, 2019
@kaspar030
Copy link
Contributor

I'll try to use phillip to test this!

@miri64 miri64 reopened this Sep 10, 2019
@stale stale bot removed the State: stale State: The issue / PR has no activity for >185 days label Sep 10, 2019
@fjmolinas fjmolinas requested a review from aabadie December 13, 2019 09:14
Copy link
Contributor

@aabadie aabadie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm very interested by this PR. I also think that #12934 could be helpful to determine the cpu core clock frequency.

USEMODULE += sifive_drivers_fe310

USEMODULE += periph
USEMODULE += periph_common
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not needed, just remove it.

USEMODULE += periph_pm

# include common periph drivers
USEMODULE += periph_common
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway, this is not needed, so just remove it.

set_csr(mstatus, MSTATUS_DEFAULT);

/* trigger static peripheral initialization */
periph_init();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is already in master. Maybe just rebase this PR so this change is dropped from GitHub diff ?

* #define CLOCK_CORECLOCK (38400000ul)
*/
/* As defined in boards/hifive1/board.c CPU_DESIRED_FREQ **/
#define CLOCK_CORECLOCK (200000000ul)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might be interested by #12934 where the value of the core clock is automatically computed when using the PLL or HFXOSC.
Maybe rebase this PR on top of it ?

FEATURES_PROVIDED += periph_rtc
FEATURES_PROVIDED += periph_rtt
#FEATURES_PROVIDED += periph_spi
FEATURES_PROVIDED += periph_spi
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could also be applied to the hifive1b (I can test on this board actually).

DIV_UP(CLOCK_CORECLOCK, 2 * 10000000) - 1,
};
#undef DIV_UP
#define SPI_NUMOF (1)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to have some struct based configuration. See #12917 where I changed the UART to use this scheme. I find this convenient, at least to know which pins are connected the serial interface and it's more consistent with most of other board configurations in RIOT (like STM, SAM, nRF).

@pyropeter
Copy link
Contributor Author

@aabadie This is quite old, and I forgot most of the details regarding this PR. I also stopped using RIOT and I don't have a lot of time at the moment, so I will not continue working on this PR. Feel free to take the code and do whatever you like with it. (But please update the author and copyright information so that it doesn't look like I alone wrote the resulting code. Where appropriate, feel free to remove my name completely.)

@pyropeter pyropeter closed this Dec 13, 2019
@aabadie
Copy link
Contributor

aabadie commented Dec 13, 2019

I was planning to write the SPI driver when I saw your PR. I'll use it as a base and will keep your authorship. You have already done most of the work.
Anyway, thanks for your contribution @pyropeter!

@aabadie
Copy link
Contributor

aabadie commented Dec 16, 2019

The replacement PR is here: #12957. Except the configuration and the reuse of clock improvement from #12934, the initial version was already working well. Thanks for the work @pyropeter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: boards Area: Board ports Area: drivers Area: Device drivers Platform: RISC-V Platform: This PR/issue effects RISC-V-based platforms Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants