I had high hopes of getting a significant portion of the design finish this weekend, but it seems like I’ve hit a road block.  It seems that upgrading to the latest operating system might have hindered my efforts to create the SteadyClip.  The PSoC 4 Pioneer Kit doesn’t seem to enumerate on the USB port when I plug the device into a Windows 8.1 machine.  As it stands right now, I cannot get any code loaded into my device. I’ve opened a ticket with Cypress and hopefully this gets resolved quickly.

 

On the electronic hardware front, I am waiting for some parts to arrive.  I have also added several parts to my EDA suite’s library. When and if the time comes to spin a board, I should be able to pump one out revisions relatively fast.  On a separate note, since I no longer have access to my lab and tools of my last job, I might opt to use off the shelf hardware for the whole project.  Previously, it was rather convenient to etch a set of boards in the kitchen sink.

 

So what’s new?  Well I’ve thought about the approach that I will take to create this design.  Perhaps this is only in hindsight, but I think I might have bitten off more than I can chew. What I mean by this is that there is a lot of mechanical parts to this project, and I am woefully unprepared in terms of tools and skill to create anything mechanical.  I’m looking to see if there are any suitable pieces of hardware off of EBay that I can make modifications in order to get frame that I can use as the mechanical prototype.  The alternative is to head to the hardware store, buy a Dremel type tool, and see if I can make something meaningful.  I am leaning towards the EBay option.

 

On the software side, I’m worried about the program timing determinism. Since I will be using a PID as the control loop for the motors, the timing will need to be rather critical.  The D portion of the PID constant uses the rate of the controller error.  If my time slices are off, then the D portion of the controller will not work properly.  The loop that does the PID loop iteration must be relatively accurate.  Due to this timing complication, software becomes rather complicated to write.

 

I’ve taken a look at some event processors that will take care of the timing for me.  Instead of having to play around with multiple interrupts racing against each other, the event processor should facilitate the whole affair.  Think of it as a simplified operating system, and as long as I remain within the guidelines of the API calls, I should be able to guarantee the timing requirements of my PID loops.  Since I’ve used the QP event processor before, I’ve decided to see if they have a solution for the ARM Cortex M series.  Luckily a lot of the difficult work in porting over the code to ARM Cortex M has been done.  I just needed to compile the library using the gcc compiler included in PSOC Creator package.  At least this portion of went pretty smoothly.  Now if only I can load the code and test it out in my PSoC 4 Pioneer Kit…