Jump to content

bi0tech

Members
  • Content Count

    10
  • Joined

  • Last visited

  • Days Won

    2

bi0tech last won the day on May 14 2014

bi0tech had the most liked content!

About bi0tech

  • Rank
    Member

Profile Information

  • Gender
    Not Telling
  1. bi0tech

    DAC GUI V2

    Right, but I know about a half dozen commonly used methods to scan and enumerate coms in the windows world. And I know where most of those end up pulling the information from the registry. So I can then populate the wine bottle registry to expose hardware devices linked from linux land. None of those appear to work with this app. If I know for certain what call is made I can likely trace it down.
  2. bi0tech

    DAC GUI V2

    What call did you use for pulling a com port list in the gui? I was attempting to get it working under wine, trying several of the usual tricks to get com device detection and it's a no go. Sidenote: I thought it would be a good way to learn some python so I'm writing a version of the gui primarily for *nix based systems. I have about 1/3 - 1/2 of the current features of the windows gui in place along with some basic realtime data plotting/graphing in so far. It would go a good bit faster if I could get it running under wine or get an outline of the full command syntax / return value formats. (If I ever get to feature parity Ill throw the code up somewhere.)
  3. bi0tech

    CCS V6 does not install on Arch Linux

    From what I've seen CCS doesn't not play particularly well with Arch (v5 as well as v6). I can only suggest satisfying all the 32bit lib requirements and give it a go. Although depending on how much time you have to spend on it, a XP vm may be faster. zip has been around since the days of pkware for DOS. (early 90's) http://en.wikipedia.org/wiki/Info-ZIP
  4. bi0tech

    advice on mounting a launchpad?

    This seems relevant so Ill throw in a few pics of my msp430 franken'pad. I wanted a zif and drop in breadboard capability, so I picked up a few knockoff texttool 28 pin zifs (largest size I saw in narrow format, the extra pins don't pose an issue and allow use with a few other chips). Desoldering the carrier socket was moderately painful, but doable with just some braid/fine tip. (full disclosure I'm not the worlds worst at soldering, now 2nd worst is still to be determined). Added in stacker headers in place of the carrier to give me drop in breadboarding and to clear the board surface level / leave room for the crystal. A little hot glue to keep things in place (and hold a flywire from where I lifted a pad) and a 5 minute router job with some scrap wood as a puck stand.
  5. One last note I'll throw in this thread since it already has other info. CCSv6 does actually work with the MSP430 under Linux, I'm not sure I'd go as far as saying 'supported' though. For debugging you have to configure it for external program use of mspdebug as a relay for msp430-gdb, but it functions in terms of compilation (briefly tested TI compiler with 430ware libs and Energia project imports using GCC), flashing, and debugging with those external tools.
  6. I figured I'd have to deal with this sooner or later myself so I hooked up my launchpad and tested a kernel module patch I'd seen around a few places. In very brief testing it does seem that it eliminates the extended hang when serial data is passed to ttyACM* before there is a reciever on the host. The patch to cdc-acm I used was for arch and has been since abandoned but it's easy enough to use/modify: Grab the tarball here: https://aur.archlinux.org/packages.php?ID=63769 The only file you need from it is the cdc-acm.patch, extract it somewhere like /usr/src/cdcacm-msp430 Grab the source for your kernel version. (either from vendor site or kernel.org) Pull the cdc-acm.c & cdc-acm.h files from the kernel source into /usr/src/cdcacm-msp430 sudo apt-get install kernel-headers build-essential (or similar for non-deb distros) cd /usr/src/cdcacm-msp430/ Rename the cdc-acm.c to cdc-acm.c.orig Either use the patch file (/usr/src/cdcacm-msp430/patch < cdc-acm.patch) or manually edit the changes from the .patch into cdc-acm.c.orig Save the result file as cdcacm.c Save the below text into /usr/src/cdcacm-msp430/Makefile make sudo cp /usr/src/cdcacm-msp430/cdcacm.ko /lib/modules/`uname -r`/kernel/drivers/usb/class/ echo "blacklist cdc-acm" > blacklist-MSP430.conf sudo cp blacklist-MSP430.conf /etc/modprobe.d/ sudo depmod -a reboot (or manually unload the old "cdc-acm" and insmod the new "cdcacm") generic kernel module Makefile: obj-m := cdcacm.o KVERSION := $(shell uname -r) all: $(MAKE) --debug=v -C /lib/modules/$(KVERSION)/build M=$(PWD) modules clean: $(MAKE) --debug=v -C /lib/modules/$(KVERSION)/build M=$(PWD) clean You can also go the dkms route but I had issues with it (and I'm not overly fond of it). Using dkms you won't need to rebuild when switching kernels (in theory). To revert back to cdc-acm: sudo rm /etc/modprobe.d/blacklist-MSP430.conf sudo rm /lib/modules/`uname -r`/kernel/drivers/usb/class/cdcacm.ko sudo depmod -a reboot
  7. The only other thing I could think of for no output would be the chip configuration. You didn't mention which msp430 this is using. Make sure you have the correct chip variant selected and the jumpers oriented acc'd to the info below. Check here: http://energia.nu/Guide_MSP430LaunchPad.html A bit more info: http://energia.nu/Serial.html
  8. I believe your problem is there. If the serial device is owned by dialout you need to be a member. sudo usermod -a -G dialout username Although I believe the udev rule should move the usb device as well as the tty to plugdev ownership. Did you disconnect/reconnect the device since you restarted udev? Permissions for usermode aside, serial communication on the 430 and serial comm in linux is a bit touchy (read as buggy). I haven't spent a lot of time with it yet but I find toggling the line speed of the ttyACM* device on the host side kickstarts throughput. (After starting the serial monitor toggle it to 4800 for a second and then back to 9600, or leave one terminal open to 'cat < /dev/ttyACM0' and use 'stty -F /dev/ttyACM0 raw <speed>' in a second terminal.)
  9. I was looking at CCSv6 with a Tiva launchpad the last few days, and it's a nice transition point between arduino/energia and self setup Eclipse toolchains. There's always a few quirks with Eclipse plugins like settings you don't remember where one control nested 5 menus deep was, but those seem to be few in nature. The Linux install was a tad lengthy, and there's always issues with libs on self contained installers but most of those were easy enough to get by. Prereq libs are listed here: http://processors.wiki.ti.com/index.php/Linux_Host_Support and a supposed lib checker is available here: http://processors.wiki.ti.com/index.php/Checking_Linux_Dependencies_for_CCS. (For the moment at least the lib checker is not particularly robust and there seems to be a bug in it looking for a library version that doesn't exist.... so not confidence inspiring there.)
  10. bi0tech

    Energia + Linux ?

    For Mint/*buntu at least you can also skip the udev rules by simply adding the user to the ownership group of the device file, in this case 'dialout'. Show device permissions: (for the default ACM0): ls -al /dev/ttyA* crw-rw-r-- 1 root dialout 166, 0 May 1 10:19 /dev/ttyACM0 Show current group members: cat /etc/group | grep <groupname> cat /etc/group | grep dialout dialout:x:20:<username> Add existing user to the group (as secondary group membership): sudo usermod -a -G <group> <user> sudo usermod -a -G dialout username *After changes to user permissions you will need to logout and back in to establish a session with the new permissions. (or just reboot)
×