Mecrisp on the TI Stellaris Launchpad

On 18/04/15 22:11, Dimiter_Popoff wrote:
>
> 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.
>

I think this is entirely up to the app.  Input events get put in a 
queue, normally handled by the main thread (as is common on most gui 
systems AFAIK).  If the app keeps the main thread too busy to see the 
events for a while, you get delays.

On 19.4.2015 г. 22:32, David Brown wrote:
> On 18/04/15 22:11, Dimiter_Popoff wrote:
>>
>> 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.
>>
>
> I think this is entirely up to the app.  Input events get put in a
> queue, normally handled by the main thread (as is common on most gui
> systems AFAIK).  If the app keeps the main thread too busy to see the
> events for a while, you get delays.
>

It may be down to some app but it applies to all apps (i.e. there is
no scenario where if one browser window gets stuck you can switch
and talk to some other task, everything stays stuck for a very long
time). Then if an app is allowed to block the system task doing user
I/O this is a very poorly organized system (which it is, it becomes
obvious immediately when one touches it - but it is good to have it
in ones pocket nonetheless, better than nothing anyway).

Dimiter

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

On 19/04/15 12:22, Dimiter_Popoff wrote:
> 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
>

Other than that, the only difference I see between the lines in my and 
Rick's posts, and Rod's posts, is that Thunderbird has spaces at the end 
of the lines, while Rod's do not.  (Nor do yourrs, Dimiter.)  I suspect 
that Thunderbird uses these spaces to identify wrapped paragraphs, which 
it can then re-wrap to the window width for display in Thunderbird (but 
not for posting).

It could also be that there is a difference in the line ending 
characters, but it would surprise me if a Usenet client is fussy about 
the line endings it accepts.

On 4/18/2015 12:21 PM, Niklas Holsti wrote:
> On 15-04-18 16:32 , rickman wrote:
>
>> But that doesn't explain the issue I have where quoted text in the
>> window for composing messages often is not wrapped and runs off the edge
>> of the window.
>
> That occasionally happens with Thunderbird for me, too.
>
>> Any idea what causes that?
>
> No, I don't.
>
>> It makes it very hard to see what I am replying to.
>
> Yes. But there is a useful menu command Edit->Rewrap which wraps the
> quoted text.

Thanks, that will make me happier.

-- 

Rick

On 4/18/2015 12:06 PM, mm0fmf wrote:
> On 17/04/2015 22:02, rickman wrote:
>> I was commenting on the facts that there is a quarter volt lost across
>> the rPi
>
> It doesn't matter how much "is lost" because the final voltage is within
> spec.

You are confused.  The only reason why the output voltage is in spec is 
because the input voltage is well above the nominal voltage required on 
the input.  With another power module the output voltage would be 
outside of spec and even now, the output is not able to supply much 
current.  Connect a device that draws more current and the voltage sags 
more.

This is not so much about the USB spec as it is the design of the rPi 
which creates a lot of voltage drop on what should be very nearly a wire 
with nominal resistance.


> I don't know about the hub and PHY on the Pi, but all the PHYs we
> produce have the ability to disable VBUS on each port and can signal
> over current conditions. When a device pulls too much current you signal
> the USB MAC and it tells the PHY to kill VBUS. The missing volts will be
> loss in the PHY VBUS switch most likely.

Such a switch would typically have a resistance of low mOhms and create 
a correspondingly low voltage drop... much less than the 0.25 volts we 
are seeing in the rPi.


> I don't work with our PHYs directly but only with the USB MACs we
> produce so I can't recall off the top of my head if the over current is
> as programmable as the current the device claims during enumeration.
> Devices specify their max current requirements in multiples of 2mA
> units. Before enumeration, the spec allows 100mA and I'm fairly sure our
> PHYs will signal over current if something tries to draw much more than
> 100mA. Once enumerated, again I'm fairly sure the over current level is
> programmable.
>
>> and that the launchpad seems to reset when I type on the USB
>> keyboard.
>
> If the launchpad lies during enumeration then this can happen. It's not
> helped by the early Pi hardware being a bit more than flakey.

Bingo.


>>  Maybe it's not voltage related, but the quarter volt drop is
>> unexpected
>
> Not when you know there are switches between the power rail and VBUS as
> previously stated.

The rPi does not have switches in the power path I believe.  But if it 
does, they should be designed for a much lower voltage drop than a 
quarter volt, hence the problem.


>> and there are plenty of cases where even an older mouse, like
>> the one I have, can't be powered through the rPi.
>
> I have lots of devices that work perfectly with a Pi as long as they are
> connected before the Pi (model B, 512M) is booted. Plugging them in once
> booted normally results in a crash. Which is a shame as USB is designed
> to be hot-pluggable.
>
> I should really say that I am shocked, nay stunned to find that a �30
> single board PC which can be battery powered that runs Linux and
> provides a metric shit-load of IO in addition to Ethernet and USB has a
> number of gotchas and issues. ;-)

I find your description of the rPi to be interesting.  Battery powered 
is a bit tongue in cheek as this level device is on par with phones and 
tablets which can't be away from a power plug for hours rather than 
days.  I think of "battery powered" as describing equipment that can be 
left unattended for many days without an external power source.  But 
whatever, one man's battery is another man's RTG.  lol

Enjoy

-- 

Rick

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

On 4/18/2015 11:52 AM, Albert van der Horst wrote:
> In article <mgtsk2$v6j$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>> On 4/18/2015 4:47 AM, Albert van der Horst wrote:
> <SNIP>
>>
>> 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.
>
> I think the documentation of noforth is quite formidable. Not only the
> examples, the system itself and the way to make turnkey systems, but also
> the metacompiler, which is somewhat rarer.
> We (Dutch Forth chapter) are in the process of helping the authors
> to make the system somewhat easier to find, (probably BitBucket)
> and the authors have GPL-ed it, such that the copyright status is clear.
>
> It is mature, as the example I gave was three year ago, and quite some
> improvements have been made, in particular the number of boards that
> are supported. But sorry, it is MPS430 only.

That's one of the things I like about Mecrisp, it is on two families, 
MSP430 and ARM CMx and lots of boards supported.  I'll keep note of 
noforth.

-- 

Rick

On 4/18/2015 12:42 PM, Paul Rubin wrote:
> David Brown <david.brown@hesbynett.no> writes:
>>> I'm still amazed at how slow computers have gotten as the CPUs have
>>> gotten faster.  The rPi is no exception.  It is many times faster and
>>> has much more memory than the machine I first got on the Internet
>>> with.  But I guess browsers and HTML have changed to demand more.
>
> Certainly today's web pages have ridiculous amounts of javascript on
> them.  Rick could try a simpler browser like dillo (dillo.org), that has
> no JS and is very fast, but there's lots of sites that won't work.
>
>>> That's the main reason why I want to use Forth.  It is very light
>>> weight and puts little strain on the system hosting it.
>
> Python is nowhere near as light as Forth but it works pretty well on the
> Pi, from what I hear.  I used it on a much less powerful board than the
> Pi and it was great.

The rPi is not my target processor, a TI Stellaris Launchpad is.  I want 
to use the rPi as my development system.


>> "Software gets slower faster than hardware gets faster."
>> (I can't remember whose "law" that is.)
>
> I thought this was interesting:
>
> http://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf
>
> it points out that people have always dealt with unacceptably slow
> computations by limiting what they compute.  "Example: In your favorite
> sword-fighting video game, are light reflections affected realistically
> by sword vibration?"
>
> There's more abstraction and interpretation burning cpu cycles in
> today's software, but the software is also doing more for people than it
> used to.

Is it really?  I mean, is it doing more *useful* stuff?  I think most 
web sites are loaded with glitz and crap and for the semiconductor 
makers the sites are just noise.  For example TI used to have an 
excellent site, clearly organized with a lot of input from the 
engineering staff or customers.  Now it is full of glitz and advertising 
so that it is hard to find what you want in a way that makes it all easy 
and clear.  The result is pages that run slowly and are hard to even 
scroll.

-- 

Rick

In message <mh14qa$u9a$1@dont-email.me>
          rickman <gnuarm@gmail.com> wrote:

> On 4/18/2015 12:06 PM, mm0fmf wrote:
>> On 17/04/2015 22:02, rickman wrote:
>>> I was commenting on the facts that there is a quarter volt lost across
>>> the rPi
>>
>> It doesn't matter how much "is lost" because the final voltage is within
>> spec.

> You are confused.  The only reason why the output voltage is in spec is
> because the input voltage is well above the nominal voltage required on
> the input.  With another power module the output voltage would be
> outside of spec and even now, the output is not able to supply much
> current.  Connect a device that draws more current and the voltage sags
> more.

> This is not so much about the USB spec as it is the design of the rPi
> which creates a lot of voltage drop on what should be very nearly a wire
> with nominal resistance.

and to make it worse, and fluctuations in the current drawn will 
produce fluctuations in the voltage. Checking with an oscilloscope is 
the only realistic way to see whether this is affecting the problem.

>> I don't know about the hub and PHY on the Pi, but all the PHYs we
>> produce have the ability to disable VBUS on each port and can signal
>> over current conditions. When a device pulls too much current you signal
>> the USB MAC and it tells the PHY to kill VBUS. The missing volts will be
>> loss in the PHY VBUS switch most likely.

> Such a switch would typically have a resistance of low mOhms and create
> a correspondingly low voltage drop... much less than the 0.25 volts we
> are seeing in the rPi.


>> I don't work with our PHYs directly but only with the USB MACs we
>> produce so I can't recall off the top of my head if the over current is
>> as programmable as the current the device claims during enumeration.
>> Devices specify their max current requirements in multiples of 2mA
>> units. Before enumeration, the spec allows 100mA and I'm fairly sure our
>> PHYs will signal over current if something tries to draw much more than
>> 100mA. Once enumerated, again I'm fairly sure the over current level is
>> programmable.
>>
>>> and that the launchpad seems to reset when I type on the USB
>>> keyboard.
>>
>> If the launchpad lies during enumeration then this can happen. It's not
>> helped by the early Pi hardware being a bit more than flakey.

> Bingo.


>>>  Maybe it's not voltage related, but the quarter volt drop is
>>> unexpected
>>
>> Not when you know there are switches between the power rail and VBUS as
>> previously stated.

> The rPi does not have switches in the power path I believe.  But if it
> does, they should be designed for a much lower voltage drop than a
> quarter volt, hence the problem.


>>> and there are plenty of cases where even an older mouse, like
>>> the one I have, can't be powered through the rPi.
>>
>> I have lots of devices that work perfectly with a Pi as long as they are
>> connected before the Pi (model B, 512M) is booted. Plugging them in once
>> booted normally results in a crash. Which is a shame as USB is designed
>> to be hot-pluggable.
>>
>> I should really say that I am shocked, nay stunned to find that a &#4294967295;30
>> single board PC which can be battery powered that runs Linux and
>> provides a metric shit-load of IO in addition to Ethernet and USB has a
>> number of gotchas and issues. ;-)

> I find your description of the rPi to be interesting.  Battery powered
> is a bit tongue in cheek as this level device is on par with phones and
> tablets which can't be away from a power plug for hours rather than
> days.  I think of "battery powered" as describing equipment that can be
> left unattended for many days without an external power source.  But
> whatever, one man's battery is another man's RTG.  lol

> Enjoy



-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

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