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.
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
Personally, I like to save a bit of "sudo" by doing "sudo su -" first, to get a root login, and then just typing commands without the sudo stuff.
Make sure you have updated your repository lists ("apt-get update"). Then try a search ("apt-cache search gtkterm") - maybe it has a slightly different name on your distro.
Yes, but that number doesn't matter much - don't worry about it.
Use "whoami" to confirm that.
Also use "ls -l /dev/ttyUSB*" to confirm that the group you want is "dialout" - distros vary on the details.
Note that you need to log out, then log in again, in order for the new group membership to take effect.
It doesn't matter how much "is lost" because the final voltage is within spec. 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.
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.
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.
Not when you know there are switches between the power rail and VBUS as previously stated.
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.
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. ;-)
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.
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.
I thought this was interesting:
formatting link
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.
The = at the end of each line means that the message was sent using "quoted-printable" encoding, but has not been decoded correctly. This might be a problem at your end, but more likely means that along the line the descriptor which identified the encoding has been lost, replaced or mangled.
--
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/
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.
The kernel and base system are all Linux. The gui and many higher-level features are Android specific.
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.
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.
Some distros still have it (or are by their nature a "typical desktop" or "typical server", such as Linux Mint or Centos).
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.
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
The B2 is significantly faster than the B+, even for single core apps. We are using Raspbian.
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
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).
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.
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.
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.
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.
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).
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.