What is Spark Core application area?

Hi, I have ordered one Spark Core in order to evaluate what is it good for.

Currently I have implemented (in one week):

  1. Blink RGB LED when Jenkins continous integration starts building some software project (eg. jUnit tests). Set color to green, yellow, red depending on build result and number of tests failed.
  2. Control Syma S107 helicopter using IR LED (with BC548B transistor for better IR range). Control via usb serial commands. Control via DirectX/DirectInput game devices via UDP datagram socket.
  3. Write simple text on 1.8ā€™ā€™ OLED COLOR (Digole). Drawing bw or color image was not successful due to low memory on Spark Core

The three things above are nice DIY home toys. Can Spark Core do some more serious tasks like streaming 160x120 256 color pixels over SPI to OLED? Can it upload pictures from serial camera (UART) to web (realtime/almost realtime) ? What realtime jobs is Spark Core suitable for? I thought Spark Core will be a small MCU with wifi capability (like Arduino with Wifi shield) plus it will be battery powered and small and I can build a quadcopter with GPS+realtime camera+joystick control.

What I hate on Spark so far:

  1. Need to be connected to cloud 24/7 (I want just UDP communication with my laptop).
  2. Low memory size for the code. (Is it possible to upload the code to CC3000 EEPROM?)

WHAT IS YOUR VISION ON SPARK CORE USAGE AND USE CASE SCENARIOS IN THE FUTURE?

Can Spark Core be used to build something like this or should I look for something else? http://www.seeedstudio.com/depot/Crazyflie-Nano-Quadcopter-Kit-10DOF-BCCFK04A-p-1527.html

  1. Need to be connected to cloud 24/7 (I want just UDP communication with my laptop).

I believe itā€™s in the works to eventually not connect to the Spark cloud for development. This is high priority on the :spark: team list.

  1. Low memory size for the code. (Is it possible to upload the code to CC3000 EEPROM?)

Thereā€™s and external flash with 2mb unused space and that should provide more than the CC3000. Not sure if you can but the external flash would be much preferred, in my opinion.

Iā€™m sure there and some realtime jobs out there with the Spark core in place and definitely more to come!

Spark core is relatively new but the development progress is moving real fast and things are getting better each day.

I can only say thereā€™s for sure more good things/projects to come with the spark core!! :smiley:

1 Like
  1. Yes, I know theyā€™re working on offline capabilities and I know about testing branch with multi-threaded loop, so Wifi wonā€™t block loop() function. The problem is that Spark Core wonā€™t handle uS communication with it. For example when sending pulses over IR LED, it needs to send some 0 a 1 in some pulse with uS precision using delayMicroseconds(). From what Iā€™ve read, this wont be accurate with context switching.

  2. Ahh, I was thinking about 2MB external flash :slight_smile: not CC3000 EEPROM then. It would be very very viable to use this for the code. Iā€™d like to use C++, classes and OOP to the max. Right now I write procedural code without any reusable components (libraries).

I previously worked on a power controlling device which authorises userā€™s access to machines.

Before I had a spark core, I wondered how to push booking, user info data etc on a Daily basis to hundreds of authorisation devices.

When I knew about spark core, I immediately knew this would be the solution for my application and the team will eventually even open source the server side applications.

Not sure if you did but I havent seen such projects on scale with excellent support and constantly improving code base and tools with strong community support.

My device is going to prevent untrained users for ever running CNC machines, Table saw and other specialized equipment. Thatā€™s a realtime application if you are talking about and my scale of deployment is in terms of a factory/production labs dealing with workplace safety.

:slight_smile:

Iā€™m thinking about miniArduino+Zigbee and Cubieboard A20 or Phoenix A20 ITX. I would be happy if Spark Core would use ARM Cortex M3 to be closer to the two than miniArduino.

I was working on NCLab.com for University of Nevada, Reno. They have a PLASM module (patent pending) in Python, which can be used for students to learn CNC/CAD effectively (not sure if CNC commands are implemented, but CAD is pretty good).

We should compare with the right factors. Those mentioned are mini linux boards and spark core is another class itself.

Spark Core v1.0 uses the STM32F103CB - ARM 32-bit Cortexā„¢-M3 CPU Core

This quadrotor uses RF24L01+ STM32F103CB which is the same Microcontroller and adding RF24L01 to :spark: core is possible :smiley:

@war1st Sounds like you have some great skillset so why not help work on the Spark core and make it the best you could ever imagine? :smiley:

Seems like i didn't make the wrong choice backing 2 :spark: core after answering your questions!

Yeah, Iā€™m waiting on my $300 order from China to EU with a lot of sensors and stuff for my Spark :-). I definitely love it, but realtime processing might be a show-stopper for me, so I have to investigate it more. I wish Spark Core could be used to build a mini quadcopter like this: http://www.seeedstudio.com/depot/Crazyflie-Nano-Quadcopter-Kit-10DOF-BCCFK04A-p-1527.html ā€¦in the video, they have also serial camera/LED light/GPS sensor or wireless charging feature (have ordered one: http://www.seeedstudio.com/depot/Wireless-Charging-Module-p-1354.html). But my bottleneck is Spark Core communication speed and camera/display buffer processing (RAM limitation).

cyberluke, because of the open nature of the Spark, you can actually ignore the core firmware and write your own! Some members talked of running an RTOS. The only catch is if you do, you have to do your own CC3000 interfacing. Anything goes! :smile:

1 Like

Lots of great discussion happening here! @peekay123 and @kennethlimcp are right in that if you get a bit deeper into the firmware you can disable the cloud connection entirely. We played around with the context switching fix, and the alternate timer fix for running cloud tasks in the ā€˜backgroundā€™, but there are potential timing issues with those. Right now there is also work happening to make our interactions with the CC3000 non-blocking.

As it stands the firmware wonā€™t interrupt your code while itā€™s running, so you could certainly do microsecond timing on tasks. If you want to block for a long time or control your own flow more closely, you just need to call the SPARK_WLAN_Loop function every once and awhile (about every 10 seconds).

Actually it does interrupt and process the Timing_Decrement(); function within the main.cpp every 1ms. This updates the breathing cyan RGB and lots of other little states. Not sure how long this function takes, but it defintely messes up critical microsecond timing. I'm guessing it's longer than 50us.

SPARK_WLAN_Loop(); is also the proper case if you want to call this function.

My bad, youā€™re totally right @BDub! The Timing_Decrement does run every 1ms, but itā€™s meant to run as quickly as possible. Thanks for keeping me on my toes! :slight_smile:

1 Like

Thanks for pointing out, I might try disabling this function. Syma s107 is quite ok with that for now (a lot of delayMicroseconds during the pulses).

Thx @kennethlimcp Iā€™ll be glad to help though I still keep fighting with ā€œcyan flash of deathā€. :frowning: If I find a solution Iā€™ll post a guide within the next week or so.
Behind the Spark lies really great idea and a brilliant community to develop it further. To my mind this little device definitely has a big future ahead of it.
@cyberluke As for the robotics my very personal opinion that OR-WRT is the easiest and cheapest way to create nice wi-fi toys

@peekay123: Have been looking on RTOS for Spark Core and found only some FreeRTOS port for ARM Cortex M3. That would be so much work and it would be so much time consuming, that it would be quicker and cheaper to replace Spark Core with some other board for realtime video data or miniquadcopter.

@war1st: Cheapest way it is not, because the license is only for non-commercial purposes. I donā€™t have problem with software part at all. I am able to connect some UART/SPI/I2C module and make it work. The only bottleneck is Spark Core RAM, which cannot transfer 20+ kB of data. This is making the 32-bit ARM M3 @ 72 MHz unusable.

I was pretty disappointed when I found this thread and realized I have to be connected to the cloud for the Spark Core to run my programs.
Where exactly can I start looking in the firmware to go about experimenting with disabling this?
I think this platform has an opportunity to be really revolutionary and Iā€™m still excited about it, but this particular limitation would greatly decrease my ability to do a lot of the things Iā€™d like to do with it.

This is temporary till the new features come out!

Right now you must 1st connect to the cloud before you can connect/disconnect from the cloud.

I think programming locally in your IDE can disable that but requires some tinkering with the code.

Others would be able to shed more light then they reply you! :frowning:

@jfenwick check out this easy example of how you can disconnect your Core from the Cloud after it starts up and first checks in with the Cloud. after it's disconnected you can press the Mode button to get it reconnected so you can flash a new program over the air from the web IDE

1 Like

They have put a lot of work in cloud features. You can do also a local communication now (had success with running UDP and TCP server on my PC). Running local private Spark Cloud is a high priority in Spark development I think. So it should be possible soon. You can also alter the whole firmware and disable cloud functionality and upload your code over USB right now.

So wait for this: Private Cloud + possibility to start and run code without connection to cloud at all (but with wifi)
Though I donā€™t think we will get this soon. Still too many issues to solve in core itself