Wednesday, September 21, 2011

Play Spotify Over Airplay from Mac

How on Earth are we going to do this (for free)?!  Without this feature Spotify is little more than background noise for me.

Potentially useful tools available to us:
MacPorts
DarkIce
IceCast
Jack
Soundflower

I will be noodling this one, feel free to join in!

Wednesday, September 14, 2011

Apple USB-Ethernet Adapter Drivers for Windows 7 64-bit [UPDATED x2]

Through a series of incredibly unbelievable events I ended up needing to use an Apple USB-Ethernet adapter on this fully loaded Alienware M17X laptop running Windows 7 64-bit. The rest of you will probably be approaching this from the much more believable but equally incredible event of installing Boot Camp on your new MacBook Air. Congratulations.

[UPDATE 1/9/2013]
The driver link below has been updated now that MobileMe is dead!

[UPDATE 9/14/2011]
The proper driver is now included in Boot Camp 4.0 from Apple.  At the time of this writing the only way to get 4.0 is to download it from your Mac by running Boot Camp assistant and asking it to download Windows support files.
[/UPDATE]

Originally posted 8/10/2011...
Anyway, why these drivers are so hard to find is beyond me. Here’s the link to them on my iDisk. When iDisk becomes iCloud I will have to update this link, remind me if necessary. Apple USB-Ethernet Win7 64-bit Drivers

The .ini files were modified as taught by: YouGottaBeKiddingYou

Wednesday, September 7, 2011

Enable VNC Server in Mac OS X

This is so easy I can't believe it's taken me this long to find it.  This works for Snow Leopard and Lion as far as I know, though I've only tested it on Lion.

Go this route:
  • System Preferences
  • Sharing
  • Choose "Screen Sharing" and check the box to turn it on
  • Click "Computer Settings..."
  • Enable the "VNC views may control screen with password:" option and give it a password.  Password length is limited to 8 characters.
Now you can connect to and control your Mac from your favorite VNC application, including free versions like Mocha VNC (Lite) for iPhone or Chicken of the VNC for Mac.  I personally use Mocha VNC and it is a very good VNC app for my casual use.  It is surprisingly fast over my home network Wireless-G iPhone 3GS to Gigabit-connected early-2007 iMac, and it works perfect with my iMac's dual monitor setup.  It's the best Spotify "remote" I've found yet.


Tuesday, September 6, 2011

Part 4: Mac OS + Eclipse + OpenOCD + STM32 (ARM Cortex M3)

Intro
I really wanted to program and debug ARM processors from my Mac. This series of entries is a work in progress as I fine tune my setup for regular use.  Be sure to read the full story:
Part 1: Getting Started, what we are going to do and what parts we are going to use.
Part 2: Laying the Foundation, getting all the parts installed.
Part 3: Connecting the Plumbing, hook up all the pieces and run it.
Part 4
: Finishing Touches, troubleshooting and final thoughts.

Finishing Touches
I know that established, commercial software can often have more start-up issues than we care to deal with, especially when dealing with external development hardware.  My experience is that open-source, home-grown, multiple-author, work-on-it-in-my-spare-time, no-warranty-expressed-or-implied solutions are even more difficult.  I hope to someday build an Eclipse plug-in automate all of the things so my company can use a low maintenance open toolchain, but it's not going to happen right now!  Instead, I will show you the troubles that I've seen and the solutions that worked for me.  Deal?  Deal.

OpenOCD External Tool Troubleshooting
Installing OpenOCD
I don't have any comments on installing OpenOCD since the MacPorts installation works so well.

External Tool Configuration Reminders
This setup is pretty easy from the Eclipse perspective since only one tab in the External Tools Configuration screen needs to be populated.  Just be sure that your Location path is absolute and correct for your machine.  Same goes for the paths used in Arguments fields.  If you aren't using an Olimex ARM-USB-TINY-H JTAG or STM32 then be warned that you may need different flags on Arguments command, and that you will need to find the necessary .cfg files for your setup.

Target Connection Errors
A common thing that I ran into initially was not having my target connected and/or powered so OpenOCD couldn't connect.  When running the OpenOCD External Tool from Eclipse I would get error messages in the Eclipse Console that looked like this:

Open On-Chip Debugger 0.4.0 (2011-07-22-14:08)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
1000 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
Command handler execution failed
Warn : jtag initialization failed; try 'jtag init' again.
Error: JTAG scan chain interrogation failed: all zeroes
Error: Check JTAG interface, timings, target power, etc.
error: -100
Command handler execution failed
With a properly connected target you should see something less scary like:
Open On-Chip Debugger 0.4.0 (2011-07-22-14:08)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
1000 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
Info : max TCK change to: 30000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1) 
You might also see this displayed when starting OpenOCD:
Error: JTAG-DP_STICKY_ERROR
This doesn't happen all the time, or very often at all, for me, but I have seen it, and it makes it impossible to start debugging when it does happen.  I found a page at TinCanTools that said it is related to an OpenOCD 0.4.0 bug and it can be fixed by simply relaunching OpenOCD (the method I stumbled on) or by changing the OpenOCD launch arguments from:
-f /opt/local/share/openocd/scripts/interface/olimex-arm-usb-tiny-h.cfg -f /opt/local/share/openocd/scripts/target/stm32.cfg -c "init" -c "reset"
to:
-f /opt/local/share/openocd/scripts/interface/olimex-arm-usb-tiny-h.cfg -f /opt/local/share/openocd/scripts/target/stm32.cfg -c "init" -c "reset init" 
I did that and it worked, but then I switched back to the original to test the theory and it still worked.  YMMV.

Debugger Troubleshooting
No source available for ""
This being displayed in the source file area of the Debug Perspective happens for any number of reasons, but its always when something prevented the program download or run from happening properly.  Go through your Console output and look for "Error:" messages.

Error: couldn't open test_rom.hex
This is thrown when the debugger can find your binary file (obviously).  One reason is because you haven't build your program yet, or you did but then you cleaned the project before running the debugger.  Another reason is that in your debugger configuration has the wrong path to your binary file in the "'Run' commands" section of the "Commands" tab.  Your run command should look like the block below, but you need to edit it to reflect the correct relative path to your binary output file.  The location is dependent on your project directory structure and the name of your output files which are dependent on what you called them and if your are compiling for Flash or RAM.  Notice that the "symbol-file" path doesn't require the same path information.  Why? I don't know right now. The two paths I'm talking about are in bold:

monitor soft_reset_halt
monitor wait_halt
monitor poll
monitor flash probe 0
monitor stm32x mass_erase 0
monitor flash write_bank 0 STM32Test2/test_rom.hex 0
monitor soft_reset_halt
symbol-file test_rom.elf
thbreak main
continue
Conclusion
This was fun and I hope you were able to use it for your own work.  Looking back it took quite a long time to figure out and a surprising amount of time to write about...there's a lot to do!  All of this stuff certainly helps you appreciate the simplicity of IAR Embedded Workbench for ARM.

In the future I want to show you how to use IAR sample projects in our new toolchain, and I want to develop a quick-install method or plug-in of some kind to automate all of this work, as well as make it easy to change JTAG and target processor types.  Should be fun!  Please feel free to put questions/corrections/etc in the comments and I'll try to reply quickly.

Thursday, September 1, 2011

Part 3: Mac OS + Eclipse + OpenOCD + STM32 (ARM Cortex M3)

Intro
I really wanted to program and debug ARM processors from my Mac. This series of entries is a work in progress as I fine tune my setup for regular use.  Be sure to read the full story:
Part 1: Getting Started, what we are going to do and what parts we are going to use.
Part 2: Laying the Foundation, getting all the parts installed.
Part 3: Connecting the Plumbing, hook up all the pieces and run it.
Part 4
: Finishing Touches, troubleshooting and final thoughts.

Connecting the Plumbing
So at this point you have all the software and tools installed and it is time to hook everything together. I considered an infographic/flowchart to describe it all, but maybe later. For now, consider this
  • Eclipse uses OpenOCD to make the bridge to the hardware
  • Eclipse then uses a makefile in your project to invoke YAGARTO to compile your source into binary and debugger files
  • Eclipse then uses YAGARTO's GDB via Zylin to send the binary file over the OpenOCD bridge to the hardware using a simple (JTAG and chip dependent) OpenOCD script that I'll share with you
  • Now that your microcontroller is programmed Eclipse uses its built in debugger features to control YAGARTO's GDB via Zylin to control and debug your device over the OpenOCD bridge
As you can see, there is a lot of interaction between the parts, but after initial setup the complexity will be reduced to a three step process: 
  1. Build Project.
  2. Start OpenOCD. Even better: you only have to do this once per session.
  3. Start Debugging. Automatically downloads the latest binaries to your target each time.
Create a Test Project
  1. YAGARTO's example page has a nice starter project. It is their STM32Test project for the STM32-P103 board, but really its so simple it will work for anything. I modified the makefile to suit my setup and preferences, and I'll show you how to do it, too. Download it and extract it, doesn't matter where you put it.
  2. Time to import the project into Eclipse. Go File->New->C Project. Name it STM32Test for consistency, Project Type is "Makefile project"->Empty Project, Toolchain setting is "-- Other Toolchain --". Hit Finish.  My project is called STM32Test2 since I'm redoing this for you.
  3. In Project Explorer, right-click on your new project name and click "Import...". Set the Import source to be "General"->File System, then hit Next.  The From Directory is where you extracted the STM32Test project to. You want to import everything except for the root folder, see the image below (click to expand). To do this, expand the root folder, choose the three sub-folders, then click on the root folder to view its files and select the makefile.  The Into Folder path is set to your new project path because that was the one you right-clicked on to start the import. Press Finish to complete the import.
  4. Now that the files are in your project expand the project folder in the Project Explorer of Eclipse so you can see the contents.  Open the makefile by double-clicking on it. 
  5. Find the makefile line near the top that begins with TRGT.  Since Eclipse doesn't like to respect PATH variables I changed this line to reflect the absolute path to the YAGARTO compiler tools: TRGT = /Developer/YAGARTO/yagarto-4.6.0/bin/arm-none-eabi-
  6. My STM32 toolchain configuration wants binary files instead of hex files, so I went down a five lines and changed the BIN entry to be: BIN  = $(CP) -O binary
  7. I also wanted to run the program from the Flash memory of my micro so I scrolled down further and changed this setting: RUN_FROM_FLASH = 1
  8. Note that later when you add more source files to you project you will need to add them to the source files list in the makefile.  Header files are found automatically as long as they are in the project folder.
  9. Ok, that's it, save the makefile, then build your project from the Project menu or just by right-clicking on your project in Project Explorer. The Console window should show all the of the compiler commands rushing by then three new files should appear in your project: test_rom.elf (debugger data file), test_rom.hex (the image for your micro, its actually binary), and test_rom.map (like any map file, showing what is will be in the various memory areas of your micro).

Configure OpenOCD as an External Tool for Eclipse
  1. Look for External Tools icon on the toolbar and hit the drop-down arrow, or go to the Run menu -> External Tools, and choose "External Tools Configuration".
  2. On the left side of theExternal Tools Configuration dialog box click on "Program", if it's not already selected, and the right-side pane will show you what you can do with this dialog box.
  3. Choose the New option and the right-side pane will show you details of your new tool configuration.
  4. First thing to note is that the Helios release of Eclipse does not remember your global or project prefs settings for environment PATH variables.  So, where ever I use file paths I put in the absolute path rather than using relative paths and relying on the environment setting. You can either use the latest version of Eclipse or modify your Mac's PATH variable if you don't like this.  I understand the lack of portability, but I blame it on Eclipse and my laziness of not upgrading.
  5. Location is the path to the executable of the tool, and that tool is OpenOCD
  6. Arguments setup OpenOCD for your particular toolchain, my case is the Olimex ARM-USB-TINY-H and the ST Micro STM32.  The OpenOCD scripts folder contains quite a few different options here, but be aware that changing these options may result in necessary changes elsewhere in our IDE setup.
  7. The "Main" tab is all you need to worry about here. Fill in your new tool configuration as shown in the image below (click to enlarge), then press Apply then Close. You can run this external tool from the toolbar by clicking on the drop-down arrow of External Tools and finding the tool name (ARM-USB-TINY-H Start), you may have to Run the tool from inside its configuration window the first time to get it to appear in the drop-down menu. So, make sure that your JTAG is plugged into USB and plugged into your target, and make sure your target is powered, then run it!
  8. The console should show lots of red text (red doesn't mean error), and it should look something like this:
    Open On-Chip Debugger 0.4.0 (2011-07-22-14:08)Licensed under GNU GPL v2For bug reports, readhttp://openocd.berlios.de/doc/doxygen/bugs.html1000 kHzjtag_nsrst_delay: 100jtag_ntrst_delay: 100Info : max TCK change to: 30000 kHzInfo : clock speed 1000 kHzInfo : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpointsInfo : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)

Set the Debugger Configuration for Eclipse
  1. Find the Debugger icon on the toolbar and hit the drop-down arrow, or go to the Run menu, and choose "Debug Configurations".
  2. Since you've already installed the Zylin CDT Plugin you will have "Zylin Embedded Debug (Native)" in the list on the left side.  Select this and press the "New launch configuration" button at the top of the list.
  3. For this setup there are three tabs that we are interested in: Main, Debugger, and Commands.
  4. Main Tab: Thus far in my usage I've needed a separate debugger config for each project because there are pathnames hard coded into the debugger commands, I'm sure this can be improved on, but not yet. So, at the very top of the dialog box we are going to call this setup "STM32TestROM".  Then put in the optional project name, either browse for your new project or type in the name STM32Test (STM32Test2 in my case). The C/C++ Application is the .elf file created by the project build, which you can search or browse for, or just type in "test_rom.elf".  Note that since we pointed it at the "_rom" file this config is specific for running our program in Flash and not RAM, since our makefile uses "_ram" output filenames for non-Flash compiled programs.  Feel free to customize.
  5. Debugger Tab: Debugger is "Embedded GDB", Selected "Stop on startup at: " and put "main" in the text box. GDB debugger absolute path (for me) is: "/Developer/YAGARTO/yagarto-4.6.0/bin/arm-none-eabi-gdb". Clear out the GDB command file field.  GDB command set: standard. Protocol: mi.
  6. Commands Tab, 'Initialize' commands: 

  7. target remote localhost:3333
    monitor soft_reset_halt



  8. Commands Tab, 'Run' commands:


  9. monitor soft_reset_halt
    monitor wait_halt
    monitor poll
    monitor flash probe 0
    monitor stm32x mass_erase 0
    monitor flash write_bank 0 STM32Test2/test_rom.hex 0
    monitor soft_reset_halt
    symbol-file test_rom.elf
    thbreak main
    continue



  10. That's it.  Apply. Close.
  11. The OpenOCD JTAG interface is already running from before, so now we just need to run the debugger.  The Debug toolbar icon offers the drop-down arrow where you can find your debug configuration name.  Again, the first time you run it you may have to go click "Debug" from inside the debug configuration setup window to get it to appear on the toolbar menu. When you do this Eclipse will automatically switch the IDE to the Debug Perspective so you can see your typical debugger view and tools like Disassembly and Step controls. Eclipse has a powerful debugger that even allows you to hover the mouse over variables in your source code and read the realtime values when the program is halted.
Next Step
Ok, that was a long post, I went further than I expected, but ideally you are up and running now.  I'm going to leave it here for today, but next time I'll get into some troubleshooting and configuration tweaking items. Part 4: Finishing Touches.