Arduino project update…

October 14, 2013 Leave a comment

Having ‘completed’ my Arduino ‘stomp box’ project I immediately realized that I needed it to do more (of course!). Originally my intention was to have one switch control the wet/dry mix on my effects unit and the other to control the selected patch, flip flopping between them, all pretty simple stuff. But then I thought about ‘soloing’.  My MIDI keyboard controller (a keytar) does not send MIDI volume information, nor can I program it to do so, so I needed some way to be able to easily switch from normal playing mode (medium volume) to solo playing mode (boosted volume). Guitar players usually have a pedal they just stomp on to boost the signal to a pre set level for solos so I figured it’d be useful to be able to do that  using my stomp box.

The two switches gives me four conditions, although because you cannot really use the normal (I.E. not pressed) state that leaves three conditions. Left button pressed, right button pressed or both pressed. Since I was using the first two conditions already that left the ‘both buttons pressed’ condition to use to switch between normal and solo mode.

Well that turned out to be a lot more complex that you’d think. I could not simply look at the switches and wait for them both to be pressed because the chances of my foot hitting them both at the exact same time is pretty much nil so the code would always detect one or the other on it’s own initially and I was using that state to switch the mix or patch. Waiting to see if the other switch was pressed was not really an option because how long do you wait?

What is interesting though is that a binary switch has more than just an on or off state.  It also has the ‘changed state’ condition. I.E. It was open but is now closed and it was closed but is now open, often referred to as leading and trailing edge (of a square wave which is what you’d see on an oscilloscope if you tracked the voltage on the switch contacts).

So what I did was to switch the mix and patch selects to work on the trailing edge signal, that is when you release the switch and I made the volume switch occur on the leading edge, that is when both switches closed. That way I could distinguish between the events quite easily.

But wait, there’s more!

Originally I hard coded the normal volume level but than I thought, well what if I want to change it for a particular setup (I figured leaving the ‘solo’ setting at max all the time was fine), I’ve only got two switches and I’ve used them all and how do I indicate what is going on to the user, I’ve only got two LEDs?

Well it turns out a switch can have yet another state and that is how long it has been pressed. Since the mix setting now triggers on the switch release, I can now time how long a single switch has been pressed and if it exceeds a certain time (I figured five seconds was a good value, not too long, not too short) then I put the unit into ‘program’ mode. To indicate this to the user I made the LED next to the switch flash.

Once in ‘program’ mode I can listen for the other switch being pressed and each time it is pressed, increase the ‘volume’ setting. Rather than have the user step through 127 values I figured having ten steps would be enough that I convert into MIDI signal levels by multiplying by 12 which gives me ten settings of 12 through 120.

To indicate the current volume ‘setting’ I make the second LED flash using a slow setting for the lowest volume and increasing the speed for each click up to ten at which point it cycles around back to the lowest setting.

Pressing the first switch again takes it out of program mode and saves any new volume setting.

But wait, there’s even more!

The chip on the Arduino has 1024 bytes of EEPROM that can be used to save data even when the device is turned off. So after setting a new volume I now save the setting in the EEPROM so that when the device is switched on I can restore the volume setting from the save value in the EEPROM. I also flash the second LED one to ten times (depending on the save volume level) at switch on to indicate to the user (me!) the current ‘normal’ volume level in use.

Summary

I have been very impressed with the quality of the Arduino IDE and the programming libraries available for it. In the past I have done micro processor (PIC) programming but used assembler. That’s fine but you have to do EVERYTHING yourself and testing can be ‘interesting’ to say the least. Writing in C and using existing libraries made development and testing very easy and speedy, especially when used in conjunction with the Arduino IDE’s ‘serial monitor’ and loads of debugging messages in the code (wrapped in #if defined statements so I can easily remove them for the ‘live’ code).

If I have on criticism of the Arduino IDE (or rather the doc) it is that as well as the extensive Arduino specific libraries you can also use code from the AVR project, which I wanted to do for the EEPROM support since it has more function (block read/write) than the Arduino library. However even though the AVR library is included in the Arduino IDE, it is not very well documented in the Arduino doc. It was only by chance (thank you Google) that I even came across the AVR library and I then spent quite a long time trying to figure out how to add it to the Arduino IDE before I found that it was already there.

Advertisements
Categories: Uncategorized Tags: ,

Using the SDSF REXX interface – Part 2

October 12, 2013 Leave a comment

Here’s another REXX exec using the SDSF REXX interface. This one will issue a command to the local system.

/**REXX**************************************************************/   
/*                                                                  */   
/* ISSUCMD - Issue a command.                                       */   
/*                                                                  */   
/* Input args:                                                      */   
/*                                                                  */   
/*  Delay   - # secs to wait for command completion                 */   
/*  Command - Command to issue (do not need leading /)              */   
/*                                                                  */   
/* Output: return code from the command.                            */   
/*                                                                  */   
/********************************************************************/   

parse arg delay, command                                                 

Address 'TSO'                                                           

IsfRC = isfcalls( "ON" )                                                 

saved_delay=ISFDELAY            /* save curr delay */                   
ISFDELAY=delay                  /* Set delay time  */                   

address SDSF "ISFEXEC '/"command"'"                                     
saverc=rc                                                               

ISFDELAY=saved_delay            /* restore delay   */                   

IsfRC = isfcalls( "OFF" )                                               

return saverc

Using the above command to start a started task on the local system:

/* REXX */
rc=ISSUCMD(2,"S CICS1")
return 0
Categories: Mainframe, REXX Tags: ,

Using the SDSF REXX interface – Part 1

September 24, 2013 Leave a comment

I thought I’d post some of the REXX execs I have written that use the SDSF REXX interface. This first one determines if a job is executing, either on the specified lpar if passed in or anywhere in the sysplex if not (subject to shared JES spool limits). It returns a return code and, if executing, the lpar the job (or stc) is executing on separated by a space which you can then parse out.

/**REXX**************************************************************/   
/*                                                                  */      
/* JOBSTAT - Determine if a job is executing or not                 */   
/*                                                                  */   
/* Input args:                                                      */   
/*                                                                  */   
/*  Jobname - Required.                                             */   
/*  sysname - Optional. If specified will only look for job on that */   
/*                      system.                                     */   
/*                                                                  */   
/* Output:                                                          */   
/*  0 - Job is not executing (on requested system if specified)     */   
/*  1 - Job is executing + sysname of system job is running on      */   
/*                                                                  */   
/********************************************************************/   

parse arg jobn , sysname                                                 
upper jobn                                                               
upper sysname                                                           

Address 'TSO'                                                           

IsfRC = isfcalls( "ON" )                                                 

saved_delay=ISFDELAY                                                     
ISFDELAY=0                                                               

executing=0                                                             
executing_on=""                                                         

address SDSF "ISFEXEC ST "jobn                                           

if sysname <> "" then do                                                 
   do i = 1 to jname.0                                                   
      if queue.i = "EXECUTION" & actsys.i = sysname then do             
         executing=1                                                     
         executing_on=actsys.i                                           
         end                               
      end                                 
   end                                     
else do                                   
   do i = 1 to jname.0                     
      if queue.i = "EXECUTION" then do     
         executing=1                       
         executing_on=actsys.i             
         end                               
      end                                 
   end                                     

ISFDELAY=saved_delay                       

IsfRC = isfcalls( "OFF" )                 

return executing" "executing_on

Using the above exec to determine if a job is executing on the local lpar:

/**REXX**************************************************************/   
/*                                                                  */  
/* Call jobstat to see if job is running in the local system        */
/*                                                                  */   
/********************************************************************/  

sysname=MVSVAR('SYSNAME')   /* local sysname */

parse value jobstat("MYJOB",sysname) with executing lpar 
if executing then do                               
   /* do 'executing' stuff here */ 
   say 'Job is executing'         
   end                                             
else do                                           
   /* Do 'Not executing' stuff here */  
   say 'Job is not executing'                                 
   end 

return 0

Using the above exec to determine if a job is executing in the sysplex and on which lpar:

/**REXX**************************************************************/   
/*                                                                  */  
/* Call jobstat to see if job is running anywhere in the sysplex    */
/*                                                                  */   
/********************************************************************/  

parse value jobstat("MYJOB") with executing lpar 
if executing then do                               
   /* do 'executing' stuff here */ 
   say 'Job is executing on '||lpar         
   end                                             
else do                                           
   /* Do 'Not executing' stuff here */  
   say 'Job is not executing'                                 
   end  

return 0
Categories: Mainframe, REXX Tags: ,

Arduino project finished…

September 15, 2013 Leave a comment

The missing components turned up so I spent a day building the MIDI interface board. Figuring out where to place the various connectors and components on the prototyping board so that the connectors were not blocked by the sides of the box it would all live in was far harder than writing the code or designing the circuit. Once I had it all hooked up I tried it and…. nothing! Well, the switches worked as did the LEDs but I was not getting a MIDI signal out of the box, or if I was the other end was not detecting it. When I looked at the circuit for the commercial MIDI interface board I had it was a lot simpler than my over engineered effort so after some hesitation I ripped out the output circuit from my board and replaced it with a much simpler version based on the commercial units circuit (basically one wire and a couple of resistors, no transistors). Swapped over the output cables to account for the circuit changes and tried it…. nothing again!

Now  had been very careful about hooking up the output wires to the MIDI connector the right way around. Seems I was not careful enough! On a whim I swapped them and of course it worked. It was probably OK the first time, just the had the wires the wrong way round but at least it works now.

This is what the inside of the project looks like:

StompBoxInside

As you can see pretty cramped. The board you can see is the MIDI interface board I made. The Arduino is underneath that screwed to a piece of board that is then glues to the case to hold it in place and insulate it from the metal box.

I always think that it is a shame to hide all the electronics as so much effort goes into creating it. In some ways it’s like programming, you can put a lot of effort into making some code as elegant as possible but in the end, all people care about is ‘does it work’.

So with that in mind, this is what the completed project looks like:

StompBoxFinished

The power switch is on the other side of the box but that’s it. The left button controls the bypass on the effects unit and the right button switches between two patches. The LEDs just indicate the current setting that is selected for each switch. All pretty simple.

Time to go play!

Categories: General Stuff Tags: ,

When projects collide…

September 12, 2013 Leave a comment

The iPhone/iPad app I am developing is for live music use (not giving away any details just yet since I am sure any reasonable iPhone developer could knock up the same app in a couple of days and beat me to the finish line!) which means your hands are not so free. My original idea was to use a blue tooth connected foot pedal that I already happen to have (Airturn BT-105) to control the app. However it occurred to me that it would be pretty simple to add a blue tooth shield to an Arduino, hook up a few switches and make my own blue tooth enabled stomp box to control my app, plus I could have more than the two switches my current pedal has.

So, once the current Arduino project is done I’ll be starting on creating a blue tooth enabled stomp pedal to control this app and looking at blue tooth enabling my app to work with my custom pedal.

Categories: Coding, iPhone, xcode Tags: , , ,

Back to the iPhone project

September 11, 2013 Leave a comment

The Arduino project is on hold because I am waiting for parts to arrive which appear to be on a VERY slow boat from Thailand so I decided to get back to my iPhone project.

My iPhone app (which will be mainly an iPad app when it is done) currently has three view controllers. I guess you can think of these as logical screens. Each one has it’s own implementation file (class) and when I originally wrote things, just to get it all going I used a lot of global variables to share data between the view controllers. This got messy really quickly so I’ve been reworking the code over the past couple of weeks to get rid of the global variables and pass data between the view controllers the ‘proper’ way.

I also need to make the app support device rotation as well as both iPhone and iPad devices so for no particular reason I chose to attack the device rotation topic first. So far it is proving to be an interesting challenge to make all my view controllers  work correctly since only the currently displayed VC receives the orientation change messages so any hidden VC has to check the orientation when it is redisplayed and reconfigure the screen to match the current orientation. Let’s just say that this part of the project is still a ‘work in progress’!

I have managed to sketch out what I want the main interface to look like but all the current work is just to get to the point where I can actually implement the main app function and has nothing to do with the actual ‘guts’ of the app.

Oh, and now we have new devices (no doubt with new physical screen sizes) and a new OS to contend with as well.

Still, it keeps me off the streets at night!

Categories: Coding, iPhone Tags: , ,

Maintaining the OMEGAMON XE for CICS on z/OS Globals with PARMGEN

September 10, 2013 Leave a comment

Global settings selection

May aspects of the operation of OMEGAMON XE for CICS on z/OS data collection and operation are controlled by global settings. These settings are held in a PDS member of the library allocated to the RKC2GLBL DD in the ‘classic’ collector address space (also known as the OCCI). Typically the hlq.RKANPARU library is allocated to the RKC2GLBL DD

Global members have member names of the form KC2GLBxx where xx is a two character suffix. The global member to be used by the OCCI when monitoring a given CICS region is selected by including a KOCGLBxx dummy DD in the CICS startup JCL, where the xx in the DD name matches the suffix of a global member in the library allocated to the RK2GLBL DD in the OCCI address space.

If you do not add a KOCGLBxx DD to the CICS region, then xx defaults to ’00’ (zero zero).  If the selected global member is not found by the OCCI address space then it uses a default set of values.

PARMGEN support for the CICS globals

Currently PARMGEN support for the CICS globals is limited to copying global members from a source PDS into the run time environment’s hlq.RKANPARU library.

The source PDS to be used is specified by the KC2_CLASSIC_KC2GLB_SRCLIB parameter in the rte member name in the PARMGEN WCONFIG library and defaults to the ICAT INSTDATA dataset.

If you are not converting from an ICAT install for the RTE you can point this parameter at any library you chose and place your completed global members in there. During the deployment phase of the RTE, the deployment jobs will copy the global members from this library to the run time’s hlq.RKANPARU library.

If you are NOT using the default global member for a CICS region you will still need to manually add a KOCGLBxx dummy DD card to the CICS startup JCL in order to select the corresponding global member.