Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #37861 > unrolled thread

Mecrisp on the TI Stellaris Launchpad

Back to article view | Back to comp.lang.forth

Contents

  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 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#38516

On 4/22/2015 3:10 PM, Waldek Hebisch wrote:
> 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.

Not sure what this means.


> 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.

Maybe you are right about the drivers, but I haven't been able to get a 
terminal program installed and I'm a bit fed up messing with it.  So 
choose your poison.  Go with an OS where the eval board maker can make 
it easy to install their board if they want and everything else is there 
waiting for me to use, or go with an OS where the board installs easily 
and everything else is an uphill climb.


> 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.

I'm not using gdb, just a terminal interface to the Forth that should be 
running on the target processor already.

At this point the rPi is off the workbench and in a box.  I'd be happy 
to pull it back out if I had any confidence it is more likely to work 
than the drivers for the STMdiscovery boards I've ordered, or if it 
would save me the time.  I don't expect them to be here before Friday at 
the earliest.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#38522

In comp.lang.forth rickman <gnuarm@gmail.com> wrote:
> On 4/22/2015 3:10 PM, Waldek Hebisch wrote:
> 
> I'm not using gdb, just a terminal interface to the Forth that should be 
> running on the target processor already.
> 
> At this point the rPi is off the workbench and in a box.  I'd be happy 
> to pull it back out if I had any confidence it is more likely to work 
> than the drivers for the STMdiscovery boards I've ordered, or if it 
> would save me the time.  I don't expect them to be here before Friday at 
> the earliest.
> 

You wrote that you can not install a terminal emulator.  What
get wrong?  For me

apt-get install minicom

worked as expected.  Next

minicom -b 115200 -o -D /dev/ttyACM0

connects me to mecrisp.  All this on Banana Pi running Raspbian 7.

There is a problem, namely mecrisp seem to emit lone linefeed
at the end of line, while minicom expects to receive carrage
return + linefeed pair.  So one gets staicaise pattern on the
screen.  There is no obvious way to convince minicom to treat
linefeed as line ending.  I admit that I am surprised by this,
I used minicom several times I never met such problem (apparently
any other source emits carrage returns).


-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 

[toc] | [prev] | [next] | [standalone]

#38551

In comp.lang.forth Waldek Hebisch <hebisch@math.uni.wroc.pl> wrote:
> In comp.lang.forth rickman <gnuarm@gmail.com> wrote:
> > On 4/22/2015 3:10 PM, Waldek Hebisch wrote:
> > 
> > I'm not using gdb, just a terminal interface to the Forth that should be 
> > running on the target processor already.
> > 
> 
> You wrote that you can not install a terminal emulator.  What
> get wrong?  For me
> 
> apt-get install minicom
> 
> worked as expected.  Next
> 
> minicom -b 115200 -o -D /dev/ttyACM0
> 
> connects me to mecrisp.  All this on Banana Pi running Raspbian 7.
> 
> There is a problem, namely mecrisp seem to emit lone linefeed
> at the end of line, while minicom expects to receive carrage
> return + linefeed pair.  So one gets staicaise pattern on the
> screen.  There is no obvious way to convince minicom to treat
> linefeed as line ending.  I admit that I am surprised by this,
> I used minicom several times I never met such problem (apparently
> any other source emits carrage returns).
> 

I tried another program, that is microcom:

apt-get install microcom 

installs it, then

microcom -p /dev/ttyACM0

connects me to mecrisp.  It seems to work fine (unlike mincom there
is no staircaise pattern).

BTW: Both commands as root.  To use as ordinary users one needs
to set permissions as described in other posts.

-- 
                              Waldek Hebisch
hebisch@math.uni.wroc.pl 

[toc] | [prev] | [next] | [standalone]

#38601

On 4/23/2015 10:52 PM, Waldek Hebisch wrote:
> In comp.lang.forth Waldek Hebisch <hebisch@math.uni.wroc.pl> wrote:
>> In comp.lang.forth rickman <gnuarm@gmail.com> wrote:
>>> On 4/22/2015 3:10 PM, Waldek Hebisch wrote:
>>>
>>> I'm not using gdb, just a terminal interface to the Forth that should be
>>> running on the target processor already.
>>>
>>
>> You wrote that you can not install a terminal emulator.  What
>> get wrong?  For me
>>
>> apt-get install minicom
>>
>> worked as expected.  Next
>>
>> minicom -b 115200 -o -D /dev/ttyACM0
>>
>> connects me to mecrisp.  All this on Banana Pi running Raspbian 7.
>>
>> There is a problem, namely mecrisp seem to emit lone linefeed
>> at the end of line, while minicom expects to receive carrage
>> return + linefeed pair.  So one gets staicaise pattern on the
>> screen.  There is no obvious way to convince minicom to treat
>> linefeed as line ending.  I admit that I am surprised by this,
>> I used minicom several times I never met such problem (apparently
>> any other source emits carrage returns).
>>
>
> I tried another program, that is microcom:
>
> apt-get install microcom
>
> installs it, then
>
> microcom -p /dev/ttyACM0
>
> connects me to mecrisp.  It seems to work fine (unlike mincom there
> is no staircaise pattern).
>
> BTW: Both commands as root.  To use as ordinary users one needs
> to set permissions as described in other posts.

To answer your earlier question the problem was a short between the 
headphones.  I was calling it miniterm rather than minicom.  lol

I reached the point you describe where Mecrisp is not sending a CR with 
the LF and minicom can't seem to deal with that or Putty either oddly 
enough.  I guess there is something about an SSH session that interferes 
with this.

I will try microcom (and not microterm, lol)

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#38602

On 4/25/2015 2:40 PM, rickman wrote:
> On 4/23/2015 10:52 PM, Waldek Hebisch wrote:
>> In comp.lang.forth Waldek Hebisch <hebisch@math.uni.wroc.pl> wrote:
>>> In comp.lang.forth rickman <gnuarm@gmail.com> wrote:
>>>> On 4/22/2015 3:10 PM, Waldek Hebisch wrote:
>>>>
>>>> I'm not using gdb, just a terminal interface to the Forth that
>>>> should be
>>>> running on the target processor already.
>>>>
>>>
>>> You wrote that you can not install a terminal emulator.  What
>>> get wrong?  For me
>>>
>>> apt-get install minicom
>>>
>>> worked as expected.  Next
>>>
>>> minicom -b 115200 -o -D /dev/ttyACM0
>>>
>>> connects me to mecrisp.  All this on Banana Pi running Raspbian 7.
>>>
>>> There is a problem, namely mecrisp seem to emit lone linefeed
>>> at the end of line, while minicom expects to receive carrage
>>> return + linefeed pair.  So one gets staicaise pattern on the
>>> screen.  There is no obvious way to convince minicom to treat
>>> linefeed as line ending.  I admit that I am surprised by this,
>>> I used minicom several times I never met such problem (apparently
>>> any other source emits carrage returns).
>>>
>>
>> I tried another program, that is microcom:
>>
>> apt-get install microcom
>>
>> installs it, then
>>
>> microcom -p /dev/ttyACM0
>>
>> connects me to mecrisp.  It seems to work fine (unlike mincom there
>> is no staircaise pattern).
>>
>> BTW: Both commands as root.  To use as ordinary users one needs
>> to set permissions as described in other posts.
>
> To answer your earlier question the problem was a short between the
> headphones.  I was calling it miniterm rather than minicom.  lol
>
> I reached the point you describe where Mecrisp is not sending a CR with
> the LF and minicom can't seem to deal with that or Putty either oddly
> enough.  I guess there is something about an SSH session that interferes
> with this.
>
> I will try microcom (and not microterm, lol)

Yep, that did the trick.  Now I just need to learn Mecrisp.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#38267

In article <mgpv33$469$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>On 4/16/2015 6:11 PM, Paul Rubin wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> compile, but I can't seem to figure out how to run it.  I type
>>> lm4flash at the command line, but it says "command not found".  The
>>> file has no visible extension.  Is that expected?  What am I missing?
>>
>> Try ./lm4flash
>
>Yes, I figured that out.  It seems the current working directory is not
>considered under Linux for finding executables... really!?

Not correct. The PATH for finding executables is fully under control.
It is urban legend that there is a security leak by having de current
directory in the PATH. ("someone could have sneaked an ls in your directory
that installs a rootkit.") This is nonsensical for normal users.
So blame the idiots that have nothing better to do than this, not linux, and
put the line
    PATH=".:$PATH"
in your profile.
If you're still a bit worried, you could do
    PATH="$PATH:."
and refrain from doing it for the root user (assuming
you've ditched sudo).

This should be in the Unix FAQ.

<SNIP>
>
>--
>
>Rick
-- 
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]

#38268

On 17.4.2015 г. 13:52, Albert van der Horst wrote:
> In article <mgpv33$469$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>> On 4/16/2015 6:11 PM, Paul Rubin wrote:
>>> rickman <gnuarm@gmail.com> writes:
>>>> compile, but I can't seem to figure out how to run it.  I type
>>>> lm4flash at the command line, but it says "command not found".  The
>>>> file has no visible extension.  Is that expected?  What am I missing?
>>>
>>> Try ./lm4flash
>>
>> Yes, I figured that out.  It seems the current working directory is not
>> considered under Linux for finding executables... really!?
>
> Not correct. The PATH for finding executables is fully under control.
> It is urban legend that there is a security leak by having de current
> directory in the PATH. ("someone could have sneaked an ls in your directory
> that installs a rootkit.") This is nonsensical for normal users.
> So blame the idiots that have nothing better to do than this, not linux, and
> put the line
>      PATH=".:$PATH"
> in your profile.

I think what Rick was saying is that the current directory is not
searched for executables in unix, not that it cannot be made to be
searched.
Even I know it can be made (and once I knew how....), and I am not
a unix user much more than a windows one (i.e. I can use either as
a computerized TV set but not much beyond that).

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

[toc] | [prev] | [next] | [standalone]

#38275

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
> Not correct. The PATH for finding executables is fully under control.
> It is urban legend that there is a security leak by having de current
> directory in the PATH. ("someone could have sneaked an ls in your directory
> that installs a rootkit.")

No it wasn't an urban legend, it was a real issue.  In the old days "."
was the first thing on the path and there were actual incidents of what
you described.  E.g. you'd be a sysadmin of some university timesharing
system, you'd get told that some student had porn in his home directory,
you'd cd to the directory and type "ls" as root, and hilarity ensues.  I
think there is a paper by Fred Grampp about this, that introduced the
practice of getting "." off of the standard path.

> This is nonsensical for normal users.

I'd say it's still not nonsensical: you unpack an archive, cd to it and
type "ls", same situation.  Or even in non-malicious cases, someone
might have chosen a program name that wasn't a standard Unix command,
but that happened to match something that you used and was on your path.
Like I think there are at least 2 different Forth implementations called
pforth.  So maybe you use one of them and the directory you cd to has
the other one, so you type "pforth" and get the wrong one, etc.

[toc] | [prev] | [next] | [standalone]

#38277

On 17/04/15 16:56, Paul Rubin wrote:
> albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>> Not correct. The PATH for finding executables is fully under control.
>> It is urban legend that there is a security leak by having de current
>> directory in the PATH. ("someone could have sneaked an ls in your directory
>> that installs a rootkit.")
> 
> No it wasn't an urban legend, it was a real issue.  In the old days "."
> was the first thing on the path and there were actual incidents of what
> you described.  E.g. you'd be a sysadmin of some university timesharing
> system, you'd get told that some student had porn in his home directory,
> you'd cd to the directory and type "ls" as root, and hilarity ensues.  I
> think there is a paper by Fred Grampp about this, that introduced the
> practice of getting "." off of the standard path.
> 
>> This is nonsensical for normal users.
> 
> I'd say it's still not nonsensical: you unpack an archive, cd to it and
> type "ls", same situation.  Or even in non-malicious cases, someone
> might have chosen a program name that wasn't a standard Unix command,
> but that happened to match something that you used and was on your path.
> Like I think there are at least 2 different Forth implementations called
> pforth.  So maybe you use one of them and the directory you cd to has
> the other one, so you type "pforth" and get the wrong one, etc.
> 

And while it is true that when running under a standard user, you cannot
easily install a rootkit (the malicious program would have to persuade
you to do a "sudo" or similar), you can make a real mess without that.

Albert, try putting this in a file called "ls", with the executable flag
set:

#!/bin/bash
rm -rf ~/

[toc] | [prev] | [next] | [standalone]

#38284

In comp.arch.embedded Paul Rubin <no.email@nospam.invalid> wrote:
> albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>> Not correct. The PATH for finding executables is fully under control.
>> It is urban legend that there is a security leak by having de current
>> directory in the PATH. ("someone could have sneaked an ls in your directory
>> that installs a rootkit.")
 
> No it wasn't an urban legend, it was a real issue.  In the old days "."
> was the first thing on the path and there were actual incidents of what
> you described.  E.g. you'd be a sysadmin of some university timesharing
> system, you'd get told that some student had porn in his home directory,
> you'd cd to the directory and type "ls" as root, and hilarity ensues.  I
> think there is a paper by Fred Grampp about this, that introduced the
> practice of getting "." off of the standard path.

OK, so at least you should put the . at the end of the path.
That will still surprise you if you name your program the same
as a system program, though.
 
>> This is nonsensical for normal users.
 
> I'd say it's still not nonsensical: you unpack an archive, cd to it and
> type "ls", same situation.  Or even in non-malicious cases, someone
> might have chosen a program name that wasn't a standard Unix command,
> but that happened to match something that you used and was on your path.
> Like I think there are at least 2 different Forth implementations called
> pforth.  So maybe you use one of them and the directory you cd to has
> the other one, so you type "pforth" and get the wrong one, etc.

By now, I have gotten used to putting ./ in front of names. 
Especially interesting is:

./!$

for ordinary users on systems with no public users, and who don't
download files without looking at the names, . at the end should
be safe enough. For root, it probably isn't safe enough.

As far as I know, MSDOS and its successor, Windows, have an
implied . at the beginning of the path.

-- glen

[toc] | [prev] | [next] | [standalone]

#38273

On 2015-04-17, rickman <gnuarm@gmail.com> wrote:
> On 4/16/2015 6:11 PM, Paul Rubin wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> compile, but I can't seem to figure out how to run it.  I type
>>> lm4flash at the command line, but it says "command not found".  The
>>> file has no visible extension.  Is that expected?  What am I missing?
>>
>> Try ./lm4flash
>
> Yes, I figured that out.  It seems the current working directory is not 
> considered under Linux for finding executables... really!?

Why would it be? Most of the directories where binaries are stored are
called bin or sbin. For example

/bin
/sbin
/usr/bin
/usr/sbin
/usr/local/bin
/usr/local/sbin

It is really not appropriate or orderly to have binaries in your home
directory. The home directory is the top level directory for each user. It
is expected to contain other directories in an organized manner. If you want
to make a directory for binaries the normal way to do that is

mkdir ~/bin              # one time only
export PATH=$PATH:~/bin  # this goes in your logon proc depending on shell

Blajrs

[toc] | [prev] | [next] | [standalone]

#38276

Blajrs Jrolrsen <boegre@no.com> writes:
>On 2015-04-17, rickman <gnuarm@gmail.com> wrote:
>> Yes, I figured that out.  It seems the current working directory is not 
>> considered under Linux for finding executables... really!?
...
>It is really not appropriate or orderly to have binaries in your home
>directory. The home directory is the top level directory for each user. It
>is expected to contain other directories in an organized manner. If you want
>to make a directory for binaries the normal way to do that is

The home directory was not the issue here, the current working
directory was.

I think it has something to do with more usage of Unix/Linux by
non-programmers (to such an extent that they don't even write their
own shell scripts).  They don't benefit from "." in the PATH at all,
so it was removed from the default.  Programmers know how to add it
back.

In the old times, we had "." first in the PATH.  If I am working on a
new version of Gforth, and am in the build directory of Gforth, then
saying "gforth" gives me the development version, not the installed
version.

That had a security disadvantage: If an attacker can get you to unpack
a package, and that package contains, say, an executable "ls", then,
if you are in the directory containing that executable and try to list
the files, you will execute the attacker's executable.

That disadvantage was worked around by removing the "." from the front
and putting it on the back of the PATH.  This allows programmers to
call their programs in the current directory without "./", unless a
version of that program has been installed in another directory in the
PATH.  I guess that, if you have that, you may start to use "./" a
lot, so then you can eliminate "." from the PATH completely.

- 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
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#38304

Am 17.04.2015 um 16:42 schrieb Anton Ertl:
> Blajrs Jrolrsen <boegre@no.com> writes:
>> On 2015-04-17, rickman <gnuarm@gmail.com> wrote:
>>> Yes, I figured that out.  It seems the current working directory is not
>>> considered under Linux for finding executables... really!?

Yes, really.

> I think it has something to do with more usage of Unix/Linux by
> non-programmers (to such an extent that they don't even write their
> own shell scripts).

I don't think that argument works.

There have been platforms where a very large fraction of users never 
wrote a program of their own.  The biggest of those has to be Microsoft 
Windows, closely followed by MacOS.

But Unix never was anywhere near the top of that category.  I'm not 
aware of any system that encouraged users to write their own programs 
more strongly than Unix did: the whole "toolkit" paradigm almost forced 
_users_ to become programmers, at least at the shell script level.  And 
how many other systems did come with a bona-fide HLL compiler right 
there in the box?

> In the old times, we had "." first in the PATH.  If I am working on a
> new version of Gforth, and am in the build directory of Gforth, then
> saying "gforth" gives me the development version, not the installed
> version.

And that was baskk-ackward.  If only because it's a whole lot easier to
and type the "./" prefix for the exceptional case of wanting something
else than the normal instance of a command, than it would be to figure
out where the "official" one might be, and type the full path to there 
every time you want to be sure you get that.

The distinction between "gforth" and "./gforth" is way easier to handle 
than the one between "/opt/swserver/Forth/GForth/V5/patch1/bin/gforth" 
and "gforth".

> That disadvantage was worked around by removing the "." from the front
> and putting it on the back of the PATH.

That workaround would be half-assed at best, because it relies on the 
obviously flawed assumption that user will never mis-type commands.  But 
because they do, it's relatively easy for an attacker to pre-load their 
traps with lots of mis-typed versions of, 'ls', 'cd', etc.

One other rather important aspect is that the way Unix does it actually
leaves you a _choice_ how you want this handled: _you_ define your $PATH
setting, so you can put '.' in there exactly where you want or need it,
or not at all. On Microsoft platforms, you have no control over it: the 
system forces an implied '.' to the front of your PATH, whether you want 
it or not.

[toc] | [prev] | [next] | [standalone]

#38307

On 4/17/2015 6:25 PM, Hans-Bernhard Bröker wrote:
> Am 17.04.2015 um 16:42 schrieb Anton Ertl:
>> Blajrs Jrolrsen <boegre@no.com> writes:
>>> On 2015-04-17, rickman <gnuarm@gmail.com> wrote:
>>>> Yes, I figured that out.  It seems the current working directory is not
>>>> considered under Linux for finding executables... really!?
>
> Yes, really.
>
>> I think it has something to do with more usage of Unix/Linux by
>> non-programmers (to such an extent that they don't even write their
>> own shell scripts).
>
> I don't think that argument works.
>
> There have been platforms where a very large fraction of users never
> wrote a program of their own.  The biggest of those has to be Microsoft
> Windows, closely followed by MacOS.
>
> But Unix never was anywhere near the top of that category.  I'm not
> aware of any system that encouraged users to write their own programs
> more strongly than Unix did: the whole "toolkit" paradigm almost forced
> _users_ to become programmers, at least at the shell script level.  And
> how many other systems did come with a bona-fide HLL compiler right
> there in the box?
>
>> In the old times, we had "." first in the PATH.  If I am working on a
>> new version of Gforth, and am in the build directory of Gforth, then
>> saying "gforth" gives me the development version, not the installed
>> version.
>
> And that was baskk-ackward.  If only because it's a whole lot easier to
> and type the "./" prefix for the exceptional case of wanting something
> else than the normal instance of a command, than it would be to figure
> out where the "official" one might be, and type the full path to there
> every time you want to be sure you get that.
>
> The distinction between "gforth" and "./gforth" is way easier to handle
> than the one between "/opt/swserver/Forth/GForth/V5/patch1/bin/gforth"
> and "gforth".
>
>> That disadvantage was worked around by removing the "." from the front
>> and putting it on the back of the PATH.
>
> That workaround would be half-assed at best, because it relies on the
> obviously flawed assumption that user will never mis-type commands.  But
> because they do, it's relatively easy for an attacker to pre-load their
> traps with lots of mis-typed versions of, 'ls', 'cd', etc.
>
> One other rather important aspect is that the way Unix does it actually
> leaves you a _choice_ how you want this handled: _you_ define your $PATH
> setting, so you can put '.' in there exactly where you want or need it,
> or not at all. On Microsoft platforms, you have no control over it: the
> system forces an implied '.' to the front of your PATH, whether you want
> it or not.

I don't wish to insult anyone.  But I will say that I have tried to 
learn linux several times and found poor support from the linux 
community.  Mostly I think there is an attitude that "we" (the linux 
community) got it *right*, when there are many, many more PC users, even 
professional programmers, than there are working under Linux.

Ok, everyone is entitled to their opinion.  But the problem arises when 
it is not understood that this is an opinion, not a universal truth. 
There are good and bad things about both linux and windows.  I would 
like to learn about linux now, so I won't ask "why" anymore.  I'll just 
accept the things that are goofy about it just as I have done with 
windows for many years.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#38308

rickman <gnuarm@gmail.com> writes:
> Mostly I think there is an attitude that "we" (the linux
> community) got it *right*, when there are many, many more PC users,
> even professional programmers, than there are working under Linux.

Linux has its roots in Unix which goes back to the 1970's, long before
the existence of PC's, so it tends to use old-school approaches:

http://2ndscale.com/rtomayko/2006/that-dilbert-cartoon

[toc] | [prev] | [next] | [standalone]

#38311

On 4/17/2015 8:14 PM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> Mostly I think there is an attitude that "we" (the linux
>> community) got it *right*, when there are many, many more PC users,
>> even professional programmers, than there are working under Linux.
>
> Linux has its roots in Unix which goes back to the 1970's, long before
> the existence of PC's, so it tends to use old-school approaches:
>
> http://2ndscale.com/rtomayko/2006/that-dilbert-cartoon

I'm going to get the better computer, but it costs $35.  The rPi 2... 
This thing is not much of a desktop.  I have a 10 year old machine that 
runs XP and does rings around the rPi.  But then it has it's own table, 
burns enough power to warm a cat very nicely while the rPi serves as a 
night light and sits on top of my monitor... lol

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#38312

rickman <gnuarm@gmail.com> writes:
> I'm going to get the better computer, but it costs $35.  The rPi
> 2... This thing is not much of a desktop.  I have a 10 year old
> machine that runs XP and does rings around the rPi.  

The Rpi is an embedded linux board that I hope is not being sold as a
desktop.  The Rpi2 has four cores each around 1.5x the speed of the
Rpi1, and I don't know if the parallelism will really help with web
browsing.  I can understand not wanting to lug a full sized laptop
around but there are some very nice, fast ultralights around these days.
I want one of these:

http://www.dell.com/us/business/p/xps-13-linux/pd.aspx

Ironically one of the easiest places to go look at one in person is the
Microsoft store.  But I'd buy the Linux version above.

[toc] | [prev] | [next] | [standalone]

#38314

On 4/17/2015 8:32 PM, Paul Rubin wrote:
> rickman <gnuarm@gmail.com> writes:
>> I'm going to get the better computer, but it costs $35.  The rPi
>> 2... This thing is not much of a desktop.  I have a 10 year old
>> machine that runs XP and does rings around the rPi.
>
> The Rpi is an embedded linux board that I hope is not being sold as a
> desktop.  The Rpi2 has four cores each around 1.5x the speed of the
> Rpi1, and I don't know if the parallelism will really help with web
> browsing.  I can understand not wanting to lug a full sized laptop
> around but there are some very nice, fast ultralights around these days.
> I want one of these:
>
> http://www.dell.com/us/business/p/xps-13-linux/pd.aspx
>
> Ironically one of the easiest places to go look at one in person is the
> Microsoft store.  But I'd buy the Linux version above.

My problem isn't the size of the laptop exactly.  It is the smallness of 
the space available, lol.  I can't use such small machines really.  In 
fact one of my complaints of this 17" laptop is they didn't use all the 
space available for the keyboard so there is no space between the key 
sections.  It is impossible to feel for any keys like the arrows or the 
Home, End, PgUp, PgDn keys.  You have to look every time you reach for 
one.   Then the rPi is tiny, but the 19" monitor is not and the compact 
Dell keyboard is wider than the 17" laptop, along with all the tools, 
drawers, lamps, outlet strips and misc junk on the relatively small 
table top.  If I put the laptop where the keyboard is I have to lay the 
keyboard behind it... I could bring another table in just for the 
laptop.  Or I could admit I am never going to fire up the XP computer 
again and use that tray.

But for the short term, I'm just looking for a way to talk to the 
launchpad from the rPi.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#38330

In article <87oammuvhe.fsf@jester.gateway.pace.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>rickman <gnuarm@gmail.com> writes:
>> I'm going to get the better computer, but it costs $35.  The rPi
>> 2... This thing is not much of a desktop.  I have a 10 year old
>> machine that runs XP and does rings around the rPi.
>
>The Rpi is an embedded linux board that I hope is not being sold as a
>desktop.  The Rpi2 has four cores each around 1.5x the speed of the
>Rpi1, and I don't know if the parallelism will really help with web
>browsing.  I can understand not wanting to lug a full sized laptop
>around but there are some very nice, fast ultralights around these days.
>I want one of these:
>http://www.dell.com/us/business/p/xps-13-linux/pd.aspx

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.

>
>
>Ironically one of the easiest places to go look at one in person is the
>Microsoft store.  But I'd buy the Linux version above.

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.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#38346

On 4/18/2015 4:47 AM, Albert van der Horst wrote:
> In article <87oammuvhe.fsf@jester.gateway.pace.com>,
> Paul Rubin  <no.email@nospam.invalid> wrote:
>> rickman <gnuarm@gmail.com> writes:
>>> I'm going to get the better computer, but it costs $35.  The rPi
>>> 2... This thing is not much of a desktop.  I have a 10 year old
>>> machine that runs XP and does rings around the rPi.
>>
>> The Rpi is an embedded linux board that I hope is not being sold as a
>> desktop.  The Rpi2 has four cores each around 1.5x the speed of the
>> Rpi1, and I don't know if the parallelism will really help with web
>> browsing.  I can understand not wanting to lug a full sized laptop
>> around but there are some very nice, fast ultralights around these days.
>> I want one of these:
>> http://www.dell.com/us/business/p/xps-13-linux/pd.aspx
>
> 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.
>
>>
>>
>> Ironically one of the easiest places to go look at one in person is the
>> Microsoft store.  But I'd buy the Linux version above.
>
> I've much more sbc's in store than I can get acquainted with in my
> lifetime ...

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

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.lang.forth

csiph-web