Mecrisp on the TI Stellaris Launchpad

What do you call a UART on a USB port? These things are MCUs with a USB on one side and a UART on the hardware side. The software on the PC makes them look like a UART to the PC, but the PC is really talking over USB.

The question is how do you know that? As I have said, I know how to do this stuff under Windows, but not under Linux.

I've also posted that when I do an ls /dev/tty* I get a list of tty, tty0 through tty63, ttyAMA0 and ttyprintk. This list does not change when I plug the device in or unplug it. I also spent some time plugging in a number of USB UARTs and none of them showed up any differently this way. I did find one that crashes the rPi as soon as I plug it in. I expect this is part of the power issues the rPi has.

What do you mean, "announces itself"? Where do you see that?

I'm not totally clear on the difference. A modem is connected to the PC via a UART. To talk to a modem the software talks through the UART. I suppose there is the AT command protocol that is used to control the modem which has nothing to do with the UART. I guess the modem is like another layer on top of the UART although that assumes a smart modem as opposed to a dumb modem which just transmits the data it sees one bit at a time.

Thanks for the effort, but no, this has not helped. I understand modems and UARTs probably more than most people. I don't know much about Linux and I don't see anything here that explains that. I'm a complete noob at Linux, not computers.

--

Rick
Reply to
rickman
Loading thread data ...

Thunderbird is wrapping your lines perfectly well - you can see this by using ctrl-U to see the "source" of the posts.

But Thunderbird re-wraps for display - if the lines in a post are not quoted, and appear to be a line-wrapped paragraph, it re-wraps then to the width of the window. I am somewhat in two minds as to whether this is a good thing or a bad thing, but I haven't tried to turn it off.

So your posts from Thunderbird are absolutely fine.

Reply to
David Brown

If you are running from X, then there are a few terminal editor programs (including putty, which might be familiar to you from windows).

From the command line, I prefer to use "screen" for serial ports. I use "screen" at lot for other purposes (if you don't know it, look it up on google - it's very useful for getting lots of cli windows, but this is not the place for covering details).

screen /dev/ttyUSB0 115200

Reply to
David Brown

Once you have figured out what devices you are plugging in, and where ("lsusb" and "lsusb -v" are very handy), udev rules are your friend for making it all consistent and easy to use.

This is from my "52-david.rules" file in /etc/udev/rules.d on my development PC (the rules files are read in order, so the "52" is about the middle) :

KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.1/2-1.1:1.0/*", SYMLINK += "ttySerial_hub1" KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.2/2-1.2:1.0/*", SYMLINK += "ttySerial_hub2" KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.3/2-1.3:1.0/*", SYMLINK += "ttySerial_hub3" KERNEL=="ttyUSB*", DEVPATH=="*/usb2/2-1/2-1.4/2-1.4:1.0/*", SYMLINK += "ttySerial_hub4"

KERNEL == "ttyUSB*", ATTRS{idVendor} == "0403", ATTRS{idProduct} == "6001", \ ATTRS{serial} == "FTFLYG0L", SYMLINK += "ttySerial_ttl1"

ATTR{idVendor}=="0403", ATTR{idProduct}=="6001", \ ATTR{serial}=="FTUSV1RA", SYMLINK += "ttySerial_232"

The key points here are to give a list of identification checks (like the ttyUSB kernel driver, used for FTDI devices, or the physical path through hubs, or the serial numbers, vendor IDs, etc., of the device), and then a list of commands. Typical commands change the permissions (to make particular devices available to particular users), and SYMLINK to make new symbolic links.

So with this setup, I have a four-port hub that I use to connect FTDI serial ports - TTL, RS232, RS485, etc. When I connect then, the first connected gets /dev/ttyUSB0, then the next gets /dev/ttyUSB1, etc. Unlike Windows, the numbers are not tracked by serial number of the device - this means the same devices entered in different orders get different numbers. On the other hand, you don't end up with numbers like COMM123 ...

With the udev rule above, the devices get additional names when plugged into particular ports on the hub. This means that I always know exactly which device is which, using those symbolic names. It doesn't matter if /dev/ttySerial_hub2 points to /dev/ttyUSB0 - I know which port it is attached to.

Another quick point - if you are working with serial ports, and you like Python, don't forget that pyserial is your friend :-)

Reply to
David Brown

How people answer questions is going to vary a great deal, no matter what the subject and what the group - don't tar all "linux communities" as being bad support. But if you /do/ feel you are getting bad support somewhere, ignore them or find another forum - don't stop asking questions, and never stop asking "why?". It's crucial to learning.

I fully agree that there are good and bad things about Linux and Windows. I couldn't do my work with only one of them.

It is the "power users" from Windows that find Linux hardest, precisely because there are many small differences that lie under the surface, unseen by users who are satisfied by email, browser, media player and a few games.

But there are many things about the Unix design that have turned out to be very good decisions. When you look at the differences between Linux and Windows, many aspects trace their roots back to the beginnings of the systems - for Linux, this was Unix of the 70's, and for Windows it was MSDOS. And then consider where Unix came from - it came from serious computing professionals, big companies, big universities, big multi-user computers. It has always been serious stuff, made by serious people. MSDOS, on the other hand, was a con-job pulled off by a couple of guys (admittedly quite good programmers), hacked together for a marketing exercise that was never meant to be used for real work.

Some Linux users therefore feel completely justified in being arrogant about the superiority of the Linux "guts" compared to that of Windows. But if it bugs you (and it certainly can be annoying), just ignore it and move along.

Reply to
David Brown

gtkterm is simple and capable, but can't find rPi to check this :( To install, type at terminal:

sudo apt-get install gtkterm

In a terminal type:

dmesg | tail

and you will see the end of the system log. If you just plugged the USB, then you should see something like:

"FTDI USB Serial Device converter now attached to ttyUSB1"

For the above, the com port name/location is /dev/ttyUSB1

To access the comm ports as a regular user you might need to join the dialout group. To check current status type:

groups

To add user "rick" to dialout group, type at prompt either of these: (your user name might be "pi")

sudo usermod -a -G dialout rick sudo adduser rick dialout

Checked this on my desktop, so maybe not quite so. The rPi will run a number of linux systems, so if you have further problems say which version of linux it is running.

uname -a

I recently connected the little MSP430 launchpad board at work, and struggled. I could re-check this on Monday.

Jan Coombs

--
http://askubuntu.com/questions/112568/how-do-i-allow-a-non-default-user-to-use-serial-device-ttyusb0 
email valid, else fix dots and hyphen 
 Click to see the full signature
Reply to
Jan Coombs

That may be true. But with gforth on the rPi, I demonstrated the following on a fair, couple of years back: - add only a screen and a keyboard - run gforth to compile noforth - install noforth on the launchpad - compile a real time program for metallophones - load it on the launchpad and make it a turnkey - run the turnkey, even detached from the rPi

So for old school, who worked on the pdp10's, it is a decent development system.

I've much more sbc's in store than I can get acquainted with in my lifetime ...

Groetjes Albert

--
Albert van der Horst, UTRECHT,THE NETHERLANDS 
Economic growth -- being exponential -- ultimately falters. 
 Click to see the full signature
Reply to
Albert van der Horst

Pretty much any home computer from the 1970s and 1980s included BASIC. Yes, an interpreter, but that does not stop anyone from programming.

Anyway, Unix may have the highest proportion of programmers, but it seems that non-programmers are the primary target of the Linux distributions these days. E.g., neither emacs nor vi nor Eclipse is installed in Debian by default. Or look at what programming languages are installed by default. Only those necessary for running the scripts, no others.

Actually (and getting back on-topic a little bit) the Raspberry Pi was created exactly to get away from the current non-programming culture and get more people to program, like home computers did in the 1980s.

Not in my experience: If I am in a gforth build directory, I pretty much always want to call ./gforth rather than /usr/bin/gforth when I type gforth. If I want to call /usr/bin/gforth, I either do it from a different directory, or I say, e.g., gforth-0.7.0.

As for /opt, I don't know where that nonsense comes from, but it certainly does not come from the original Unix. Proper programs are installed in one of the directories that users have in the PATH by default (such as /usr/bin or /usr/local/bin) rather than somewhere in /opt (which indicates that the programmer is too lazy to make a working "make install").

On Windows and MacOS, the usual way to call a program is to click on an icon, and AFAIK that works with absolute file names, no PATH incolved.

- anton

--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html 
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html 
 Click to see the full signature
Reply to
Anton Ertl

Most distros install a subset of commonly used tools, and then make it easy for others to be installed. There are vast numbers of tools, editors, languages, libraries, etc., commonly used by programmers - it would be ridiculous to install 2GB+ of popular programming tools when even most full-time programmers won't need them. (i.e., /you/ might want emacs - but someone else will want eclipse, or vim, or jedit, or netbeans, or QT tools, etc.).

You appear to be supremely confident that your own personal usage of Linux, and your own (somewhat lacking and biased) view of OS history, is /the/ truth and /the/ right way to do things. Linux, and Unix in general, is all about flexibility and the freedom to use the tools you want in the way you want.

So choose the PATH settings that work for /you/, and choose the file system organisation that works for /you/. But don't try and tell everyone else that they are lazy or otherwise "wrong" for using a different organisation.

That's correct. But DLL libraries and other files may need to be in the PATH (or a library path variable).

Reply to
David Brown

Am 18.04.2015 um 02:03 schrieb rickman:

In all fairness, from this end your attitude, particularly that "really!?", did come across pretty much the same, just applied the opposite way. This attitude thing does cut both ways.

That's the "trillions of flies eat shit, so that must be a good thing!" fallacy. Democracy just doesn't work to decide about technical merit.

Reply to
Hans-Bernhard Bröker

Certainly true, however its implication "this is what flies do, so I shall not do it" is also a widespread fallacy (e.g. means you will not consider flying as an option). Then the fallacy you point to is what most if not all of the pro linux/gnu arguments are based on.

Your argument (from a previous post) about the user being left to decide whether to have his current directory as one of his exec paths is quite correct.

BTW, does anyone know how much unix is there within Android? Its event timings and latencies are *so* pathetic I could not imagine the entire linux thing would have survived that long if it were that bad. Good thing tablet devices have become cheap enough to not regret much if you smash one against the wall.

Dimiter

------------------------------------------------------ Dimiter Popoff, TGI

formatting link

------------------------------------------------------

formatting link

Reply to
Dimiter_Popoff

So what? The distro also installs stuff like nano and an inetd that most people don't use. Somehow, when I last looked (a few years ago), Debian installed nothing that I use, except a shell and apt-get; that's ok when I ask for a minimal install, but requiring 600MB for that alone is a bit stiff. Anyway, in the old days distros used to have options that said "typical server", "typical desktop", "typical development environment"; I have not seen the latter option for a number of years.

And installing hundreds of packages to get a decent environment gets old quick, even if each package is easy to install.

Sure, comes from experience, not just with Linux, but also with other Unices for about 29 years. If you want to counter my point, you could try explaining the benefits of /opt instead of making an ad-hominem attack.

- anton

--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html 
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html 
 Click to see the full signature
Reply to
Anton Ertl

Thanks for the info. It's good to know this is correct. There is one nut case in the Forth group who replies to my posts with a bit of boiler plate added saying my lines were not wrapped correctly and he rewrapped them for me, lol.

But that doesn't explain the issue I have where quoted text in the window for composing messages often is not wrapped and runs off the edge of the window. Any idea what causes that? It makes it very hard to see what I am replying to. This message seems to be just fine, I suppose because the lines *are* wrapped. Looking at my post from April 16 at

5:24 PM I see my lines are *not* wrapped. I see in the source the = char at the end of each line which I assume means a continuation. Strange... This seems to not be wrapped in the composition window when replying.
--

Rick
Reply to
rickman

Ok, lsusb is helping. If I plug into the "device" port on the launchpad

*nothing* shows up. If I plug into the "debug" port it shows up as dev1.7. This is on the same port that was showing a mouse as dev1.6. But this is a start. I guess I was using the wrong port on the launchpad.

I appreciate the help, but I don't understand much of this. Like I've said, I'm a complete noob at Linux. Do I need to do any of this? There is only one user, "raspberry".

But only if the devices are connected in the same order each time. I noticed that when the mouse is plugged in it was port 1.6. When I unplug it and use that port for the launchpad it becomes port 1.7. Is that expected?

It may be my friend, but I can't figure out how to run it... Is that what friends are about, hard to understand? I also can't figure out how to run miniterm. Google searches... or more accurately a duckduckgo search on miniterm I get all manner of links to pyserial and few, if any, to miniterm. The noob factor is at work. I can download what seems to be pyserial, but I can't figure out how to run it as an application.

--

Rick
Reply to
rickman

Sounded good, but didn't work. I am familiar with the "sudo apt-get install" thing. I think that was the first thing I learned a few weeks ago (or was it months?) when I first powered up the rPi. This time it says "Unable to locate package gtkterm".

It would be so much easier if I could access newsgroups on the rPi. Oh well...

Yeah, I've already figured out I was using the wrong port on the launchpad for the UART. Seems it is the same port as the debugger. So now I can see it.

I have to switch it out with the mouse and every time the USB number increments. The mouse is now on port 1.8 lol.

Now I just need to figure out my user name. I haven't logged into this thing in months. I believe the default is raspberry.

I'm running Raspbian. I think I have all the pieces now except a terminal emulator. When reading about miniterm it says it lets the command window handle ANSI code formatting and that window is called "terminal". I'm wondering if I need a terminal emulator at all. I guess the "terminal emulator" reroutes the keystrokes to the serial port output and the serial port input to the display. There would be no way to do that with pipes or such. That would allow me to control the command window from the serial port perhaps which is not what I need.

--

Rick
Reply to
rickman

I some NNTP clients don't seem wrap outgoing lines, But I don't know which ones they are.

Pan has the ability to display incoming messages as they were received or after wrapping them, which is quite useful.

Wrapping is useful if long lines are received, but it can mess up lines which start with hyphens or asterisks because it thinks that means 'join to preceding line' rather than 'another item in the list'. Hitting 'w' toggles between wrap and no-wrap so either way the fix is instant.

--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie

I know what you mean. I have a small stack of MCU boards here I've never applied power to. I bought four of the Cypress boards to help Matthais with Mecrisp only to find the Cypress development system is rather obtuse. They intentionally hide as much as possible from the user... in this case a designer! I had to ask all manner of questions to get something very basic going. But the boards were only $3 or $4 in two slightly different flavors. That's why I bought four, lol.

So is noforth documented much? That is one problem I'm having with Mecrisp. It doesn't have a lot of documentation, which is something I would like to work on. Matthias has ported it to several MSP430s and then discovered the ARM CM line. I think there are some dozen ARM targets ready to fire up on eval boards. He really liked the STM line I think. I have an old Motorolla board that should be worth firing up and I think the processor has a version ready for it. Cool.

But if noforth would get me to my goal more quickly on this task, I would like to consider it. But it looks like it is only for the MSP430 and not the ARM board I currently have.

--

Rick
Reply to
rickman

Thank you for the support. I *did* let it stop me from learning Linux on several occasions. But now that I have a project for the rPi, I have more incentive to dig in. I'm spending a lot of time with this now.

Lol, I was actually using Unix in the 70's, the era of command line processing. I learned cat I recall... but not much more. I think I used it some more in the 90's, but didn't find that experience rewarding at all. For some reason the delete and backspace keys were reversed on our workstations and I was told I could define it any way I wished... lol. Not much good if you don't know how to redefine it.

I don't care about origins or intent. I just want to get some work done with the minimum of hassle. I'm still amazed at how slow computers have gotten as the CPUs have gotten faster. The rPi is no exception. It is many times faster and has much more memory than the machine I first got on the Internet with. But I guess browsers and HTML have changed to demand more. That's the main reason why I want to use Forth. It is very light weight and puts little strain on the system hosting it. Heck, Mecrisp runs entirely on the target!

--

Rick
Reply to
rickman

I don't wish to belabor this too much. It is off topic and I just thought someone with Thunderbird experience might have a quick answer. This issue is not on reading messages, that always wraps lines so they are viewable. It is the quoted text in the reply that will not be wrapped if it is not broken in the received message. Very odd....

--

Rick
Reply to
rickman

No, you certainly don't /need/ any of it. But it can sometimes make life a little easier. If you only use one user, and have made sure that it is in the right groups (typically "dialout" and/or "plugdev" - details vary from distro to distro), then you will have full access to the USB serial devices. If you have problems, you can also access the port as "root". (Some people will call such advice blasphemy, but sometimes it is simply easier to do things as root.)

Other than that, keep a note of this post. If you want to use more devices in the future and get consistent names, then it will give you clues - especially when combined with a google search for udev rules. (Of course, you could also post again here.) Even if you don't need these things now, it might be useful to know about them in the future.

Yes - some of the number in USB devices simply increments each time a device is attached. The DEVPATH I used in the rules above does not act like that - it is a tree based on the physical path through hubs, and is thus completely independent of the ordering.

pyserial is not an application - it is a library for Python. If you have experience with Python programming (or /want/ experience with Python programming - it's a nice high-level language, fully cross-platform), then you should find pyserial quite easy to use. You can try it on Windows first for familiarity - it works there too.

But if you haven't used Python, then pyserial is not your friend for now!

As I noted elsewhere, try "screen" rather than miniterm - "screen /dev/ttyUSB0 115200" gets you connected at 115200 baud. Obviously change the /dev/ttyUSB0 as needed.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.