prototype of linux OSC over USB working

With much help to Liam, I was able to get a prototype of OSC over USB working in mchelper-v25. I'll would like to have a couple of volunteers to install v25 and test it on linux. Hurray! I am *so* glad we got this working!!! EBo --

Where can I download it from?

Previously Ryan Chard wrote:

Where can I download it from?

In his other announcement thread, he said: "So, just ping me over on IRC #makingthings and I'll email you the diffs to mchelper-v25."  His handle there is "ebo".

Ryan, Sorry for the delay; I was hammering away on some research and had missed your post. I have been working with Liam, and the majority of my changes have been merged into branch/v25. We still have a couple of things to polish up, but it now works! Hurray!!! So, checkout the latest code from SVN and build mchelper/branches/v25. As noted there may be a rough spot or two left, but it is close enough to fix the obvious... EBo --

Anything special need to get the OSC over USB working with v25 in Linux ? I downloaded the latest via svn, installed the latest Qt and managed to get it all compiled OK, but it still doesn't see the board when only on USB (as soon as ethernet attached it picks it up). I reverted to the distributed build of the 1.5.1 firmware, still no go.

I'm using sam7 via libusb and sudo (Ubuntu 8.04) so I tried sudo for mchelper, no change.

Hi Niall, Try updating your SVN tree since a couple of things have updated since then. Also, you will need the latest sam7utils (from cvs) to work with the latest mchelper. You might have to tweak your udev settings to make them writable by everyone. Also note that the latest version of sam7utils no longer requires you to load the at91 module. In fact if it is built into the kernel that module will grab access and nothing will work. Hope that helps. EBo --

The svn update fixed things. I am using sam7 0.2.1 which I believe is the latest (at least it is the latest tag on oss.tekno.us). My controller now shows up on both network and USB and I can even upload firmware via mchelper (though I still have to use sam7 to set boot_from_flash ?)

mchelper uses /dev/ttyACM0 which gets the correct permissions so I don't have to be root to run it, but sam7 still requires sudo ... could this be the issue with boot_from_flash ? I guess I need to figure out how to have sam7 with libusb work as normal user ...

Thanks for the help !

... Niall

Turns out I didn't have the latest version of sam7 (trunk had many changes from tag 0.2.1) but even with an update I still need to set boot_from_flash separately. Understanding this is very much a work in progress, is this the expected behaviour ?

Previously Niall Parker wrote:

mchelper uses /dev/ttyACM0 which gets the correct permissions so I don't have to be root to run it, but sam7 still requires sudo ... could this be the issue with boot_from_flash ? I guess I need to figure out how to have sam7 with libusb work as normal user ...

Yes, that would cause exactly that situation.  Internally, mchelper is running sam7, just like you do, only it isn't running it through sudo.

You have to get the permissions right, and that's an OS thing, and is common to any use of sam7 (or any other libusb-using program).  If your system uses udev, you need to add a rule to set the permissions when the device is plugged in.

What confuses me is that you were able to flash (via mchelper).  Sam7 is used for that, too, and I'd think that would fail.  It's the same invocation that sets boot_from_flash, actually.  Are you sure it didn't just fail silently, making you think it flashed even though it didn't?

Previously Lou Deluxe wrote:

What confuses me is that you were able to flash (via mchelper).  Sam7 is used for that, too, and I'd think that would fail.  It's the same invocation that sets boot_from_flash, actually.  Are you sure it didn't just fail silently, making you think it flashed even though it didn't?

You're right, the flash upload wasn't actually working, and when I set boot_from_flash the processor just went back to the original code that was loaded previously. I finally sorted out the permissions and mchelper can successfully upload and set boot_from_flash. I'm also getting the progress bar and other status info on the console, all of which was missing before.

Thanks!

Would somebody mind giving an overview or some instructions with regards to the permissions needed on Linux/*BSD? Something I could include in the ReadMe or something like that would be ideal...thanks!

Previously Liam Staskawicz wrote:

Would somebody mind giving an overview or some instructions with regards to the permissions needed on Linux/*BSD? Something I could include in the ReadMe or something like that would be ideal...thanks!

Unfortunately, complexity is added in that different OSes (or even different versions of the same one) do it differently, and that people's security models also differ.  You'd probably have to point to a crash course in *nix permissions for it to make any sense to certain audiences.

I did find this.  http://www.gphoto.org/doc/manual/permissions-usb.html

I haven't tried the HAL method.
I use udev on my system.  Two rules are needed because udev works differently with different kernel versions that I've used recently.  One of the rules works under one and the other under another.

Here are my rules:
SUBSYSTEM=="usb_device", ACTION=="add", SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="6124", OWNER="me", GROUP="me", MODE="0660"
ACTION=="add", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="6124", OWNER="me", GROUP="me", MODE="0660"

As you can see, they are pretty me-centric.  Another user may wish to set only the group, and set that to one that folks who should be able to use sam7 are members of.

More or different rules (with corresponding idVendor and idProduct)  may be needed to get the flashed MC (as opposed to SAM-BA) to show up in mchelper properly.

Hi gang, I have just noticed a very strange problem compiling against v25 ESVN_VERSION=896. When I pop mchelper I cannot view the inspector *unless* I double click the device. Then the name of the device shows up and everything is OK. Unfortunately, Eth now never shows up on the device list... I am not sure what is going on with this, but things were working before. I'll try both building off one of the old versions and the most current SVN version. EBo --

Ok... issue 1) Things work as expected *IF* mchelper is running *before* plugging in the controller. If you plug in the controller first, mchelper gets confused and does not appear to init the board properly. issue 2) I hosed my system a few days ago when doing some low-level upgrades (that does not happen often, but does from time to time). I decided to rebuild the entire system to make sure everything was OK. Now I cannot get mchelper to talk over the ethernet at all. I keep getting the dreaded "Error - can't listen on port 11000. Make sure it's available. from XML Server" "Error: Can't listen on port 10000 - make sure it's not already in use. from Ethernet" errors. Since I rebuilt the system, and may have overwritten some of the system configuration in the process, I thought I would go back to the Getting Started instructions to see if I missed anything in the setup. With the latest web site changes, the old getting started instructions no longer contain the Linux specific instructions. The more I try to write software for the MakeMicrocontroller the more I feel like there is no interest in linux support. You know I am really starting to get pissed off. EBo --

Ok... I stumbled onto what appears to be one of the problems. When I was testing several different version of mchelper one of the inspector windows was left orphaned from the main window. Since that was floating around (underneath one of my command/terminal windows) it was interfering with subsequent runs. Liam, when exiting the main window, it should kill all children... EBo --

Oh frazelsnarf!

your guys new interface STRIPS out all the witespace and reformats the text. \\This is a test to see if putting in HTML tags give me appropriate line and paragraph breaks.
this is only a test...

EBo --

html br and p commands work, but the newline does not appear to work.

this is so annoying!

ebo --

Previously John (EBo) David wrote:

I keep getting the dreaded "Error - can't listen on port 11000. Make sure it's available. from XML Server" "Error: Can't listen on port 10000 - make sure it's not already in use.

The lsof program (maybe also fuser, I haven't used it much) can be very helpful in finding which program (and PID) has a port open.

 

Yeah - it sounds like that all mostly from a previous window being open.  I've just committed a fix for this.

There are no guarantees running against the trunk when development is being done  

Yep, I found that I had an orphaned window which was competing for control, etc.

Actually, while I am running/compiling against the trunk, my build scripts build off specific revisions of the SVN tree, so things are not breaking because something was updated in the tree.

Also, the other problem is updating the devices udev so I do not have to run the program as root. I have a bug posted to the udev development team about this. What started this all off was needing to rebuild my of because of a potential config file corruption and not being able to overwrite some of the low level udev definitions. So, whenever I rebuild udev I loose the hacks I have to make to fix talk to the device as a regular user. Sorting that back out I ended up killing mchelper when the inspector was open. Unless you have fixed this recently, none of the popups are killed if the main program is killed. This I consider a bug.

EBo --

As I mentioned in the above post, I just committed a fix for it.  Hopefully that should help out.