https://www.linkedin.com/pulse/top-10-machine-learning-projects-github-gregory-piatetsky-shapiro?trk=eml-b2_content_ecosystem_digest-recommended_articles-91-null&forceNoSplash=true

I have upgraded the SPI handler to interleave chatter with multiple SPI devices.  The problem is that I only have one SPI device that I know works.  I tried plugging in a uSD card and talking to it, but I’m not getting anything definitive back from it.  It may be answering, or maybe not.  I don’t want to write all that protocol code for talking to the uSD card yet.

I really wish I had some dumb-arse SPI device I could use to check out the code.

However it all seems to work, as far as it goes.  I keep swapping between the DW and the uSD (working or not) and the DW keeps working just fine, so I think I’m going to declare victory and move on.

One thing I notices, and which disappoints me, is that the processor doesn’t sleep between character interrupts on the UART, or between bytes on the SPI.  I’m not sure how much there is to be saved there, because the thread-suspend/recover code is probably quite substantial, and I suspect the scheduler doesn’t send things to sleep unless there is a promising delay coming up.

        rtos_suspend   = 1;
        expected_time  = os_suspend();
        expected_time &= TIMER_MASK;

        if (expected_time > 2)
        {
            prev_time       = NRF_RTC1->COUNTER;
            expected_time  += prev_time;
            NRF_RTC1->CC[0] =
                (expected_time > TIMER_MASK) ? expected_time – TIMER_MASK : expected_time;

Need to clarify what I have done, because the next step is to extend this model to handle the SPI bus. I’m trying to prototype multiple threads accessing a common resource – the UART in this example.   I also want to make sure that I can shut down the processor as much as possible while this is going on. This is not rocket science, just a RTX familiarization exercise.

I’m using RTX which is an RTOS provided by Keil, but available for free via ARM, and Nordic.  It’s reasonably lightweight, and allegedly well-tried and tested.  The question is can I get it to do what I need.

My test program needs to demonstrate use of a mutex to serialize access to a shared resource (the UART, as a stand-in for the SPI bus), and show that it can be driven from a variety of types of threads: the main loop, user threads, and a timer event handler.

The test program sets up five threads, three of which try to output to the UART in parallel.   Here’s what each thread does:

• Following initialization crap, main() loops forever, alternately suspending itself for 1s, and then sending two “wakeup” inter-thread signals to the two user-threads, called  Blinky1, and Blinky2.  
• A timer-event handling thread is woken by the RTC every 100ms, and sends a text message to the UART.  The message records the number of times the handler has been called. 
• Blinky1, and Blinky2 simple wait for a signal from the main loop, and then try to send 10 text messages to the UART as fast as they are able.
• A fifth thread, “Idle”,  runs only when all other threads are idle.

Each thread is assigned a LED which get’s turned on whenever it is the active thread.

1. First, Blinky1, and Blinky2 never interleave their individual messages.  Why is this?  
2. It is interesting how much of the time the Idle thread is running.  Even though there is a lot of UART activity the Idle LED stays on almost all the time.   

Here are the LED assignments, and below is a video showing the program running.

Managed to get a simple 2-thread Blinky program running under RTX.  The lack of documentation about how to structure the project was the problem.  There’s another configuration file, that has to be set up for each project.

Today I discovered that I have to make a new project for each different arrangement of drivers.  It ought to be handled with a few compile-time defines, but that would make things even more ugly.

Now I’m seeing if I can create a thread to handle UART activity.  that means creating a whole new project.

https://ringly.com/?mc_cid=77ddbfb2b9&mc_eid=cd10fd185c

I have been exploring RTX.  After having told David that there are all these real-time operating systems, but they all seem too complicated, I decided I should revisit, and check out that this is still the case.  Better to use tried and trusted code, than re-do everything.

RTX is the RTOS that Keil push, and it is kind of available for free via Nordic.  There is an example, for the 51422.  I tried to drag the code over to Eclipse and compile it, but there are a bunch of defined constants, and some unwritten conventions that are getting in the way of compiling everything.

It’s been three days of struggle so far, and I’m really not getting to the bottom of it, so I’m beginning to think that it is a PITA.

One issue is that RTX assumes a particular kind of inbuilt timer, and the 51822 doesn’t have that, so it has to be fudged.

We have a “way” of licensing the Keil uVision v5.11 environment, but I’m not sure if that method will work for the latest 5.17 version – and then of course would it work for the next release?  Another complete PITA to try that out, and then all the code would have to be ported to uVision.

For light relief from hacking, I looked over the eval board David gave me, and decided to see what was better about it, compared to the nRF51822.  I see four significant advantages.

A few nice additions, and a bunch of code-architecture changes that caused me to make a lot of changes to my code.

Slowly running through all my test programs to drag them into the new world, and to make sure I understand how all this new stuff works.

The usual tedious, head-scratching to figure it all out.

I already have a configuration file for each type of board.  I use compile-time defines to decide which board file to use, and a bunch of other defines to decide what set of drivers to include in the compile – e.g. UART, or semo-hosting.  Nordic have decided that all of these kind of constants should be held in a config file.  Because each of my programs can be compiled with a different bunch of drivers, depending on what it does, I have introduced a new directory called “config” that contains the various configurations. Config has a subdir for each different configuration of drivers, so I have one called config/UART that sets up all the constants for the UART drivers.  I expect I’ll have to do the same for SPI, TWI and so forth.

I am hopeful that this change will make it a helluva lot easier to multi-thread the code.

http://www.technologyreview.com/news/543716/your-doctor-doesnt-want-to-hear-about-your-fitness-tracker-data/

Your Doctor Doesn’t Want to Hear About Your Fitness-Tracker Data

Some patients are bringing troves of fitness-tracker data to their checkups, but the doctor might not find it all that helpful.

Yet while sensor-embedded wearables will need to get a lot more reliable before doctors find them useful, Sehgal acknowledges that devices such as the Apple Watch or the Polar heart-rate monitor have been useful because they’ve helped some people get more active. However, he says, “Where I think the rubber really meets the road is: can you take people with chronic disease and manage it with these devices? It’s still too early to say.”