Mecrisp on the TI Stellaris Launchpad

On 18/04/15 14:16, Dimiter_Popoff wrote:
> On 18.4.2015 г. 13:19, Hans-Bernhard Bröker wrote:
>> Am 18.04.2015 um 02:03 schrieb rickman:
>> ....
>>  > when there are many, many more PC users, even
>>  > professional programmers, than there are working under Linux.
>>
>> That's the "trillions of flies eat shit, so that must be a good thing!"
>> fallacy.  Democracy just doesn't work to decide about technical merit.
>>
>
> Certainly true, however its implication "this is what flies do, so
> I shall not do it" is also a widespread fallacy (e.g. means you will
> not consider flying as an option).
>   Then the fallacy you point to is what most if not all of the
> pro linux/gnu arguments are based on.

That is - at best - an extraordinary exaggeration.  The number of people 
who choose Linux /because/ they don't want to do the same as most people 
(use Windows) is tiny.

There is the argument that one of the many reasons why Linux is (in 
general) more secure than Windows is that there are fewer users of 
Linux, but even that is a minor issue.

>
> Your argument (from a previous post) about the user being left to
> decide whether to have his current directory as one of his exec
> paths is quite correct.
>
> BTW, does anyone know how much unix is there within Android?

The kernel and base system are all Linux.  The gui and many higher-level 
features are Android specific.

> Its event timings and latencies are *so* pathetic I could not
> imagine the entire linux thing would have survived that long if it were
> that bad. Good thing tablet devices have become cheap enough to
> not regret much if you smash one against the wall.
>

It's the gui and user interface that causes this, and that is 
Android-specific.  Much of it is written in Java, and runs on a JVM.

On 18/04/15 15:08, Anton Ertl wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 18/04/15 11:15, Anton Ertl wrote:
>>> Anyway, Unix may have the highest proportion of programmers, but it
>>> seems that non-programmers are the primary target of the Linux
>>> distributions these days.  E.g., neither emacs nor vi nor Eclipse is
>>> installed in Debian by default.  Or look at what programming languages
>>> are installed by default.  Only those necessary for running the
>>> scripts, no others.
>>
>> Most distros install a subset of commonly used tools, and then make it
>> easy for others to be installed.  There are vast numbers of tools,
>> editors, languages, libraries, etc., commonly used by programmers - it
>> would be ridiculous to install 2GB+ of popular programming tools when
>> even most full-time programmers won't need them.  (i.e., /you/ might
>> want emacs - but someone else will want eclipse, or vim, or jedit, or
>> netbeans, or QT tools, etc.).
>
> So what?  The distro also installs stuff like nano and an inetd that
> most people don't use.

Yes, but nano is provides an essential function - a simple command-line 
editor.  And it takes about 100 KB - as compared to eclipse at about 100 
MB or so.  Eclipse is useful to many programmers (I use it myself), and 
equally it is despised by many programmers.  But the cost (in terms of 
disk space, network download, etc.) is significant for those that don't 
need it - unlike the cost of nano.

> Somehow, when I last looked (a few years ago),
> Debian installed nothing that I use, except a shell and apt-get;
> that's ok when I ask for a minimal install, but requiring 600MB for
> that alone is a bit stiff.  Anyway, in the old days distros used to
> have options that said "typical server", "typical desktop", "typical
> development environment"; I have not seen the latter option for a
> number of years.

Some distros still have it (or are by their nature a "typical desktop" 
or "typical server", such as Linux Mint or Centos).

>
> And installing hundreds of packages to get a decent environment gets
> old quick, even if each package is easy to install.
>
>>> As for /opt, I don't know where that nonsense comes from, but it
>>> certainly does not come from the original Unix.  Proper programs are
>>> installed in one of the directories that users have in the PATH by
>>> default (such as /usr/bin or /usr/local/bin) rather than somewhere in
>>> /opt (which indicates that the programmer is too lazy to make a
>>> working "make install").
>>
>> You appear to be supremely confident that your own personal usage of
>> Linux, and your own (somewhat lacking and biased) view of OS history, is
>> /the/ truth and /the/ right way to do things.
>
> Sure, comes from experience, not just with Linux, but also with other
> Unices for about 29 years.  If you want to counter my point, you could
> try explaining the benefits of /opt instead of making an ad-hominem
> attack.
>

Just a point here - if my post was an "ad-hominem attack" (which I don't 
think it was, and it was not intended to be), then so was your 
characterisation of /opt users as "lazy" and "nonsense".  So let us move 
past that.

In the beginning of unix, /usr was the place for site-specific or 
user-chosen software.  Gradually, due to the way disks and filesystems 
were often mounted, more and more of the standard or base files ended up 
in /usr.  People put their own software in /usr/local.  Then people 
started looking for a place to put software that would not interfere 
with system software (i.e., distro-provided software for Linux, in /usr) 
or software chosen, compiled and installed by users (in /usr/local). 
/opt became common as a distro-independant place to put things.

So on my systems, I have software from the likes of Atmel and Freescale 
in /opt.  This is software that came pre-compiled, and could have 
paid-for licences.  The tools are not on my path - nor should they be, 
as the compilers are specified explicitly in Makefiles as needed.  If I 
want a short-cut for starting an IDE, I put a symbolic link in ~/bin (or 
sometimes a bash wrapper).

Is it a perfect system?  No, there is no such thing.  But it works 
simply, easily and conveniently, and makes it very simple for me to 
distinguish between distro software and third-party software, and makes 
it simple for upgrading or moving to a new system.

On 2015-04-17, Mel Wilson <mwilson@the-wire.com> wrote:
> On Fri, 17 Apr 2015 20:20:30 -0400, rickman wrote:
> [ ... ]
>> Even once I get a terminal emulator running, I'm not sure how to find
>> the ID of the device I'll be talking to with it.  It is a TI launchpad
>> with a USB emulated UART.  These things are like falling off a rock in
>> the PC world... mainly because I've come up the learning curve and know
>> it.  Will miniterm have the smarts to find the one serial port on the
>> machine or do I have to figure out the ID of this USB serial port and
>> tell it?
>
> What do you mean by USB emulated UART?  When I plug one of my Sparkfun 
> FTDI boards into a Pi, it shows up to lsusb as "0403:6001 Future 
> Technology Devices International, Ltd FT232 USB-Serial (UART) IC" and 
> gets assigned to /dev/ttyUSB0.
> A different device, Arduino based, announces itself as "2341:0010 Arduino 
> SA Mega 2560 (CDC ACM)" and gets assigned as /dev/ttyACM0.  This is on a 
> stock Raspbian distribution.
> The difference between the two is apparently that the FTDI emulates a 
> UART, whereas the Arduino emulates a modem, and that's somehow recognized 
> when they're establishing the USB connection.

To expand on that:

There's a standard for accessing serial ports on the USB specifications
which is the CDC ACM specification. This is fully open and documented
and many implementations exist (I did a simple version myself as a
learning exercise a few years ago).

However, as you say, it's targetted towards modems in it's model of
operation although serial ports work just fine with it. However, the
hardware flow control signals don't get directly passed through to
the host (there's no direct handling of CTS for example).

The way people like Microchip appear to handle this (in devices like
the MCP2200) is to handle the flow control on the device itself.

FTDI (and Prolific (PL-2303)) have their own closed USB protocol
specifications for their own devices. These specifications are not
available without signing an NDA (I know; in the case of FTDI I actually
asked them about this).

There are however drivers for these manufacturers in the Linux kernel
and (as you have discovered) they show up in a different way to the
standards compliant CDC ACM devices.

As for how Linux knows the difference, the different types of USB serial
ports are encoded differently in the configuration descriptors on the
device (with the CDC ACM devices using configuration values assigned
by the USB standards).

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Den fredag den 17. april 2015 kl. 20.47.55 UTC+2 skrev rickman:
> On 4/17/2015 12:56 AM, Paul Rubin wrote:
> > rickman <gnuarm@gmail.com> writes:
> >> I was using a gadget to measure the voltage and current going into the
> >> rPi.  That side is at 5.25 volts give or take with around 400 mA of
> >> current.  I moved the meter to the launchpad and the output on the USB
> >> port is only 4.95 volts.
> >
> > I remember reading somewhere (probably adafruit.com) that you should use
> > a pretty beefy 5V power supply with the rpi especially if it's under any
> > type of load.  They actually tweak their rpi power supplies to deliver
> > 5.25 volts to compensate for some inevitable sag.
> >
> > I don't remember hearing that the USB ports themselves are out of spec
> > but it's possible.  Despite popular misconception USB ports are only
> > supposed to be able to deliver 100 mA unless they grant the client
> > "permission" to draw more (up to 500ma), through a power negotiation
> > protocol that's part of USB.  Most x86 motherboards can deliver 500 mA
> > with no problem, so lots of badly designed client devices just assume
> > the power is available, and try to draw it without bothering with the
> > protocol.  Maybe something like that is going on here.
> 
> I'm not 100% certain of this, but I believe the rPi runs input power 
> through a Polyfuse which does have some noticeable resistance and so 
> voltage droop.  I've cross-posted this to the rPi group to see if anyone 
> will confirm it.
> 
> -- 
> 
> Rick

yep, that is what I read too, they didn't consider that running a polyfuse 
at it's rated current would be a problem

I'd just short it

-Lasse

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

On 18.4.2015 г. 20:57, David Brown wrote:
> On 18/04/15 14:16, Dimiter_Popoff wrote:
>> On 18.4.2015 г. 13:19, Hans-Bernhard Bröker wrote:
>>> Am 18.04.2015 um 02:03 schrieb rickman:
>>> ....
>>>  > when there are many, many more PC users, even
>>>  > professional programmers, than there are working under Linux.
>>>
>>> That's the "trillions of flies eat shit, so that must be a good thing!"
>>> fallacy.  Democracy just doesn't work to decide about technical merit.
>>>
>>
>> Certainly true, however its implication "this is what flies do, so
>> I shall not do it" is also a widespread fallacy (e.g. means you will
>> not consider flying as an option).
>>   Then the fallacy you point to is what most if not all of the
>> pro linux/gnu arguments are based on.
>
> That is - at best - an extraordinary exaggeration.  The number of people
> who choose Linux /because/ they don't want to do the same as most people
> (use Windows) is tiny.
>
> There is the argument that one of the many reasons why Linux is (in
> general) more secure than Windows is that there are fewer users of
> Linux, but even that is a minor issue.

I was being general, I did not mean people chose linux just in order
to be different. I said only "doing something because other people
do it is no better than not doing it for this reason", no unix
etc. implied - though I can see how in this context it may have
come across this way (which was neither intended nor meant).

>>
>> Your argument (from a previous post) about the user being left to
>> decide whether to have his current directory as one of his exec
>> paths is quite correct.
>>
>> BTW, does anyone know how much unix is there within Android?
>
> The kernel and base system are all Linux.  The gui and many higher-level
> features are Android specific.
>
>> Its event timings and latencies are *so* pathetic I could not
>> imagine the entire linux thing would have survived that long if it were
>> that bad. Good thing tablet devices have become cheap enough to
>> not regret much if you smash one against the wall.
>>
>
> It's the gui and user interface that causes this, and that is
> Android-specific.  Much of it is written in Java, and runs on a JVM.
>

This must be it, the sync issues I see are mainly between user
clicks (taps)and what is tapped on - at times many seconds apart,
you tap and tap on a link and after half a minute may be the browser
hears your tapping and takes you to some other link you did not even
suspect was there let alone tap on it. What a mess, if I try to sell
something 1/10th that messy I'll never get away with it.

Dimiter

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

In article <mgtro8$reh$1@dont-email.me>,
 rickman <gnuarm@gmail.com> writes:

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

What I do for things like that is keep a small text file
with all the details I need.  Often it's a command line
that I can cut-paste when setting up a copy of the system.
(or putting the system back together)

You don't need the whole story, just enough to trigger your memory,
or contain the magic phrase that will let man or  google find it for you.
If google finds multiple pages, I often save the URL with the one
that had the answer I liked best.


-- 
These are my opinions.  I hate spam.

On Sat, 18 Apr 2015 09:32:24 -0400, rickman <gnuarm@gmail.com> wrote:
> On 4/18/2015 4:00 AM, David Brown wrote:

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

That guy may be a nut, but he's *correct* about your lines.

Your lines aren't wrapped correctly for Usenet.  This is not a Google
Group.

Your lines should hard wrap with a newline, i.e., ASCII CR LF per spec.,
at 72 characters or so.  Either your Usenet reader has a setting to do
this, or you must manually hit return before 72 characters.  I.e., on
my browser, I had to enter newlines above or it would be one single line.

In this thread, Usenet text wrapping for posts by "rickman" and by
"David Brown" are incorrect.


Rod Pemberton

-- 
Cars kill more people than guns in the U.S.
Yet, no one is trying to take away your car.

On 18/04/15 23:55, Rod Pemberton wrote:
> On Sat, 18 Apr 2015 09:32:24 -0400, rickman <gnuarm@gmail.com> wrote:
>> On 4/18/2015 4:00 AM, David Brown wrote:
>
>>> So your posts from Thunderbird are absolutely fine.
>>
>> Thanks for the info.  It's good to know this is correct.  There is one
>> nut case in the Forth group who replies to my posts with a bit of boiler
>> plate added saying my lines were not wrapped correctly and he rewrapped
>> them for me, lol.
>
> That guy may be a nut, but he's *correct* about your lines.
>
> Your lines aren't wrapped correctly for Usenet.  This is not a Google
> Group.
>
> Your lines should hard wrap with a newline, i.e., ASCII CR LF per spec.,
> at 72 characters or so.  Either your Usenet reader has a setting to do
> this, or you must manually hit return before 72 characters.  I.e., on
> my browser, I had to enter newlines above or it would be one single line.
>
> In this thread, Usenet text wrapping for posts by "rickman" and by
> "David Brown" are incorrect.
>
Thunderbird has a 'rewrap text' option that does this.


>
> Rod Pemberton
>


-- 
Everything you read in newspapers is absolutely true, except for the 
rare story of which you happen to have first-hand knowledge. &ndash; Erwin Knoll

On 19.4.2015 г. 01:55, Rod Pemberton wrote:
> On Sat, 18 Apr 2015 09:32:24 -0400, rickman <gnuarm@gmail.com> wrote:
>> On 4/18/2015 4:00 AM, David Brown wrote:
>
>>> So your posts from Thunderbird are absolutely fine.
>>
>> Thanks for the info.  It's good to know this is correct.  There is one
>> nut case in the Forth group who replies to my posts with a bit of boiler
>> plate added saying my lines were not wrapped correctly and he rewrapped
>> them for me, lol.
>
> That guy may be a nut, but he's *correct* about your lines.
>
> Your lines aren't wrapped correctly for Usenet.

Don't know about nutcase but his lines here seem quite correct to me.
I checked a few messages at a glance and examined in detail one (I think
it was his second one).
His lines are well within 72 characters. The quoted lines are left
alone; some of them are much longer than they should be but this
has been the fault of *their* poster, not Ricks. If someone has
the expectation people will edit the line length of everything
they quote.... well, this is unrealistic to say the least.

Dimiter