ChibiOS Free Embedded RTOS

snegovick wrote:Hi, Ive used this https://gist.github.com/alanbarr/8203430 code as a starting point, rewrote it and added almost everything needed to do manual connect to specified ssid, start tcp session and send data. If anybody is interested in this code, Ill share it on github.

That gist was actually mine. I gutted part of my code for some help on the TI forums and was waiting to get it in a working state before making it public.

In case anyone is interested, you can find it here: https://github.com/alanbarr/ChibiOS_CC3000_SPI and includes some documentation.

It doesn't do a whole lot; it act's as the SPI driver to TI's CC3000HostDrver and also handle asynchronous events. Everything else is expected to go through TI's CC300HostDriver API.

I welcome any suggestions.

I have developed an OSHW product using ChibiOS and CC3000: BrewBit Model-T. I started with TI's stock driver, and eventually rewrote large portions of it to better suit ChibiOS and fix a ton of bugs. It is fairly stable now, but the performance of the CC3000 itself leaves something to be desired in my opinion.

Our code is on github if you want to check it out:

https://github.com/brewbit/model-t

I stumbled on alanbarr's repo a few weeks ago. It looks like we ended up with pretty similar solutions for the SPI driver where we start up a SPI handler thread and signal it with a semaphore from the IRQ line interrupt. I have not looked extensively at his solution, so it might include some of the fixes that I made:

• Simplified the SpiReadAfterHeader() which was done pretty stupidly by TI. Instead of using the SPI packet length field to figure out how big the payload is, they are reading into the payload to get the HCI header, then using that to figure out how much data to read. All you have to do is read the SPI header, and it tells you how much data to read! No need to mix the SPI and HCI concerns into the same module.
• Moved the message parsing into that thread as well to ensure that you don't start processing the next message before the last one is fully processed.
• Fixed a race condition where the application layer does not setup the buffers for incoming data before the data arrives over SPI.
• Replaced infinite wait loops throughout the driver with semaphores.
• Added timeouts for messages because the CC3000 likes to lock up entirely on occasion.
• Reorganized the socket IO thread to remove tight coupling to the HCI/WLAN modules and use ChibiOS synchronization primitives.
• And probably some other stuff I am forgetting.

Hi Alan5,

I've used your driver for the CC3000, I was able to get it to work using sparkfun's wifi shield on my Nucleo F401RE. However, I've only been able to create outgoing TCP and UDP connections, I can send outgoing TCP traffic just fine. When I started creating inbound TCP connections (socket, bind, listen, accept), it failed on recv - the ChibiOS almost always goes into an unhandled exception handler. I haven't had time to look into where it's getting the exception, I was wondering if you had ever come to this problem or do you recently have any updates on the gits?


Regards,
Vergil

vpcola wrote:Hi Alan5,
I've used your driver for the CC3000, I was able to get it to work using sparkfun's wifi shield on my Nucleo F401RE. However, I've only been able to create outgoing TCP and UDP connections, I can send outgoing TCP traffic just fine. When I started creating inbound TCP connections (socket, bind, listen, accept), it failed on recv - the ChibiOS almost always goes into an unhandled exception handler. I haven't had time to look into where it's getting the exception, I was wondering if you had ever come to this problem or do you recently have any updates on the gits?
Regards,
Vergil

Hi,
Its been a few months since I've looked at this so I might need to re-jog my memory. With respect to the code though, I have no local changes that have not been pushed up.

How are you implementing handling inbound connections? In general there's a few things which can cause issues:
If you are using multiple threads CC3000 API calls should be protected by a mutex.
If you are using other peripherals e.g. I2C make sure they do not use the same DMA lines as SPI.