Try right clicking on the "ProcessorExpert.pe" component in your BSP project and then click on "Generate Processor Expert Code". You should then rebuild your BSP project, and then you may have to clean and rebuild your application project in order for the linker/indexer to find the newly generated files. You should see several documents in the Generated Code folder, including "PE_Types.h", "IO_Map.h", "PE_Const.h", "PE_Error.h", "SS1.c", SS1.h".
Hope this helps!
1. Unless something has changed since MQX 3.8, the MQX drivers only support Master mode in the Kinetis version (even though the hardware definitely supports both master and slave modes)
(In a recent project with MQX 3.8 and the K60, I had to write my own low-level SPI driver since we needed slave <with DMA ping-pong> capability)
It is possible that this has changed. In the current project, we only need master mode, so I have not done full research on this for MQX 4.0.2
2. Baud rate is only valid for the master.. (this is on a hardware level)
Baud rate is used to set the clock signal (which is output from the Master)
On the slave side, the clock signal is an input - which is what sets the operation speed for the slave.
Or, in other words, the Slave *MUST* run at the clock rate of the master, so only the master gets to decide what that is.
There are a number of other things here too...
1. I don't see "open_spi_driver()" and "spi_init()" documented in the MQX I/O Driver Guide. Are they your own routines? If so, what do they have in code? (There does not seem to be an attached project either)
2. (assuming everything else is working properly), you don't want a single task calling the read_write for the master and the slave consecutively. One will start (and maybe even complete) before the other is handled.
You will need two separate tasks, one for the slave side, and one for the master side.
The slave task should issue the request for transfer before the master task. It should then just wait until the master task decides to communicate.
Then the master task will start the (bi-directional) communication when it issues the transfer request, and both tasks will then complete the communication.
I understand the SPI functionality. I also understand it should be two separate tasks now, however not sure as you say, if there is a high level function writtern for it in MQX 4.0. Low level functions mean write to registers and there must be a correct sequence for it. I can risk it but not sure if it works by the end of day!
for spi init please look into bsp folder, it should be mqx/bsp/init_bsp.c. For open spi, I believe the fopen in my code does that.
also SPI must be activated in user_config.h file.
Do you guys have any sample for master slave spi at low level so I follow the sequence?
Unfortunately, the code I wrote belongs to a customer (we do contract development work)
I do not see an spi_init() function, only a structure that should be filled in.
Reading your posts, it is clear that the HW is setup correctly (as the bareboard project works).
One thing I noticed (and had issues with myself, recently): You should indeed open the correct spi port, and indicate the proper CS line.
For CS1 (on master) use "spifd = fopen ("spi2:2", NULL); (The number after the colon indicates the CS lne to use - see MQX I/O Driver User's Guide)
For Slave, it should not matter, as there is only one SS line (mapped to the CS0 pin) - you might try indicating it anyway ("spi1:1")
This part all hinges on whether MQX4.0 drivers support SPI in slave mode, and I have not had confirmation or denial from MQX, nor have I seen in the docs if this is so.
When it comes to the coding I did, it was quite complicated...
We had data *pouring* in the SPI port (in slave mode).
I looked at the MQX code (source is included in the MQX folders) and created a new driver (modeled on the master driver using DMA).
This driver used ping-pong DMA to constantly move data into large buffers.
When a buffer was full, I used an ISR to update the DMA (to point to a new next buffer), chain the full buffer into a buffer queue, and post a semaphore to let the application code know it had a new buffer of data available.
This was done on a K60 processor, so we have that in common.
This also required DMA programming and using the DMA interrupt to notify application code, etc.,
BTW. The MQX drivers are also configured so you can use DMA for SPI I/O
The only way I could know for sure if MQX 4.0 supports slave mode SPI on the K60 would be to look into the source code, or get a statement from MQX person(s).
The code has been changed considerably from 3.8.
I really do not have the time to dig into the code deeply enough to find out. I did a quick look, but it was not immediately obvious.
If you do have the time, the driver code is in: mqx/source/io/spi
You might even consider using the debugging in CW and step into this code and follow the execution - especially what happens in the IOCTL that sets the transfer mode and the RW call itself.
Then look at the HW register contents to see if they have been set up similarly to what is done in the bareboard project.
What is the particular error that you are getting on the slave side (change code to print error number, not just "ERROR" string)?
Hope this helps...
unfortunately the new SPI driver doesn't support slave. It is stated in the MQX Release Notes:
SPI I/O Driver
This driver supports the operation master mode.
Ok, so does this mean that I have to make my own low level register read and writes to configure the SPI slave? Would you know of the exact sequence for CTARx and MCR, etc registers configurations....
Answering your questions above:
I used DMA to save data in RAM memory (not Flash).
Ping-pong DMA means that the DMA is pre-configured to fill one buffer, and then immediately start filling the next, even before the interrupt has been processed for the filled buffer.
The ISR then has to set up the DMA for the 3rd buffer before the second buffer has filled.
Saying DMA is a "third party" is like saying that "interrupts" are a "third party"
Yes, using DMA is more complicated, but once set up, it is almost a "must" for high data rates.
Basically, DMA handles data transfer without interrupts until a buffer is filled (or emptied).
Then, a single interrupt is generated, and the ISR - application, whatever - can process complete buffers instead of single transfers.
Having said that, if your data rate is low, there is no particular need to use DMA (although the master SPI driver can use DMA as written)
In another post here, a Freescale employee now confirms that MQX SPI drivers do not support slave mode...
That means that there is a significant amount of "driver writing" work ahead of you if you want to support SPI slave in MQX.
It might have been more meaningful to have the IOCTL that tries to set the slave mode return a "not supported" error code, in addition to failing at the transfer request.
Ok, so we got the news! I actually were going to make my own low level code...direct register read and write to spi registers....but I thought I try using high level functions first and see if they work for spi slave....
so is that what you did exactly in your project? direct register reads and writes?
You can always try the Processor Expert SPI_Slave component.
Hi Travis Long,
Is it possible to add processor expert in MQX 4.0 project? I have not seen any option for that?
My Bareboard project with processor expert is working fine for spi slave. But I need MQX RTOS for my project....
You should have Processor Expert in your MQX BSP, but even if you don't you can use your bare metal PE code files with your MQX project. They should work together nicely. Just make sure that MQX is not initializing the SPI driver by disabling it in the user_config.h in your BSP.
Oh, Ok, I see now, When I click on my bsp_twrk60d100m, I see the components...so here if I add components like spi master, and slave, say spi2 and spi 1 respectively, then I have to generate a "new processor expert code" by clicking on the button, and then the spi1 and 2 are getting initialized in my mqx? somewhere in my main.c code?
Not quite. You will use them in the same way you do in your bare metal app. When you generate the code for PE, you whould see the new code files in your Generated Code folder in your MQX BSP project. You can then build your bsp and you should be able to include the SS1.h header into your app and call the functions as you do from a bare metal app. You do NOT want to enable the same SPI device in MQX since PE is handling it for you, you should define BSPCFG_ENABLE_SPI0 to zero in your user_config.h and MQX shouldn't try and initialize it or change any of your setup.
Ok so when I do that (I added spi1 as slave and spi2 as master to my components in bsp + in user config turned off all spi units).
I did a clean bsp and rebuilt it. but there is an error about incorrect toolchian that never used to happen before!! My toolchain is freescale not gcc and not sure why it is picking on my toolchain!
I have the snapshot attached.
secondly there is nothing in the generated code folder!!!
I should get my word back, actually the problem still exists no matter I switch to gcc or freescale bsp! Sorry I was looking at different project!!!
there is nothing in generated code:
would you know after addition of my SPIs to bsp components why nothing shows up in generated code section?
I converted all my projects to Freescale compiler by the way and getting no error at the moment. Also my MQX 4.0 projects are created to use Freescale compiler (just for your information).
Here is the snapshot:
Retrieving data ...