# FreeRTOS SPI - What to change... **URL:** \ **Category:** Kernel\ **Created:** [October 27, 2017, 4:43pm UTC](https://forums.freertos.org/t/freertos-spi-what-to-change/6826 "2017-10-27T16:43:16Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [October 27, 2017, 4:43pm UTC](https://forums.freertos.org/t/freertos-spi-what-to-change/6826/1 "2017-10-27T16:43:16Z")
**[k1mgy](https://sourceforge.net/u/k1mgy/)** wrote on [Friday, October 27, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/fcb4b6f7/#ca54): SAMG55J19 Atmel Studio ASF 3.35.1 FreeRTOS 7.3.0 + PDC + SPI I have existing code that uses the ASF SPI driver. Therefore I have calls such as spi\_write\_packet() which go directly to ASF. I have created a call to freertos\_spi\_master\_init() with appropriate parameters which will instantiate in standard mode. Is this all I need to modify? Will my calls to spi\_write\_packet() be intercepted and redicted to the FreeRTOS versions? Not looking forward to re-writing my HAL driver for SPI if I don’t have to 🙂 ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [October 27, 2017, 5:38pm UTC](https://forums.freertos.org/t/freertos-spi-what-to-change/6826/2 "2017-10-27T17:38:38Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Friday, October 27, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/fcb4b6f7/#ca54/0a58): > Is this all I need to modify? Will my calls to spi\_write\_packet() be > intercepted and redicted to the FreeRTOS versions? It’s been a long time since I looked at that - but I don’t think so. You would need to call the FreeRTOS specific versions. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [October 28, 2017, 8:11am UTC](https://forums.freertos.org/t/freertos-spi-what-to-change/6826/3 "2017-10-28T08:11:41Z")
**[k1mgy](https://sourceforge.net/u/k1mgy/)** wrote on [Saturday, October 28, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/fcb4b6f7/#81ab): My next question is whether or not it’s necessary to use the FreeRTOS SPI driver in specific circumstances. In my test case, I see some fairly strange behaviour when making SPI-related calls from within FreeRTOS tasks, perhaps a result of tasks not blocking and SPI transactions being non-atomic. Is there a means of making SPI work from within FreeRTOS tasks, perhaps by holding up the RTOS system long enough to complete these and then resuming RTOS? Of course, begs the question as to why use FreeRTOS in the first place, but perhaps this question will reveal a simpler solution for me than having to re-write our HAL. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [October 28, 2017, 4:13pm UTC](https://forums.freertos.org/t/freertos-spi-what-to-change/6826/4 "2017-10-28T16:13:07Z")
**[edwards3](https://sourceforge.net/u/edwards3/)** wrote on [Saturday, October 28, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/fcb4b6f7/#1ab6): If the SPI is used by multiple tasks then just protecting it with a mutex might be enough. Ideally make it interrupt driven. ---
**Author:** ![richard-damon](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/richard-damon/32/38_2.png) [@richard-damon](https://forums.freertos.org/u/richard-damon)\ **Post date:** [October 28, 2017, 4:49pm UTC](https://forums.freertos.org/t/freertos-spi-what-to-change/6826/5 "2017-10-28T16:49:53Z")
**[richard\_damon](https://sourceforge.net/u/richard_damon/)** wrote on [Saturday, October 28, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/fcb4b6f7/#4946): I generally find that the vendor supplied generic I/O functions, while normally useful for a ‘typical’ single threaded application, tend to be lacking for a multi-threaded applications like those using FreeRTOS. The exception being for those specificailly written for FreeRTOS or working with a generic OS wrapper. The biggest issues being they tend to ‘spin-wait’ for the I/O and have no protection for being used in multiple threads. Sometimes you can live with these limitations, more often you need to adapt them (or at least wrap them) for use in a FreeRTOS application. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [October 30, 2017, 1:58pm UTC](https://forums.freertos.org/t/freertos-spi-what-to-change/6826/6 "2017-10-30T13:58:49Z")
**[k1mgy](https://sourceforge.net/u/k1mgy/)** wrote on [Monday, October 30, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/fcb4b6f7/#6f84): For my work the SPI is not used by multiple tasks. My SPI drives a FTDI graphics controller, which requires a certain set of command transactions to be received in an established group (a start of command set message, followed by various LCD commands, and completed by an end of command set message). These are, ideally, sent in a contiguous stream. A timer-based xTask is running through the command set periodically as this updates the LCD screen. I have two theories as to why my LCD results are variable. One has to do with how tasks are managed. Question: is it possible that a timer-based task may be re-spawned before the other instance is complete? If this happens, it explains a lot. And if so, how can I block the task from re-spawning at the next timer event if it’s not done? Another theory is that the event is put on hold for other tasks. The time unserviced somehow bothers the SPI, perhaps in mid-transmission, and bolluxes up the works. Question: is this a possibility? If so, how to make the SPI stuff unhindered? Also, I am a bit perplexed as to how to use the FreeRTOS SPI driver and its relation to FLEXCOM. FLEXCOM is what is being used presently. Would I continue to use FLEXCOM but just replace the init, read and write functions? ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [October 30, 2017, 2:58pm UTC](https://forums.freertos.org/t/freertos-spi-what-to-change/6826/7 "2017-10-30T14:58:26Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Monday, October 30, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/fcb4b6f7/#6f84/037e): > Question: is it possible that a timer-based task may be re-spawned > before the other instance is complete? If this happens, it explains a > lot. And if so, how can I block the task from re-spawning at the next > timer event if it’s not done? By which, do you mean the SPI is managed inside a software timer callback function? That might not be the best way in any case if it prevents the callback function returning for a long time. Try to keep callbacks short because, while the callback is executing, no other callbacks can execute. That answers your question too - no only one time callback function can execute at once as all the timer callbacks execute in the context of the same timer service task. That answer is only valid if my assumption is correct - you are talking about timer callbacks and not tasks. > Another theory is that the event is put on hold for other tasks. The > time unserviced somehow bothers the SPI, perhaps in mid-transmission, > and bolluxes up the works. API is synchronous so it would only be an issue if the LCD device timed out if the SPI clock was interrupted by a higher priority task. The best way to do this would be create a buffer than contains the message you want to send to the LCD, then DMA the buffer to the SPI port and have the hardware manage the transmission. If you hardware does not allow that then at least control the transmission using interrupts (start a transmission, have the SPI interrupt send the next data, until all data is sent, then disable the interrupt until the next transmission). ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [October 30, 2017, 7:16pm UTC](https://forums.freertos.org/t/freertos-spi-what-to-change/6826/8 "2017-10-30T19:16:43Z")
**[k1mgy](https://sourceforge.net/u/k1mgy/)** wrote on [Monday, October 30, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/fcb4b6f7/#edbb): Excellent, helpful information. The task callback performs the periodic LCD screen refresh. It does so by issuing a series of commands, which eventually are sent over the SPI buss to the FTDI graphics controller. I’m not aware of any other way to make this stuff happen other than within a task which is triggered to run every [n] ticks, with the code that needs to be run within the callback function. If there’s another way, please lead me to a technique. In your suggestion, where the SPI transmission is buffered to DMA and then handed off to the SPI driver, would this driver be the built-in ASF, or would I have to use the FreeRTOS driver? An example of this, if you know of one, would save me a lot of agony 🙂 ---
**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\ **Post date:** [October 30, 2017, 7:24pm UTC](https://forums.freertos.org/t/freertos-spi-what-to-change/6826/9 "2017-10-30T19:24:58Z")
**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Monday, October 30, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/fcb4b6f7/#edbb/b7a6): If only one task is using the SPI then just using the regular ASF code is fine. ---
**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\ **Post date:** [October 30, 2017, 9:45pm UTC](https://forums.freertos.org/t/freertos-spi-what-to-change/6826/10 "2017-10-30T21:45:14Z")
**[k1mgy](https://sourceforge.net/u/k1mgy/)** wrote on [Monday, October 30, 2017](https://sourceforge.net/p/freertos/discussion/382005/thread/fcb4b6f7/#790d): One task reads data from the touch screen and another updates it. I’ll need to bring those two into a single task. Maybe doing so will help. If anyone can offer an example for a use of the FreeRTOS SPI driver, it would be appreciated.