ChibiOS Free Embedded RTOS

Not 100% sure whether this is a bug, or just me using things in an unintended way. Anyway, its the same in at least Chibi 20 and 21.

I have a QSPI flash device as the only component connected to the QSPI bus on a 32F767. To avoid access collisions, I set:
#define SNOR_SHARED_BUS TRUE
This should ...

I just create a small batch file in the project directory which starts up openOCD in a project-specific way, such as:
REM starts in the Eclipse directory
cd ..\tools\openocd\
REM bin\openocd -s "scripts" -f board/st_nucleo_f7.cfg -l /Temp/Chibi/oocd.log -f add_rtos.cfg
bin ...

The standard 'make' process runs other programs once linking is complete - for example the one that generates the listing.
Is it possible to add another similar task without editing the Chibi standard files?
(I've got it working by editing rules.mk at present)

I make sure virtually everything is reset to startup values, which may well be overkill. In particular, I found that not clearing down the MPU caused some problems.

Go for the "Giovanni" approach. (Although a bit more testing than I've done wouldn't be a bad idea)

My suggestion definitely doesn't work with 16-bit systick (not that it was intended to). There may also be a problem with higher frequency 32-bit systicks, but I'm not inclined to pursue what was ...

Any feedback?

Giovanni
I like that general approach:
a) It's reasonable to require systick >=1kHz (I haven't seen systick <1kHz on any of the examples, and 10kHz or more seems about right for the faster processors, which are the ones with Ethernet).
b) One function regardless - no test cases to ...

I've compared the two options for SYSTICK of 5kHz, 10kHz, 50kHz, 100kHz.

For the first two, both proposals agree.
For the second two, the results diverge.

Given this, I'd tend towards my solution because its easier to understand (extend the SYsTick counter beyond 32 bits, then divide), which is ...

Didn't find that proposal.

I'd tend towards the SourceForge suggestion, simply on the basis that it appears to have covered all the options (I'd really just covered the one that mattered to me).
However depends how well its been tested.
I'll try and run it through my test harness in the next few ...

I concur. I've added a routine which extends the resolution of chVTGetSystemTimeX() for that specific case (it doesn't appear necessary to include the adjustments by 1):

/**
* This routine creates a 32-bit incrementing timer tick which returns all possible
* values before wrapping round&#46 ...

Yes, that's it, thankyou. (Maybe a little update to the documentation? I couldn't find any detail on this)

Thinking about it, this could probably be handled automatically in adc_lld_start_conversion().

The A-D drivers I looked at all had a piece of code along the lines of:
cfgr1 = grpp->cfgr1 ...