Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #37861 > unrolled thread
| Started by | rickman <gnuarm@gmail.com> |
|---|---|
| First post | 2015-04-02 21:08 -0400 |
| Last post | 2015-04-17 20:06 +0000 |
| Articles | 20 on this page of 102 — 24 participants |
Back to article view | Back to comp.lang.forth
Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-02 21:08 -0400
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-13 21:47 -0400
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-16 23:37 -0400
Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-16 20:59 -0700
Re: Mecrisp on the TI Stellaris Launchpad Mel Wilson <mwilson@the-wire.com> - 2015-04-17 13:16 +0000
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 00:19 -0400
Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-16 21:56 -0700
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 14:47 -0400
WAS: Mecrisp on the TI Stellaris Launchpad IS: Thunderbird Line Breaking rickman <gnuarm@gmail.com> - 2015-04-17 15:12 -0400
Re: WAS: Mecrisp on the TI Stellaris Launchpad IS: Thunderbird Line Breaking Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-17 20:14 +0000
Re: WAS: Mecrisp on the TI Stellaris Launchpad IS: Thunderbird Line Breaking rickman <gnuarm@gmail.com> - 2015-04-17 16:59 -0400
Re: WAS: Mecrisp on the TI Stellaris Launchpad IS: Thunderbird Line Breaking David Brown <david.brown@hesbynett.no> - 2015-04-18 10:00 +0200
Re: WAS: Mecrisp on the TI Stellaris Launchpad IS: Thunderbird Line Breaking rickman <gnuarm@gmail.com> - 2015-04-18 09:32 -0400
Re: WAS: Mecrisp on the TI Stellaris Launchpad IS: Thunderbird Line Breaking Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-18 15:15 +0000
Re: WAS: Mecrisp on the TI Stellaris Launchpad IS: Thunderbird Line Breaking rickman <gnuarm@gmail.com> - 2015-04-18 11:31 -0400
Re: WAS: Mecrisp on the TI Stellaris Launchpad IS: Thunderbird Line Breaking Niklas Holsti <niklas.holsti@tidorum.invalid> - 2015-04-18 19:21 +0300
Re: WAS: Mecrisp on the TI Stellaris Launchpad IS: Thunderbird Line Breaking rickman <gnuarm@gmail.com> - 2015-04-19 16:39 -0400
Re: WAS: Mecrisp on the TI Stellaris Launchpad IS: Thunderbird Line Breaking Alan Adams <alan@adamshome.org.uk> - 2015-04-18 18:52 +0100
Re: WAS: Mecrisp on the TI Stellaris Launchpad IS: Thunderbird Line Breaking "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-18 18:55 -0400
Re: WAS: Mecrisp on the TI Stellaris Launchpad IS: Thunderbird Line Breaking The Natural Philosopher <tnp@invalid.invalid> - 2015-04-19 09:13 +0100
Re: WAS: Mecrisp on the TI Stellaris Launchpad IS: Thunderbird Line Breaking Dimiter_Popoff <dp@tgi-sci.com> - 2015-04-19 13:22 +0300
Re: WAS: Mecrisp on the TI Stellaris Launchpad IS: Thunderbird Line Breaking David Brown <david.brown@hesbynett.no> - 2015-04-19 22:09 +0200
Re: Mecrisp on the TI Stellaris Launchpad mm0fmf <none@mailinator.com> - 2015-04-17 21:15 +0100
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 17:02 -0400
Re: Mecrisp on the TI Stellaris Launchpad mm0fmf <none@mailinator.com> - 2015-04-18 17:06 +0100
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-19 16:57 -0400
Re: Mecrisp on the TI Stellaris Launchpad Alan Adams <alan@adamshome.org.uk> - 2015-04-20 09:33 +0100
Re: Mecrisp on the TI Stellaris Launchpad mm0fmf <none@mailinator.com> - 2015-04-20 18:03 +0100
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-21 01:16 -0400
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 20:20 -0400
Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-17 17:24 -0700
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 20:40 -0400
Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-17 17:57 -0700
Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-18 10:04 +0200
Re: Mecrisp on the TI Stellaris Launchpad Jan Coombs <Jan-54 <jenfhaomndgfwutc@murmic.plus.com>> - 2015-04-18 09:38 +0100
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-18 11:04 -0400
Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-18 17:54 +0200
Re: Mecrisp on the TI Stellaris Launchpad hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) - 2015-04-18 15:36 -0500
Re: Mecrisp on the TI Stellaris Launchpad Theo Markettos <theom+news@chiark.greenend.org.uk> - 2015-04-23 07:59 +0100
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-25 14:35 -0400
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-25 15:44 -0400
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-05-08 12:00 -0400
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-05-10 03:36 -0400
Re: Mecrisp on the TI Stellaris Launchpad Theo Markettos <theom+news@chiark.greenend.org.uk> - 2015-05-10 10:32 +0100
Re: Mecrisp on the TI Stellaris Launchpad Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-05-10 12:56 +0300
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-05-10 10:48 -0400
Re: Mecrisp on the TI Stellaris Launchpad The Natural Philosopher <tnp@invalid.invalid> - 2015-05-10 16:05 +0100
Re: Mecrisp on the TI Stellaris Launchpad Mark Wills <markwills1970@gmail.com> - 2015-05-10 08:55 -0700
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-05-10 13:13 -0400
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-05-10 15:34 -0400
Re: Mecrisp on the TI Stellaris Launchpad albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-10 11:41 +0000
Re: Mecrisp on the TI Stellaris Launchpad Theo Markettos <theom+news@chiark.greenend.org.uk> - 2015-05-10 16:56 +0100
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-05-10 13:01 -0400
Re: Mecrisp on the TI Stellaris Launchpad stephen@mpeforth.com (Stephen Pelc) - 2015-04-18 19:22 +0000
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-19 17:04 -0400
Re: Mecrisp on the TI Stellaris Launchpad Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2015-04-20 13:24 +0300
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-22 13:23 -0400
Re: Mecrisp on the TI Stellaris Launchpad Dimiter_Popoff <dp@tgi-sci.com> - 2015-04-22 20:44 +0300
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-22 13:51 -0400
Re: Mecrisp on the TI Stellaris Launchpad Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2015-04-22 19:10 +0000
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-22 15:31 -0400
Re: Mecrisp on the TI Stellaris Launchpad Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2015-04-23 02:08 +0000
Re: Mecrisp on the TI Stellaris Launchpad Waldek Hebisch <hebisch@math.uni.wroc.pl> - 2015-04-24 02:52 +0000
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-25 14:40 -0400
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-25 15:42 -0400
Re: Mecrisp on the TI Stellaris Launchpad albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 10:52 +0000
Re: Mecrisp on the TI Stellaris Launchpad Dimiter_Popoff <dp@tgi-sci.com> - 2015-04-17 14:05 +0300
Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-17 07:56 -0700
Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-17 17:26 +0200
Re: Mecrisp on the TI Stellaris Launchpad glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-17 17:01 +0000
Re: Mecrisp on the TI Stellaris Launchpad Blajrs Jrolrsen <boegre@no.com> - 2015-04-17 13:36 +0000
Re: Mecrisp on the TI Stellaris Launchpad anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-17 14:42 +0000
Re: Mecrisp on the TI Stellaris Launchpad Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-04-18 00:25 +0200
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 20:03 -0400
Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-17 17:14 -0700
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 20:26 -0400
Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-17 17:32 -0700
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 20:47 -0400
Re: Mecrisp on the TI Stellaris Launchpad albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-18 08:47 +0000
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-18 11:19 -0400
Re: Mecrisp on the TI Stellaris Launchpad albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-18 15:52 +0000
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-19 17:07 -0400
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-06-09 03:04 -0400
Re: Mecrisp on the TI Stellaris Launchpad Robert Wessel <robertwessel2@yahoo.com> - 2015-04-18 00:11 -0500
Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-18 10:32 +0200
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-18 11:26 -0400
Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-18 17:57 +0200
Re: Mecrisp on the TI Stellaris Launchpad Paul Rubin <no.email@nospam.invalid> - 2015-04-18 09:42 -0700
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-19 17:11 -0400
Re: Mecrisp on the TI Stellaris Launchpad Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2015-04-18 12:19 +0200
Re: Mecrisp on the TI Stellaris Launchpad Dimiter_Popoff <dp@tgi-sci.com> - 2015-04-18 15:16 +0300
Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-18 19:57 +0200
Re: Mecrisp on the TI Stellaris Launchpad Dimiter_Popoff <dp@tgi-sci.com> - 2015-04-18 23:11 +0300
Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-19 21:32 +0200
Re: Mecrisp on the TI Stellaris Launchpad Dimiter_Popoff <dp@tgi-sci.com> - 2015-04-19 23:04 +0300
Re: Mecrisp on the TI Stellaris Launchpad anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 09:15 +0000
Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-18 12:17 +0200
Re: Mecrisp on the TI Stellaris Launchpad anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 13:08 +0000
Re: Mecrisp on the TI Stellaris Launchpad David Brown <david.brown@hesbynett.no> - 2015-04-18 20:17 +0200
Re: Mecrisp on the TI Stellaris Launchpad anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 15:33 +0000
Re: Mecrisp on the TI Stellaris Launchpad rickman <gnuarm@gmail.com> - 2015-04-17 14:52 -0400
Re: Mecrisp on the TI Stellaris Launchpad albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 20:06 +0000
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-04-25 15:44 -0400 |
| Message-ID | <mhgqo7$nne$2@dont-email.me> |
| In reply to | #38600 |
On 4/25/2015 2:35 PM, rickman wrote: > On 4/23/2015 2:59 AM, Theo Markettos wrote: >> In comp.sys.raspberry-pi rickman <gnuarm@gmail.com> wrote: >>> On 4/18/2015 4:38 AM, Jan Coombs <Jan-54 wrote: >>>> On Fri, 17 Apr 2015 20:20:30 -0400 >>>> rickman <gnuarm@gmail.com> wrote: >>>> >>>>> Now I am a bit stuck trying to get a serial port terminal emulation >>>>> running. It would appear that miniterm is the right program to >>>>> use, but >>>>> while dealing with the slowness of the rPi when web browsing I have >>>>> yet >>>>> to find it exactly. I thought I had found it at a site called Py >>>>> Serial. But I think what I downloaded with some sort of python >>>>> wrapper >>>>> for miniterm. I'm not sure really. >>>> >>>> gtkterm is simple and capable, but can't find rPi to check >>>> this :( To install, type at terminal: >>>> >>>> sudo apt-get install gtkterm >>> >>> 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". >> >> I don't know gtkterm, but the 'canonical' package people often talk >> about is >> minicom (not miniterm as you mentioned). However it has an annoying >> 'curses' (DOS-style) GUI - I prefer picocom because it doesn't have >> menus on >> obscure keypresses to configure it, you just tell it the >> serial device on the command line and away you go: >> picocom -b 115200 /dev/ttyUSB0 >> >>> It would be so much easier if I could access newsgroups on the rPi. Oh >>> well... >> >> So do that then ;-) >> >> sudo apt-get install tin >> NNTPSERVER=nntp.aioe.org tin -r >> >> then hit shift-S and type the name of a newsgroup you want to >> subscribe to. >> Navigate with the arrow keys. You can of course set it up with your >> newsserver and name etc (look in ~/.tin/), but the above should work >> directly. >> >> 'Other newsreaders are available', as they say. >> >>> 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. >> >> The default username is 'pi' and the password '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. >> >> You don't need a terminal emulator as such - the window that displays >> your >> session is already a terminal emulator. If it's on the Pi display >> then that >> could be a program like xterm or gnome-terminal, if you're using SSH >> then it >> could be a Windows program like PuTTY. That provides the >> terminal-to-pixels >> conversion, and then all you need to do is ensure that character >> stream that >> reaches it is in the right format. Typically this is done by >> propagating a >> TERM environment variable around (which SSH will do for you but picocom >> won't), for example TERM=vt100, so as long as whatever is outputting text >> know it's aiming for a vt100 it'll generate the right characters for >> PuTTY >> or whatever, even if they pass through three machines on the way. >> >> Anyway, for simple stuff you probably don't need to tell your heating >> controller or whatever to output vt100 codes - ASCII works just fine, the >> terminal settings only matter for things like cursor movement and >> graphics. >> >> So all you need is a program to display the traffic on the serial port - >> picocom or minicom will do, but they aren't 'terminal emulators' as such. > > I got minicom up (I was calling it miniterm, lol) but it doesn't seem to > have a setting for translating LF to CR/LF. The Mecrisp app on the > launchpad only sends LF. > > I also tried setting the "implicit CR on LF" option in Putty which > doesn't do the trick either. > > Just to recap, I have the rPi running headless with the command line on > the PC through SSH using Putty. The launchpad running Mecrisp is > ttyACM0 on the rPi. Through the Putty session I am running minicom to > the launchpad. Mecrisp seems to return "ok.<LF>" which marches across > the Putty window until it wraps at the right margin. > > Any suggestions? Someone suggested using microcom which handles the LF with no CR issue and I am talking to Mecrisp finally. Now I just have to learn it. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-08 12:00 -0400 |
| Message-ID | <miimhe$ob0$1@dont-email.me> |
| In reply to | #38603 |
On 4/25/2015 3:44 PM, rickman wrote: > On 4/25/2015 2:35 PM, rickman wrote: >> >> Just to recap, I have the rPi running headless with the command line on >> the PC through SSH using Putty. The launchpad running Mecrisp is >> ttyACM0 on the rPi. Through the Putty session I am running minicom to >> the launchpad. Mecrisp seems to return "ok.<LF>" which marches across >> the Putty window until it wraps at the right margin. >> >> Any suggestions? > > Someone suggested using microcom which handles the LF with no CR issue > and I am talking to Mecrisp finally. Now I just have to learn it. A fair amount of water has fallen over the damn and I have made some progress on my project. The Forth compiler is installed on the target. Using microcom on the rPi and Extra-Putty on my PC I can talk to the Forth program from the PC. Microcom got me around the problem I had with minicom where I needed the LF from the target translated to CRLF. I have completed my hardware setup and have some software to test, but I can't figure out how to transmit a file to the target either from the rPi or from the PC. Microcom doesn't seem to have an option for sending a file to the target and Putty only seems to support X and Y modem, not a simple dump of a text file. I found picocom and installed it on the rPi, but when I run it I get the configuration info and "Terminal Ready", but none of the commands seem to work. The escape key is supposed to be Cntl-A but nothing I type gets a response. I have to kill the putty session. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-10 03:36 -0400 |
| Message-ID | <min1oo$lv5$1@dont-email.me> |
| In reply to | #38899 |
I took a few more steps today. I found that Mecrisp will accept definitions spread over multiple lines and that Putty has an option that lets you drag and drop a file to send it to the target. It doesn't work perfectly, but it works. Now I can run some source and test it. To get something working better I tried using e4thcom which knows about the command line prompt in mecrisp and can load a file to it. e4thcom installed ok but when I run it I get no response from the target. I am invoking with this command... e4thcom -t mecrisp -d ttyACM0 -b B9600 It reports this... /dev/ttyACM0 open, hdl=3 B9600 8N1 CLOCAL ONLCR but when e4thcom is exited stty returns this... speed 0 baud; rows 0; columns 0; line = 0; among other things. Why would the speed be set to zero? Even when I run microcom the target does not respond. I have to reboot which resets the target too. :( -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Theo Markettos <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2015-05-10 10:32 +0100 |
| Message-ID | <lAD*SL8uv@news.chiark.greenend.org.uk> |
| In reply to | #38928 |
In comp.sys.raspberry-pi rickman <gnuarm@gmail.com> wrote: > To get something working better I tried using e4thcom which knows about > the command line prompt in mecrisp and can load a file to it. e4thcom > installed ok but when I run it I get no response from the target. I am > invoking with this command... > > e4thcom -t mecrisp -d ttyACM0 -b B9600 > > It reports this... > > /dev/ttyACM0 open, hdl=3 B9600 8N1 CLOCAL ONLCR > > but when e4thcom is exited stty returns this... > > speed 0 baud; rows 0; columns 0; line = 0; > > among other things. Why would the speed be set to zero? AIUI if you ask stty for speed, unless you give it a device name it'll return the speed of the terminal you're typing in at the moment. Terminal speed is, I think, supposed to be a hint to programs how much data they're likely to be able to output before the serial port gets congested. If connect to your Unix timesharing system via a VT100 then termcap will say it's at 9600 baud - not only do you need to configure the serial port but it could cause programs to adapt to the speed. This is all water under the 1970s bridge, so I'd imagine 'speed 0' means 'I don't care about that stuff any more'. > Even when I run microcom the target does not respond. I have to reboot > which resets the target too. :( Is it anything to do with CTS/RTS/DSR/DTR? A slow serial line getting wedged isn't uncommon if you're lacking flow control and doing bulk downloads. Theo
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2015-05-10 12:56 +0300 |
| Message-ID | <min9v3$ehp$1@dont-email.me> |
| In reply to | #38929 |
On 10.5.15 12:32, Theo Markettos wrote: > In comp.sys.raspberry-pi rickman <gnuarm@gmail.com> wrote: >> To get something working better I tried using e4thcom which knows about >> the command line prompt in mecrisp and can load a file to it. e4thcom >> installed ok but when I run it I get no response from the target. I am >> invoking with this command... >> >> e4thcom -t mecrisp -d ttyACM0 -b B9600 >> >> It reports this... >> >> /dev/ttyACM0 open, hdl=3 B9600 8N1 CLOCAL ONLCR >> >> but when e4thcom is exited stty returns this... >> >> speed 0 baud; rows 0; columns 0; line = 0; >> >> among other things. Why would the speed be set to zero? > > AIUI if you ask stty for speed, unless you give it a device name it'll > return the speed of the terminal you're typing in at the moment. Terminal > speed is, I think, supposed to be a hint to programs how much data they're > likely to be able to output before the serial port gets congested. If > connect to your Unix timesharing system via a VT100 then termcap will say > it's at 9600 baud - not only do you need to configure the serial port but it > could cause programs to adapt to the speed. This is all water under the > 1970s bridge, so I'd imagine 'speed 0' means 'I don't care about that > stuff any more'. > >> Even when I run microcom the target does not respond. I have to reboot >> which resets the target too. :( > > Is it anything to do with CTS/RTS/DSR/DTR? A slow serial line getting > wedged isn't uncommon if you're lacking flow control and doing bulk > downloads. > > Theo It could be software flow control, X-on, X-off getting wedged. -- -TV
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-10 10:48 -0400 |
| Message-ID | <minr1l$aaa$1@dont-email.me> |
| In reply to | #38929 |
On 5/10/2015 5:32 AM, Theo Markettos wrote: > In comp.sys.raspberry-pi rickman <gnuarm@gmail.com> wrote: >> To get something working better I tried using e4thcom which knows about >> the command line prompt in mecrisp and can load a file to it. e4thcom >> installed ok but when I run it I get no response from the target. I am >> invoking with this command... >> >> e4thcom -t mecrisp -d ttyACM0 -b B9600 >> >> It reports this... >> >> /dev/ttyACM0 open, hdl=3 B9600 8N1 CLOCAL ONLCR >> >> but when e4thcom is exited stty returns this... >> >> speed 0 baud; rows 0; columns 0; line = 0; >> >> among other things. Why would the speed be set to zero? > > AIUI if you ask stty for speed, unless you give it a device name it'll > return the speed of the terminal you're typing in at the moment. Terminal > speed is, I think, supposed to be a hint to programs how much data they're > likely to be able to output before the serial port gets congested. If > connect to your Unix timesharing system via a VT100 then termcap will say > it's at 9600 baud - not only do you need to configure the serial port but it > could cause programs to adapt to the speed. This is all water under the > 1970s bridge, so I'd imagine 'speed 0' means 'I don't care about that > stuff any more'. > >> Even when I run microcom the target does not respond. I have to reboot >> which resets the target too. :( > > Is it anything to do with CTS/RTS/DSR/DTR? A slow serial line getting > wedged isn't uncommon if you're lacking flow control and doing bulk > downloads. It appeared to be the speed. It seems there is some different handling of the tty settings in the two programs, microcom and e4thcom so that e4thcom leaves the port is a state that disrupts microcom. I set the data rate from stty and got microcom to work again. But now something else is messed up and even rebooting and cycling power won't fix it. I can get microcom to work, but the target won't respond unless I hit enter twice rapidly. 8-* This is getting to be rather frustrating. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2015-05-10 16:05 +0100 |
| Message-ID | <mins3u$eoo$1@news.albasani.net> |
| In reply to | #38934 |
On 10/05/15 15:48, rickman wrote: > On 5/10/2015 5:32 AM, Theo Markettos wrote: >> In comp.sys.raspberry-pi rickman <gnuarm@gmail.com> wrote: >>> To get something working better I tried using e4thcom which knows about >>> the command line prompt in mecrisp and can load a file to it. e4thcom >>> installed ok but when I run it I get no response from the target. I am >>> invoking with this command... >>> >>> e4thcom -t mecrisp -d ttyACM0 -b B9600 >>> >>> It reports this... >>> >>> /dev/ttyACM0 open, hdl=3 B9600 8N1 CLOCAL ONLCR >>> >>> but when e4thcom is exited stty returns this... >>> >>> speed 0 baud; rows 0; columns 0; line = 0; >>> >>> among other things. Why would the speed be set to zero? >> >> AIUI if you ask stty for speed, unless you give it a device name it'll >> return the speed of the terminal you're typing in at the moment. >> Terminal >> speed is, I think, supposed to be a hint to programs how much data >> they're >> likely to be able to output before the serial port gets congested. If >> connect to your Unix timesharing system via a VT100 then termcap will say >> it's at 9600 baud - not only do you need to configure the serial port >> but it >> could cause programs to adapt to the speed. This is all water under the >> 1970s bridge, so I'd imagine 'speed 0' means 'I don't care about that >> stuff any more'. >> >>> Even when I run microcom the target does not respond. I have to reboot >>> which resets the target too. :( >> >> Is it anything to do with CTS/RTS/DSR/DTR? A slow serial line getting >> wedged isn't uncommon if you're lacking flow control and doing bulk >> downloads. > > It appeared to be the speed. It seems there is some different handling > of the tty settings in the two programs, microcom and e4thcom so that > e4thcom leaves the port is a state that disrupts microcom. I set the > data rate from stty and got microcom to work again. But now something > else is messed up and even rebooting and cycling power won't fix it. I > can get microcom to work, but the target won't respond unless I hit > enter twice rapidly. 8-* > > This is getting to be rather frustrating. > We;come to the wonderful world of serial comms. I am SO glad is almost like a horse and cart,. There, but no one uses it -- Everything you read in newspapers is absolutely true, except for the rare story of which you happen to have first-hand knowledge. – Erwin Knoll
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2015-05-10 08:55 -0700 |
| Message-ID | <d9571103-f610-4bec-8a8d-f7c1959c9adc@googlegroups.com> |
| In reply to | #38934 |
The enter twice thing might be baud rate detection.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-10 13:13 -0400 |
| Message-ID | <mio3hs$9pr$4@dont-email.me> |
| In reply to | #38939 |
On 5/10/2015 11:55 AM, Mark Wills wrote: > The enter twice thing might be baud rate detection. I don't think so. It was working just fine and now I can't get it to take anything but Enter yielding an OK prompt. I'm taking yet another learning step. I originally flashed the launchpad on the PC. I am compiling the tools to flash it on the rPi. It is taking awhile. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-10 15:34 -0400 |
| Message-ID | <miobqr$g33$1@dont-email.me> |
| In reply to | #38944 |
On 5/10/2015 1:13 PM, rickman wrote: > On 5/10/2015 11:55 AM, Mark Wills wrote: >> The enter twice thing might be baud rate detection. You were close. When e4thcom exits it sets the character length to 5 for some very odd reason. microcom doesn't set that, so the only chars that are received properly are ones having zeros in only the first five bits. So now both terminal emulators are working and I can see if e4thcom does a better job with feeding source code to Mecrisp. I was trying to install the tools to compile lm4flash and the rpi ran out of memory and crashed. I will put that off to another day. I guess that shows the rPi doesn't have memory caching on the flash drive. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2015-05-10 11:41 +0000 |
| Message-ID | <554f43f7$0$21309$e4fe514c@dreader37.news.xs4all.nl> |
| In reply to | #38928 |
In article <min1oo$lv5$1@dont-email.me>, rickman <gnuarm@gmail.com> wrote: >I took a few more steps today. I found that Mecrisp will accept >definitions spread over multiple lines and that Putty has an >option that >lets you drag and drop a file to send it to the target. It >doesn't work >perfectly, but it works. Now I can run some source and test it. > >To get something working better I tried using e4thcom which knows about >the command line prompt in mecrisp and can load a file to it. e4thcom >installed ok but when I run it I get no response from the target. I am >invoking with this command... > >e4thcom -t mecrisp -d ttyACM0 -b B9600 > >It reports this... > >/dev/ttyACM0 open, hdl=3 B9600 8N1 CLOCAL ONLCR > >but when e4thcom is exited stty returns this... > >speed 0 baud; rows 0; columns 0; line = 0; > >among other things. Why would the speed be set to zero? > >Even when I run microcom the target does not respond. I have to reboot >which resets the target too. :( If you use serial over USB, the port settings like speed are virtually meaningless. > >-- > >Rick Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | Theo Markettos <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2015-05-10 16:56 +0100 |
| Message-ID | <kAD*S-9uv@news.chiark.greenend.org.uk> |
| In reply to | #38931 |
In comp.sys.raspberry-pi Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > If you use serial over USB, the port settings like speed are virtually > meaningless. Only if it's emulated serial, for instance a 3G dongle pretending to be a modem. If it ever goes into real serial (eg a USB-RS232 adaptor) then the settings matter. Theo
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-05-10 13:01 -0400 |
| Message-ID | <mio2s9$9pr$1@dont-email.me> |
| In reply to | #38940 |
On 5/10/2015 11:56 AM, Theo Markettos wrote: > In comp.sys.raspberry-pi Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: >> If you use serial over USB, the port settings like speed are virtually >> meaningless. > > Only if it's emulated serial, for instance a 3G dongle pretending to be a > modem. If it ever goes into real serial (eg a USB-RS232 adaptor) then the > settings matter. In this case there is a real serial port between the two chips on the launchpad. No handshakes though. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2015-04-18 19:22 +0000 |
| Message-ID | <5532ae07.113960555@news.eternal-september.org> |
| In reply to | #38255 |
On Fri, 17 Apr 2015 00:19:42 -0400, rickman <gnuarm@gmail.com> wrote: >Seems they did a poor job on power distribution on the >original design. The rPi 2 model B is supposed to be better. It can >also be used for real PC work... like web browsing. The B2 is significantly faster than the B+, even for single core apps. We are using Raspbian. >Now I have to figure out how to get a terminal emulator working on the >rPi. Can't be too hard... I just have to research it on my laptop >rather than on the rPi. The "standard" Linux terminal program is minicom. You will get far less noise in responses if you post the Linux questions on a Raspberry Pi group. RPi respondes seem to be much nicer than the average Lunux person. Similarly, I get much better Google responses when Raspberry Pi is included in the search request. Stephen -- Stephen Pelc, stephenXXX@mpeforth.com MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-04-19 17:04 -0400 |
| Message-ID | <mh1571$vc4$1@dont-email.me> |
| In reply to | #38358 |
On 4/18/2015 3:22 PM, Stephen Pelc wrote: > On Fri, 17 Apr 2015 00:19:42 -0400, rickman <gnuarm@gmail.com> wrote: > >> Seems they did a poor job on power distribution on the >> original design. The rPi 2 model B is supposed to be better. It can >> also be used for real PC work... like web browsing. > > The B2 is significantly faster than the B+, even for single core > apps. We are using Raspbian. > >> Now I have to figure out how to get a terminal emulator working on the >> rPi. Can't be too hard... I just have to research it on my laptop >> rather than on the rPi. > > The "standard" Linux terminal program is minicom. > > You will get far less noise in responses if you post the Linux > questions on a Raspberry Pi group. RPi respondes seem to be much > nicer than the average Lunux person. Similarly, I get much better > Google responses when Raspberry Pi is included in the search request. Thanks. I've been trying to get minicom installed and have not figured it out. I have crossposted to the rpi group, but some folks don't crosspost their replies which is ok with me. So I am discussing this there as well. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2015-04-20 13:24 +0300 |
| Message-ID | <mh2k35$6q6$1@dont-email.me> |
| In reply to | #38390 |
On 20.4.15 00:04, rickman wrote: > On 4/18/2015 3:22 PM, Stephen Pelc wrote: >> On Fri, 17 Apr 2015 00:19:42 -0400, rickman <gnuarm@gmail.com> wrote: >> >>> Seems they did a poor job on power distribution on the >>> original design. The rPi 2 model B is supposed to be better. It can >>> also be used for real PC work... like web browsing. >> >> The B2 is significantly faster than the B+, even for single core >> apps. We are using Raspbian. >> >>> Now I have to figure out how to get a terminal emulator working on the >>> rPi. Can't be too hard... I just have to research it on my laptop >>> rather than on the rPi. >> >> The "standard" Linux terminal program is minicom. >> >> You will get far less noise in responses if you post the Linux >> questions on a Raspberry Pi group. RPi respondes seem to be much >> nicer than the average Lunux person. Similarly, I get much better >> Google responses when Raspberry Pi is included in the search request. > > Thanks. I've been trying to get minicom installed and have not figured > it out. I have crossposted to the rpi group, but some folks don't > crosspost their replies which is ok with me. So I am discussing this > there as well. screen is much better for direct connection. It is a bit of a challenge to make Minicom not use any modem controls or dialing sequences. -- -TV
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-04-22 13:23 -0400 |
| Message-ID | <mh8lch$u9n$1@dont-email.me> |
| In reply to | #38408 |
On 4/20/2015 6:24 AM, Tauno Voipio wrote: > On 20.4.15 00:04, rickman wrote: >> On 4/18/2015 3:22 PM, Stephen Pelc wrote: >>> On Fri, 17 Apr 2015 00:19:42 -0400, rickman <gnuarm@gmail.com> wrote: >>> >>>> Seems they did a poor job on power distribution on the >>>> original design. The rPi 2 model B is supposed to be better. It can >>>> also be used for real PC work... like web browsing. >>> >>> The B2 is significantly faster than the B+, even for single core >>> apps. We are using Raspbian. >>> >>>> Now I have to figure out how to get a terminal emulator working on the >>>> rPi. Can't be too hard... I just have to research it on my laptop >>>> rather than on the rPi. >>> >>> The "standard" Linux terminal program is minicom. >>> >>> You will get far less noise in responses if you post the Linux >>> questions on a Raspberry Pi group. RPi respondes seem to be much >>> nicer than the average Lunux person. Similarly, I get much better >>> Google responses when Raspberry Pi is included in the search request. >> >> Thanks. I've been trying to get minicom installed and have not figured >> it out. I have crossposted to the rpi group, but some folks don't >> crosspost their replies which is ok with me. So I am discussing this >> there as well. > > > screen is much better for direct connection. It is a bit of a > challenge to make Minicom not use any modem controls or dialing > sequences. Thanks. At this point I'm getting (or should I say *am still*) frustrated with the Stellaris Launchpad. I tried using it on my win8 pc and the drivers won't install. Seems there is much stiffer driver signature enforcement in Win8 and Win7 so that you have to disable it and reboot. I'm not sure even then that it will work. I'm looking to see if using the STM32 would be easier. If I can't get drivers installed under Windows, I can't imagine how I would get them to work under Linux. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2015-04-22 20:44 +0300 |
| Message-ID | <mh8mk6$4e3$1@dont-email.me> |
| In reply to | #38509 |
On 22.4.2015 г. 20:23, rickman wrote: > On 4/20/2015 6:24 AM, Tauno Voipio wrote: >> On 20.4.15 00:04, rickman wrote: >>> On 4/18/2015 3:22 PM, Stephen Pelc wrote: >>>> On Fri, 17 Apr 2015 00:19:42 -0400, rickman <gnuarm@gmail.com> wrote: >>>> >>>>> Seems they did a poor job on power distribution on the >>>>> original design. The rPi 2 model B is supposed to be better. It can >>>>> also be used for real PC work... like web browsing. >>>> >>>> The B2 is significantly faster than the B+, even for single core >>>> apps. We are using Raspbian. >>>> >>>>> Now I have to figure out how to get a terminal emulator working on the >>>>> rPi. Can't be too hard... I just have to research it on my laptop >>>>> rather than on the rPi. >>>> >>>> The "standard" Linux terminal program is minicom. >>>> >>>> You will get far less noise in responses if you post the Linux >>>> questions on a Raspberry Pi group. RPi respondes seem to be much >>>> nicer than the average Lunux person. Similarly, I get much better >>>> Google responses when Raspberry Pi is included in the search request. >>> >>> Thanks. I've been trying to get minicom installed and have not figured >>> it out. I have crossposted to the rpi group, but some folks don't >>> crosspost their replies which is ok with me. So I am discussing this >>> there as well. >> >> >> screen is much better for direct connection. It is a bit of a >> challenge to make Minicom not use any modem controls or dialing >> sequences. > > Thanks. > > At this point I'm getting (or should I say *am still*) frustrated with > the Stellaris Launchpad. I tried using it on my win8 pc and the drivers > won't install. Seems there is much stiffer driver signature enforcement > in Win8 and Win7 so that you have to disable it and reboot. I'm not > sure even then that it will work. > > I'm looking to see if using the STM32 would be easier. If I can't get > drivers installed under Windows, I can't imagine how I would get them to > work under Linux. > Your experience seems to support my view that demo boards like that are useless. You will design and bring to life your end product board faster than you will make some demo toy being useful to you, i.e. all the time you spend on the latter will be wasted. Unless you want to make a product for sale (say, some piece of software) to run on exactly that, popular board, targeting people who already have it. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2015-04-22 13:51 -0400 |
| Message-ID | <mh8n0u$4tk$1@dont-email.me> |
| In reply to | #38511 |
On 4/22/2015 1:44 PM, Dimiter_Popoff wrote: > On 22.4.2015 г. 20:23, rickman wrote: >> On 4/20/2015 6:24 AM, Tauno Voipio wrote: >>> On 20.4.15 00:04, rickman wrote: >>>> On 4/18/2015 3:22 PM, Stephen Pelc wrote: >>>>> On Fri, 17 Apr 2015 00:19:42 -0400, rickman <gnuarm@gmail.com> wrote: >>>>> >>>>>> Seems they did a poor job on power distribution on the >>>>>> original design. The rPi 2 model B is supposed to be better. It can >>>>>> also be used for real PC work... like web browsing. >>>>> >>>>> The B2 is significantly faster than the B+, even for single core >>>>> apps. We are using Raspbian. >>>>> >>>>>> Now I have to figure out how to get a terminal emulator working on >>>>>> the >>>>>> rPi. Can't be too hard... I just have to research it on my laptop >>>>>> rather than on the rPi. >>>>> >>>>> The "standard" Linux terminal program is minicom. >>>>> >>>>> You will get far less noise in responses if you post the Linux >>>>> questions on a Raspberry Pi group. RPi respondes seem to be much >>>>> nicer than the average Lunux person. Similarly, I get much better >>>>> Google responses when Raspberry Pi is included in the search request. >>>> >>>> Thanks. I've been trying to get minicom installed and have not figured >>>> it out. I have crossposted to the rpi group, but some folks don't >>>> crosspost their replies which is ok with me. So I am discussing this >>>> there as well. >>> >>> >>> screen is much better for direct connection. It is a bit of a >>> challenge to make Minicom not use any modem controls or dialing >>> sequences. >> >> Thanks. >> >> At this point I'm getting (or should I say *am still*) frustrated with >> the Stellaris Launchpad. I tried using it on my win8 pc and the drivers >> won't install. Seems there is much stiffer driver signature enforcement >> in Win8 and Win7 so that you have to disable it and reboot. I'm not >> sure even then that it will work. >> >> I'm looking to see if using the STM32 would be easier. If I can't get >> drivers installed under Windows, I can't imagine how I would get them to >> work under Linux. >> > > Your experience seems to support my view that demo boards like that > are useless. You will design and bring to life your end product > board faster than you will make some demo toy being useful to you, > i.e. all the time you spend on the latter will be wasted. > Unless you want to make a product for sale (say, some piece of > software) to run on exactly that, popular board, targeting people > who already have it. In this case the project is truly an evaluation, not of the device, but of the project itself. So the goal is not to design a board, but to demonstrate the functionality of the end product at the lowest possible cost. The problem I'm having is not with the eval board, but with the tools. TI didn't provide a decent driver for their Stellaris Launchpad. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Waldek Hebisch <hebisch@math.uni.wroc.pl> |
|---|---|
| Date | 2015-04-22 19:10 +0000 |
| Message-ID | <mh8rnu$rfc$1@speranza.aioe.org> |
| In reply to | #38509 |
In comp.lang.forth rickman <gnuarm@gmail.com> wrote:
>
> At this point I'm getting (or should I say *am still*) frustrated with
> the Stellaris Launchpad. I tried using it on my win8 pc and the drivers
> won't install. Seems there is much stiffer driver signature enforcement
> in Win8 and Win7 so that you have to disable it and reboot. I'm not
> sure even then that it will work.
>
> I'm looking to see if using the STM32 would be easier. If I can't get
> drivers installed under Windows, I can't imagine how I would get them to
> work under Linux.
>
Mistake. For demo boards most of the driver nonsense suffered
by Windows users is absent on Windows. Demo boards typically
have UART interface which is mostly standard and can be handled
by single generic driver. And on Linux it is handled in that
way: demo board and various USB-UARTS are automatically handled
by builtin Linux drives. Only Windows forces you to install
extra drivers.
For Stellaris/Tiva Launchpad main interface is special USB endpoint.
The lm4flash programs uses libusb to contact to this endpoint
and flash your program. Kernel has everything needed to talk
to USB bus, the rest is userland. So no driver installation.
Of course, you need to have libusb and need to compile lm4tools
package. Also, you need appropriate permissions. On my machine
I created /etc/udev/rules.d/46-ev-board.rules and put there
the followings lines:
# Stellaris Launchpad
SUBSYSTEM=="usb",ATTRS{idVendor}=="1cbe",ATTRS{idProduct}=="00fd",MODE:="0666"
KERNEL=="ttyACM*",ATTRS{idVendor}=="1cbe",ATTRS{idProduct}=="00fd",MODE:="0666"
It is lousy securitywise because is gives access to demo board to
all users, but it works. Other folks posted similar setups.
In another post you wrote that you figured out main trouble, that
is that you need to use 'debug' USB port to connect to PC. 'device'
port is the one connected to Stellaris processor and is for use of
the program on demo board. The 'debug' port is debugging/programing
interface and also gives an USB-UART (the other end of UART is connected
to hardware UART on Stellaris processor). With that problem solved
Launchpad should work without problems. FYI, I connected several
Launchpads to several different Linux machines and things worked
fine from the starts. To be clear: Stellaris errata looks really
bad and for me beakpoints in gdb do not work. But lm4flash
has no problem finding the Launchpad and programming works fine.
--
Waldek Hebisch
hebisch@math.uni.wroc.pl
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.forth
csiph-web