Hi everyone, On my current robotics project, I'm using a gumstix verdex to talk over a USB to serial converter chip (FT232) to a serial bus. My brother Dave made up a new kernel driver for the gumstix, and when I plug in the chip it registers itself as ttyUSB0. For work I've done previously on Squeak on the gumstix, I've used standard serial ports, which map to ttyS0, ttyS1, ttyS2, etc, which correspond to port 0, 1, and 2 when I open the Serial Port in Squeak. However, I have no idea which port number ttyUSB0 corresponds to... Anyone got any idea? Thanks, Jon -------------------------------------------------------------- Jon Hylands [hidden email] http://www.huv.com/jon Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog |
Can you try "cat /proc/devices" with/without the device inserted?
Maybe this will indicate the port being added? I'm not on Linux at the moment but it's worth a try. |
Sry, ignore my response. Had not read you post correctly.
|
OTOH, shouldn't it simply be a numbered port? Have you tried 3 or 4?
|
On Sun, 20 May 2007 07:45:11 +0100, "Derek O'Connell" <[hidden email]>
wrote: > OTOH, shouldn't it simply be a numbered port? Have you tried 3 or 4? I'm going to try all the ports between 0 and 9 to see what happens, but first I need to actually get Squeak running on the board -- which isn't working right now - this is a new PXA270-based gumstix verdex and apparently its different enough so I can't run the same VM I run on my old PXA255 gumstix. Later, Jon -------------------------------------------------------------- Jon Hylands [hidden email] http://www.huv.com/jon Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog |
In reply to this post by Jon Hylands
On Sunday 20 May 2007 5:33 am, Jon Hylands wrote:
> Hi everyone, > For work I've done previously on Squeak on the gumstix, I've used standard > serial ports, which map to ttyS0, ttyS1, ttyS2, etc, which correspond to > port 0, 1, and 2 when I open the Serial Port in Squeak. However, I have no > idea which port number ttyUSB0 corresponds to... SerialPort passes a portnumber which gets mapped to /dev/ttyS<n> filename. So the /dev/ttyUSB<n> cannot be accessed through port numbers :-(. ttyS0 and ttyUSB0 are handled by different drivers and I am not sure if they are equivalent at file i/o level. You could try a trick on the gumstix: rm /dev/ttyS4 && ln -s /dev/ttyUSB0 /dev/ttyS4 and then try to access it as port 4. If /dev/ttyS? is populated automatically on startup, then you will have to put this command immediately after the startup code. Hope it works .. Subbu |
In reply to this post by Jon Hylands
On 5/20/07, Jon Hylands <[hidden email]> wrote:
I have to scratch this itch :-). This is something I should know but don't. At a guess, I'd say this is your answer, from usb-serial.c in the Linux kernel: static struct usb_serial *get_free_serial (struct usb_serial *serial, int num_ports, unsigned int *minor) { unsigned int i, j; int good_spot; dbg("%s %d", __FUNCTION__, num_ports); *minor = 0; for (i = 0; i < SERIAL_TTY_MINORS; ++i) { if (serial_table[i]) continue; good_spot = 1; for (j = 1; j <= num_ports-1; ++j) if ((i+j >= SERIAL_TTY_MINORS) || (serial_table[i+j])) { good_spot = 0; i += j; break; } if (good_spot == 0) continue; *minor = i; dbg("%s - minor base = %d", __FUNCTION__, *minor); for (i = *minor; (i < (*minor + num_ports)) && (i < SERIAL_TTY_MINORS); ++i) serial_table[i] = serial; return serial; } return NULL; } I'm assuming that serial_table[] is a list of the ttyUSBn ports, and this just finds a free one starting from ttyUSB0, but somebody smarter than me is going to have to verify this. Also mentioned somewhere is that the device allocation will appear in the system logs. That's a pretty disgusting way to find the device mappings. Another way would be to iterate through the /dev/ttyUSB*'s to find your device which I find equally disgusting. It's probably easiest to simply assume that it is always /dev/ttyUSB0 or /dev/usb/tts/0 if you're using devfs. Did Dave write the code, or did he simply compile it? It sounds like he'd be the person to ask, and I'm surprised he didn't make a /dev/microraptor for you :-). Michael. p.s. I've seen a video of your raptor - it rocks! |
In reply to this post by K. K. Subramaniam
On Sun, 20 May 2007 20:02:41 +0530, subbukk <[hidden email]> wrote:
> You could try a trick on the gumstix: > rm /dev/ttyS4 && ln -s /dev/ttyUSB0 /dev/ttyS4 My brother suggested the same thing (he built me a new verdex VM as well) So, I did this: ln -s /dev/ttyUSB0 /dev/ttyS4 and it worked perfectly! Thanks everyone for your suggestions... Later, Jon -------------------------------------------------------------- Jon Hylands [hidden email] http://www.huv.com/jon Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog |
In reply to this post by Michael van der Gulik-2
Michael van der Gulik wrote:
> > > On 5/20/07, *Jon Hylands* <[hidden email] <mailto:[hidden email]>> wrote: > > > Hi everyone, > > On my current robotics project, I'm using a gumstix verdex to talk > over a > USB to serial converter chip (FT232) to a serial bus. > > My brother Dave made up a new kernel driver for the gumstix, and when I > plug in the chip it registers itself as ttyUSB0. > > For work I've done previously on Squeak on the gumstix, I've used > standard > serial ports, which map to ttyS0, ttyS1, ttyS2, etc, which correspond to > port 0, 1, and 2 when I open the Serial Port in Squeak. However, I > have no > idea which port number ttyUSB0 corresponds to... > > Anyone got any idea? > > > I have to scratch this itch :-). This is something I should know but don't. > > At a guess, I'd say this is your answer, from usb-serial.c in the Linux > kernel: ..actually sorry; I misread your email. Michael. |
In reply to this post by Jon Hylands
Hello everyone,
I re-open an old topic concerning how some USB->COM converters are mounted by Linux (and MacOS), and why it's a problem for the project I'm working in (SqueakBot, with Serge Stinckwich). We are using a lot of USB->COM converters (actually, microcontrollers, with USB interfaces, we pilot within Squeak through the serial port) and, as noted by Jon Hylands, they are mounted under Linux as ttyUSBx (and more surprinsingly, ttyUSBModemX under MacOS), and thus not reachable from Squeak (since the Serial communication primitives just append the serial port number to "ttyS" to locate the device). The proposed solution with a virtual link is a valid workaround, but not very usable in our case (the electronic boards are meant to be use by non specialist public, including children, and I can not expect them to type any kind of "ln -s" magic). A better workaround, for us, would to define a new Squeak primitive in SerialPlugin to open the serial port which takes the full device string ("dev/ttyUSBx") as argument (in this case, the cross-plateform compatibility will have to be ensured in the Squeak code). Do you think it would be feasible? or do you have any other idea? Thank you! Severin |
On Tue, 17 Jun 2008 18:11:53 -0700 (PDT), Skadge <[hidden email]> wrote:
> The proposed solution with a virtual link is a valid workaround, but not > very usable in our case (the electronic boards are meant to be use by non > specialist public, including children, and I can not expect them to type any > kind of "ln -s" magic). While I agree the new plugin would be nice to have (and I would certainly use it), couldn't you just run the command from Squeak using OSProcess as part of the initialization? Later, Jon -------------------------------------------------------------- Jon Hylands [hidden email] http://www.huv.com/jon Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog |
> While I agree the new plugin would be nice to have (and I would certainly
> use it), couldn't you just run the command from Squeak using OSProcess as > part of the initialization? > Not really because we can have several USB boards connected at the same time, without knowing, a priori, their number (ttyUSBx). We have an automatic detection mechanism : we write on the first 10 COM ports a string and read an answer when one of our board is present. Works fine under Windows, but under Linux or MacOS... I could link *all* the ttyUSB to the corresponding ttyS, but... well... it's a bit dirty :-) and could bring some conflicts if traditional serial devices are plugged and already use the ttySx. Severin |
In reply to this post by Séverin Lemaignan
On Tue, Jun 17, 2008 at 06:11:53PM -0700, Skadge wrote:
> > A better workaround, for us, would to define a new Squeak primitive in > SerialPlugin to open the serial port which takes the full device string > ("dev/ttyUSBx") as argument (in this case, the cross-plateform compatibility > will have to be ensured in the Squeak code). > Do you think it would be feasible? or do you have any other idea? Severin, Certainly it is feasible. However, it would be difficult to actually get the changes implemented and released in the "official" VM, simply because of the time it would take to coordinate. So if you can build and release the plugin yourself, then it can be done. > or do you have any other idea? If you are concerned with Unix/Linux platforms, you can probably just do a change to these two lines in the sqUnixSerial.c support code: #define PORT_NAME_SIZE 11 static const char serialPortBaseName[] = "/dev/ttyS0"; If you change the serialPortBaseName to the right value for your USB device names, and modify PORT_NAME_SIZE to match, then the plugin will probably do what you want without further modification. No, I have not tested this, and yes it's a hack ;) A slightly more difficult change would be to add an optional primitive for Unix/Linux that sets the serialPortBaseName string. That would let you control it from Squeak, and would not require any changes to the existing primitives. If you did the changes to implement this for Unix, you would have a reasonable chance of getting them included in future VM releases, because the changes would be backward-compatible and would require testing only for Unix based platforms. Note, I have no experience programming USB ports, so I'm assuming from your original question that the SerialPlugin actually works when connected to a USB device rather than to a traditional serial port. Dave |
Thanks, Dave, for the answer.
> A slightly more difficult change would be to add an optional primitive for > Unix/Linux that sets the serialPortBaseName string. That would let you control > it from Squeak, and would not require any changes to the existing primitives. That's actually probably what I'll try to do. Stupid question, but where can I fetch the sqUnixSerial.c file (and it's MacOS counterpart)? Severin |
On Wed, Jun 18, 2008 at 04:10:39AM +0100, S??verin Lemaignan wrote:
> Thanks, Dave, for the answer. > > > A slightly more difficult change would be to add an optional primitive for > > Unix/Linux that sets the serialPortBaseName string. That would let you control > > it from Squeak, and would not require any changes to the existing primitives. > > That's actually probably what I'll try to do. Stupid question, but > where can I fetch the sqUnixSerial.c file (and it's MacOS > counterpart)? Severin, The sqUnixSerial.c file is part of the external support code (as opposed to the parts that are distributed in the VMMaker package). The external support code is maintained in a Subversion repository at http://squeakvm.org and you will also find it at the various VM home pages. If you are working with Linux for example, just grab one of Ian's distributions on http://squeakvm.org/unix/. The sqUnixSerial.c file is in platforms/unix/plugins/SerialPlugin. The corresponding support code for other platforms is in e.g. platforms/Mac OS/plugins/serialPlugin. I don't know enough about Mac OS to give any guidance there, but the support code for SerialPlugin looks like it might be for some older version of Mac OS. I understand that on OS X you can actually use a plugin from the unix sources, but I'm afraid I don't know the details. Dave |
Hello everyone,
A couple of months later, I'm eventually working on getting the SerialPort plugin to work for arbitrary nodes name under Linux (and thus MacOS). A quick summary of the issue, to refresh memories: today, you can open a serial port in Squeak with "SerialPort new openPort:portNum.". Eg, for portNum = 1, it would map to COM1 under Windows and /dev/ttyS1 under Linux. That's fine, except that recent Linux kernels don't mount most serial devices on /dev/ttySxx, but on more specific nodes, like /dev/ttyACMxx for modems, /dev/ttyUSBxx for certain USB->COM converters, etc. To circumvent it, I modified the Serial Port plugin to accept either port numbers or arbitrary paths. I still have some cleaning to do, but the plugin itself (sqUnixSerial.c) basically works. But I have some troubles to get it to work from Squeak. I modified SqueakPlugin.c to introduce new primitive calls (plus their corresponding "exports" declaration), namely: EXPORT(sqInt) primitiveSerialPortCloseByName(void); EXPORT(sqInt) primitiveSerialPortOpenByName(void); EXPORT(sqInt) primitiveSerialPortReadByName(void); EXPORT(sqInt) primitiveSerialPortWriteByName(void); For each of them, I need to get the port name. I did like that (copy-pasted from another plugin): int spName; char * spNameIndex; spName = interpreterProxy->stackValue(0); interpreterProxy->success(interpreterProxy->isBytes(spName)); spNameIndex = interpreterProxy->firstIndexableField(spName); But I probably do something wrong since if I call the primitive "primSerialPortOpenByName" with "/dev/ttyACM0" as port name from Squeak, the plugin code in sqUnixSerial.c receives a different string ("/dev/ttyACM0_��@�w@�w"), thus failing to open the serial port. Does someone knows how to correctly transmit a string argument to a plugin? I attach to the mail my working versions of sqUnixSerial.c, SerialPlugin.c, SerialPlugin.h. If needed, I can send as well some test code for sqUnixSerial.c. And by the way, happy new year to everybody! Séverin 2008/6/18 David T. Lewis <[hidden email]>: > On Wed, Jun 18, 2008 at 04:10:39AM +0100, S??verin Lemaignan wrote: >> Thanks, Dave, for the answer. >> >> > A slightly more difficult change would be to add an optional primitive for >> > Unix/Linux that sets the serialPortBaseName string. That would let you control >> > it from Squeak, and would not require any changes to the existing primitives. >> >> That's actually probably what I'll try to do. Stupid question, but >> where can I fetch the sqUnixSerial.c file (and it's MacOS >> counterpart)? > > Severin, > > The sqUnixSerial.c file is part of the external support code (as opposed > to the parts that are distributed in the VMMaker package). The external > support code is maintained in a Subversion repository at http://squeakvm.org > and you will also find it at the various VM home pages. If you are working > with Linux for example, just grab one of Ian's distributions on > http://squeakvm.org/unix/. > > The sqUnixSerial.c file is in platforms/unix/plugins/SerialPlugin. > The corresponding support code for other platforms is in e.g. > platforms/Mac OS/plugins/serialPlugin. > > I don't know enough about Mac OS to give any guidance there, but the > support code for SerialPlugin looks like it might be for some older > version of Mac OS. I understand that on OS X you can actually use > a plugin from the unix sources, but I'm afraid I don't know the details. > > Dave > > > sqUnixSerial.c (17K) Download Attachment SerialPlugin.c (15K) Download Attachment SerialPlugin.h (1K) Download Attachment |
On Sun, Jan 04, 2009 at 11:54:22PM +0100, S??verin Lemaignan wrote:
> > For each of them, I need to get the port name. I did like that > (copy-pasted from another plugin): > > int spName; > char * spNameIndex; > > > spName = interpreterProxy->stackValue(0); > interpreterProxy->success(interpreterProxy->isBytes(spName)); > spNameIndex = interpreterProxy->firstIndexableField(spName); > > But I probably do something wrong since if I call the primitive > "primSerialPortOpenByName" with "/dev/ttyACM0" as port name from > Squeak, the plugin code in sqUnixSerial.c receives a different string > ("/dev/ttyACM0_??????@???w@???w"), thus failing to open the serial port. > > Does someone knows how to correctly transmit a string argument to a plugin? > S??verin, The trick here is that C expects strings to be null-terminated, and the Squeak string that you pass to the primitive does not have the trailing null. In general, you will want to copy the Squeak string contents into a freshly allocated char[] array of size one greater than the string length. There are a number of ways you can do this, but to give some examples you can look in OSProcessPlugin (available on SqueakSource in project OSProcessPlugin). The methods #transientCStringFromString: and #cStringFromString: provide two ways to do the conversion. As an example, here is a primitive from UnixOSProcessPlugin after it has been converted from Slang to C: /* Call chdir(2) to change current working directory to the specified path string. Answer nil for success, or errno on failure. */ EXPORT(sqInt) primitiveChdir(void) { extern int errno; char * path; sqInt aString; sqInt len; char *cString; char *stringPtr; sqInt newString; /* begin transientCStringFromString: */ aString = interpreterProxy->stackObjectValue(0); len = interpreterProxy->sizeOfSTArrayFromCPrimitive(interpreterProxy->arrayValueOf(aString)); interpreterProxy->pushRemappableOop(aString); newString = interpreterProxy->instantiateClassindexableSize(interpreterProxy->classString(), len + 1); stringPtr = interpreterProxy->arrayValueOf(interpreterProxy->popRemappableOop()); cString = interpreterProxy->arrayValueOf(newString); (char *)strncpy(cString, stringPtr, len); cString[len] = 0; path = cString; if (chdir(path)) { interpreterProxy->pop(2); interpreterProxy->push(interpreterProxy->nilObject()); } else { interpreterProxy->pop(2); interpreterProxy->pushInteger(errno); } } > And by the way, happy new year to everybody! And to you as well! - Dave |
Thanks Dave, it works. ...its...hum... not straighforward! :)
I'll finnish to debug and clean the code tomorrow, and I hope to be able to quickly release a patch. What's the procedure to get the patch reviewed and possibly included in the trunk (including the OLPC Etoys branch)? Bye, Séverin On Mon, Jan 5, 2009 at 00:46, David T. Lewis <[hidden email]> wrote: > On Sun, Jan 04, 2009 at 11:54:22PM +0100, S??verin Lemaignan wrote: >> >> For each of them, I need to get the port name. I did like that >> (copy-pasted from another plugin): >> >> int spName; >> char * spNameIndex; >> >> >> spName = interpreterProxy->stackValue(0); >> interpreterProxy->success(interpreterProxy->isBytes(spName)); >> spNameIndex = interpreterProxy->firstIndexableField(spName); >> >> But I probably do something wrong since if I call the primitive >> "primSerialPortOpenByName" with "/dev/ttyACM0" as port name from >> Squeak, the plugin code in sqUnixSerial.c receives a different string >> ("/dev/ttyACM0_?????? @???w @???w "), thus failing to open the serial port. >> >> Does someone knows how to correctly transmit a string argument to a plugin? >> > > S??verin, > > The trick here is that C expects strings to be null-terminated, and the Squeak > string that you pass to the primitive does not have the trailing null. > > In general, you will want to copy the Squeak string contents into a freshly > allocated char[] array of size one greater than the string length. There > are a number of ways you can do this, but to give some examples you can > look in OSProcessPlugin (available on SqueakSource in project OSProcessPlugin). > The methods #transientCStringFromString: and #cStringFromString: provide > two ways to do the conversion. As an example, here is a primitive from > UnixOSProcessPlugin after it has been converted from Slang to C: > > /* Call chdir(2) to change current working directory to the specified path string. Answer > nil for success, or errno on failure. */ > > EXPORT(sqInt) primitiveChdir(void) { > extern int errno; > char * path; > sqInt aString; > sqInt len; > char *cString; > char *stringPtr; > sqInt newString; > > /* begin transientCStringFromString: */ > aString = interpreterProxy->stackObjectValue(0); > len = interpreterProxy->sizeOfSTArrayFromCPrimitive(interpreterProxy->arrayValueOf(aString)); > interpreterProxy->pushRemappableOop(aString); > newString = interpreterProxy->instantiateClassindexableSize(interpreterProxy->classString(), len + 1); > stringPtr = interpreterProxy->arrayValueOf(interpreterProxy->popRemappableOop()); > cString = interpreterProxy->arrayValueOf(newString); > (char *)strncpy(cString, stringPtr, len); > cString[len] = 0; > path = cString; > if (chdir(path)) { > interpreterProxy->pop(2); > interpreterProxy->push(interpreterProxy->nilObject()); > } else { > interpreterProxy->pop(2); > interpreterProxy->pushInteger(errno); > } > } > > >> And by the way, happy new year to everybody! > > And to you as well! > > - Dave > > > |
On Mon, Jan 05, 2009 at 01:23:07AM +0100, S??verin Lemaignan wrote:
> Thanks Dave, it works. ...its...hum... not straighforward! :) > > I'll finnish to debug and clean the code tomorrow, and I hope to be > able to quickly release a patch. > > What's the procedure to get the patch reviewed and possibly included > in the trunk (including the OLPC Etoys branch)? S??verin, Good question. I'm not sure if there is an "official" process for this, but what I would suggest is to open a bug report on Mantis (bugs.squeak.org) and upload your patches there. Then mention the bug report here on the list, and also on the vm-dev list (http://lists.squeakfoundation.org/pipermail/vm-dev). The primary VM developers watch the vm-dev list (somewhat intermittently) so that will be the best place to figure out how to get your fixes into the Subversion repository. Dave |
Ok, I've submitted a bug (http://bugs.squeak.org/view.php?id=7266)
concerning the serial port issue. I attached along my patch. I don't know how to extract a patch from the Squeak image to distribute the required modifications to the SerialPort class, but if someone explains, I'll happily add it to the bug report. Bye, Séverin > S??verin, > > Good question. I'm not sure if there is an "official" process for this, > but what I would suggest is to open a bug report on Mantis (bugs.squeak.org) > and upload your patches there. Then mention the bug report here on the list, > and also on the vm-dev list (http://lists.squeakfoundation.org/pipermail/vm-dev). > > The primary VM developers watch the vm-dev list (somewhat intermittently) > so that will be the best place to figure out how to get your fixes into the > Subversion repository. > > Dave |
Free forum by Nabble | Edit this page |