David Brown <david.brown@hesbynett.no> writes:>On 18/04/15 15:08, Anton Ertl wrote: >> David Brown <david.brown@hesbynett.no> writes: >> 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.187KB, and it does not even have Emacs or vi key bindings. I wonder what it is doing with all that space, but it's certainly nothing I use. Looking at the popularity-contest results, some form of vi seems to be installed more often than nano (it seems that there are people who uninstall nano), so Debian could install vi in the first place. Anyway, not installing a programmer's editor and installing nano instead supports my claim that they do not target programmers. name inst vote old recent no-files (maintainer) nano 170116 32133 119241 18640 102 (Jordi Mallach) vim-common 174062 59805 87555 26616 86 (Debian Vim Mai vim 67701 23297 36271 8105 28 (Debian Vim Mai vim-tiny 169261 13839 120285 35040 97 (Debian Vim Mai emacsen-common 54751 10282 37601 6821 47 (Rob Browning) emacs23-bin-common 16067 5231 10516 312 8 (Rob Browning) emacs23 13261 4400 8585 271 5 (Rob Browning) emacs24-bin-common 6512 3233 2460 819 0 (Rob Browning) emacs24 5696 2811 2135 750 0 (Rob Browning) emacs24-common 6521 1526 3820 1166 9 (Rob Browning) emacs23-common 16092 1392 14170 497 33 (Rob Browning) eclipse-platform-data 7092 1840 3736 1511 5 (Debian Orbital eclipse-rcp 7249 1700 4112 1429 8 (Debian Orbital eclipse-platform 6962 1628 3914 1414 6 (Debian Orbital eclipse-jdt 6903 1185 5290 369 59 (Debian Orbital eclipse-pde 6859 1184 5292 368 15 (Debian Orbital>> 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).Which one still has "typical development environment"?>>>> 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./opt users are victims of their software providers. Concerning the characterization of the programmers, I stand by that; ok, it could also be incompetence. If a programmer does not provide a "make install" or at least an install script that installs the binaries or links to the binaries in a directory that is in the usual path of users (such as /usr/local/bin), but instead says in the README that the sysadmin should create such links manually, or that the users should put the /opt/.../bin directory in the PATH, no friendly characterization comes to my mind.>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).So the example you gave of using "gforth" to call "/opt/swserver/Forth/GForth/V5/patch1/bin/gforth" would not even work for your setup.>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.I see no advantage over using /usr/local. Upgrading: Get the new version of the software, do "make install". Ideally the software installs itself with version numbers, so you can also call old versions. Moving to a new system: Just copy /usr/local to the new system (or somesuch; you could also install the new system on a new partition, and mount the /usr/local there). - 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/
Mecrisp on the TI Stellaris Launchpad
Started by ●April 2, 2015
Reply by ●April 20, 20152015-04-20
Reply by ●April 20, 20152015-04-20
On 19/04/2015 21:57, rickman wrote:> > The rPi does not have switches in the power path I believe.Dear rickman, having studied many of your posts I have come to the conlusion that you don't read what people write and have significantly less comprehension regarding hardware and software in reality than you believe you have. And so, given I have fewer tomorrows than yesterdays, I shall let you stew in your own piss from now on rather than trying to help you. *plink*
Reply by ●April 21, 20152015-04-21
On 4/20/2015 1:03 PM, mm0fmf wrote:> On 19/04/2015 21:57, rickman wrote: >> >> The rPi does not have switches in the power path I believe. > > Dear rickman, having studied many of your posts I have come to the > conlusion that you don't read what people write and have significantly > less comprehension regarding hardware and software in reality than you > believe you have. > > And so, given I have fewer tomorrows than yesterdays, I shall let you > stew in your own piss from now on rather than trying to help you. > > *plink*No need to have a pissing contest with anyone, but I don't actually recall your posts attempting to be helpful. Rather you tried to tell me the voltage on the USB ports were "in spec" when that was not the issue being discussed. plonk yourself, lol -- Rick
Reply by ●April 21, 20152015-04-21
On Sunday, April 19, 2015 at 2:04:31 PM UTC-7, 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. > > -- > > RickRick, if you're using Debian or Ubuntu on the pi then you should be able to install minicom with apt-get install out of the box. Otherwise I think it can pretty easily be installed from source in exactly the same way as the lm4flash thing.. just grab the source off of sourceforge or github or wherever it's being hosted, type "make", and maybe "make install" if the Makefile has that option, and it will copy the executable and man files into the right path. However if you're using the monitor/keyboard/mouse on the pi, then I might recommend gtkterm instead as it has a graphical menu with drop-downs and pop up boxes, where as minicom requires you to use a bunch of shortcut keys to tweak the settings.. once again apt-get install should do the job. Similarly I like gedit as a text editor, it's a bit notepad-like but has syntax highlighting and some other helpful features. Not the most full-featured, but at least it doesn't make you do keyboard commands to navigate through different modes to get things done. Getting the software tools you need on a Linux environment isn't all that bad, most of the time it's a matter of seeing if it's in the repositories, maybe adding a new repository to your sources list, or as a last resort downloading the source and installing. On something like Raspberry Pi the remaining issue is whether or not the software you want actually supports ARM, but with so many platforms being ARM based, I think that will continue to be less of an issue as time moves forward.
Reply by ●April 22, 20152015-04-22
On 4/20/2015 6:24 AM, Tauno Voipio wrote:> On 20.4.15 00:04, rickman wrote: >> On 4/18/2015 3:22 PM, Stephen Pelc wrote: >>> On Fri, 17 Apr 2015 00:19:42 -0400, rickman <gnuarm@gmail.com> wrote: >>> >>>> Seems they did a poor job on power distribution on the >>>> original design. The rPi 2 model B is supposed to be better. It can >>>> also be used for real PC work... like web browsing. >>> >>> The B2 is significantly faster than the B+, even for single core >>> apps. We are using Raspbian. >>> >>>> Now I have to figure out how to get a terminal emulator working on the >>>> rPi. Can't be too hard... I just have to research it on my laptop >>>> rather than on the rPi. >>> >>> The "standard" Linux terminal program is minicom. >>> >>> You will get far less noise in responses if you post the Linux >>> questions on a Raspberry Pi group. RPi respondes seem to be much >>> nicer than the average Lunux person. Similarly, I get much better >>> Google responses when Raspberry Pi is included in the search request. >> >> Thanks. I've been trying to get minicom installed and have not figured >> it out. I have crossposted to the rpi group, but some folks don't >> crosspost their replies which is ok with me. So I am discussing this >> there as well. > > > screen is much better for direct connection. It is a bit of a > challenge to make Minicom not use any modem controls or dialing > sequences.Thanks. At this point I'm getting (or should I say *am still*) frustrated with the Stellaris Launchpad. I tried using it on my win8 pc and the drivers won't install. Seems there is much stiffer driver signature enforcement in Win8 and Win7 so that you have to disable it and reboot. I'm not sure even then that it will work. I'm looking to see if using the STM32 would be easier. If I can't get drivers installed under Windows, I can't imagine how I would get them to work under Linux. -- Rick
Reply by ●April 22, 20152015-04-22
On 22.4.2015 г. 20:23, rickman wrote:> On 4/20/2015 6:24 AM, Tauno Voipio wrote: >> On 20.4.15 00:04, rickman wrote: >>> On 4/18/2015 3:22 PM, Stephen Pelc wrote: >>>> On Fri, 17 Apr 2015 00:19:42 -0400, rickman <gnuarm@gmail.com> wrote: >>>> >>>>> Seems they did a poor job on power distribution on the >>>>> original design. The rPi 2 model B is supposed to be better. It can >>>>> also be used for real PC work... like web browsing. >>>> >>>> The B2 is significantly faster than the B+, even for single core >>>> apps. We are using Raspbian. >>>> >>>>> Now I have to figure out how to get a terminal emulator working on the >>>>> rPi. Can't be too hard... I just have to research it on my laptop >>>>> rather than on the rPi. >>>> >>>> The "standard" Linux terminal program is minicom. >>>> >>>> You will get far less noise in responses if you post the Linux >>>> questions on a Raspberry Pi group. RPi respondes seem to be much >>>> nicer than the average Lunux person. Similarly, I get much better >>>> Google responses when Raspberry Pi is included in the search request. >>> >>> Thanks. I've been trying to get minicom installed and have not figured >>> it out. I have crossposted to the rpi group, but some folks don't >>> crosspost their replies which is ok with me. So I am discussing this >>> there as well. >> >> >> screen is much better for direct connection. It is a bit of a >> challenge to make Minicom not use any modem controls or dialing >> sequences. > > Thanks. > > At this point I'm getting (or should I say *am still*) frustrated with > the Stellaris Launchpad. I tried using it on my win8 pc and the drivers > won't install. Seems there is much stiffer driver signature enforcement > in Win8 and Win7 so that you have to disable it and reboot. I'm not > sure even then that it will work. > > I'm looking to see if using the STM32 would be easier. If I can't get > drivers installed under Windows, I can't imagine how I would get them to > work under Linux. >Your experience seems to support my view that demo boards like that are useless. You will design and bring to life your end product board faster than you will make some demo toy being useful to you, i.e. all the time you spend on the latter will be wasted. Unless you want to make a product for sale (say, some piece of software) to run on exactly that, popular board, targeting people who already have it. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
Reply by ●April 22, 20152015-04-22
On 4/22/2015 1:44 PM, Dimiter_Popoff wrote:> On 22.4.2015 г. 20:23, rickman wrote: >> On 4/20/2015 6:24 AM, Tauno Voipio wrote: >>> On 20.4.15 00:04, rickman wrote: >>>> On 4/18/2015 3:22 PM, Stephen Pelc wrote: >>>>> On Fri, 17 Apr 2015 00:19:42 -0400, rickman <gnuarm@gmail.com> wrote: >>>>> >>>>>> Seems they did a poor job on power distribution on the >>>>>> original design. The rPi 2 model B is supposed to be better. It can >>>>>> also be used for real PC work... like web browsing. >>>>> >>>>> The B2 is significantly faster than the B+, even for single core >>>>> apps. We are using Raspbian. >>>>> >>>>>> Now I have to figure out how to get a terminal emulator working on >>>>>> the >>>>>> rPi. Can't be too hard... I just have to research it on my laptop >>>>>> rather than on the rPi. >>>>> >>>>> The "standard" Linux terminal program is minicom. >>>>> >>>>> You will get far less noise in responses if you post the Linux >>>>> questions on a Raspberry Pi group. RPi respondes seem to be much >>>>> nicer than the average Lunux person. Similarly, I get much better >>>>> Google responses when Raspberry Pi is included in the search request. >>>> >>>> Thanks. I've been trying to get minicom installed and have not figured >>>> it out. I have crossposted to the rpi group, but some folks don't >>>> crosspost their replies which is ok with me. So I am discussing this >>>> there as well. >>> >>> >>> screen is much better for direct connection. It is a bit of a >>> challenge to make Minicom not use any modem controls or dialing >>> sequences. >> >> Thanks. >> >> At this point I'm getting (or should I say *am still*) frustrated with >> the Stellaris Launchpad. I tried using it on my win8 pc and the drivers >> won't install. Seems there is much stiffer driver signature enforcement >> in Win8 and Win7 so that you have to disable it and reboot. I'm not >> sure even then that it will work. >> >> I'm looking to see if using the STM32 would be easier. If I can't get >> drivers installed under Windows, I can't imagine how I would get them to >> work under Linux. >> > > Your experience seems to support my view that demo boards like that > are useless. You will design and bring to life your end product > board faster than you will make some demo toy being useful to you, > i.e. all the time you spend on the latter will be wasted. > Unless you want to make a product for sale (say, some piece of > software) to run on exactly that, popular board, targeting people > who already have it.In this case the project is truly an evaluation, not of the device, but of the project itself. So the goal is not to design a board, but to demonstrate the functionality of the end product at the lowest possible cost. The problem I'm having is not with the eval board, but with the tools. TI didn't provide a decent driver for their Stellaris Launchpad. -- Rick
Reply by ●April 22, 20152015-04-22
On 4/21/2015 12:34 PM, sbattazzo@gmail.com wrote:> On Sunday, April 19, 2015 at 2:04:31 PM UTC-7, 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. >> >> -- >> >> Rick > > Rick, if you're using Debian or Ubuntu on the pi then you should be able to install minicom with apt-get install out of the box. Otherwise I think it can pretty easily be installed from source in exactly the same way as the lm4flash thing.. just grab the source off of sourceforge or github or wherever it's being hosted, type "make", and maybe "make install" if the Makefile has that option, and it will copy the executable and man files into the right path. > > However if you're using the monitor/keyboard/mouse on the pi, then I might recommend gtkterm instead as it has a graphical menu with drop-downs and pop up boxes, where as minicom requires you to use a bunch of shortcut keys to tweak the settings.. once again apt-get install should do the job. > Similarly I like gedit as a text editor, it's a bit notepad-like but has syntax highlighting and some other helpful features. Not the most full-featured, but at least it doesn't make you do keyboard commands to navigate through different modes to get things done. > > Getting the software tools you need on a Linux environment isn't all that bad, most of the time it's a matter of seeing if it's in the repositories, maybe adding a new repository to your sources list, or as a last resort downloading the source and installing. On something like Raspberry Pi the remaining issue is whether or not the software you want actually supports ARM, but with so many platforms being ARM based, I think that will continue to be less of an issue as time moves forward.Thanks for the advice. For now I am punting and working under Windows just to get the project moving along. But that is no greased slide either as the TI drivers for the launchpad won't install under Win 8 without some pain. So I've ordered a couple of STM Discovery board which have an ST-link on board and hopefully will just work. While I wait for delivery I will try installing the drivers and getting ready to move ahead. -- Rick
Reply by ●April 22, 20152015-04-22
In comp.lang.forth rickman <gnuarm@gmail.com> wrote:> > At this point I'm getting (or should I say *am still*) frustrated with > the Stellaris Launchpad. I tried using it on my win8 pc and the drivers > won't install. Seems there is much stiffer driver signature enforcement > in Win8 and Win7 so that you have to disable it and reboot. I'm not > sure even then that it will work. > > I'm looking to see if using the STM32 would be easier. If I can't get > drivers installed under Windows, I can't imagine how I would get them to > work under Linux. >Mistake. For demo boards most of the driver nonsense suffered by Windows users is absent on Windows. Demo boards typically have UART interface which is mostly standard and can be handled by single generic driver. And on Linux it is handled in that way: demo board and various USB-UARTS are automatically handled by builtin Linux drives. Only Windows forces you to install extra drivers. For Stellaris/Tiva Launchpad main interface is special USB endpoint. The lm4flash programs uses libusb to contact to this endpoint and flash your program. Kernel has everything needed to talk to USB bus, the rest is userland. So no driver installation. Of course, you need to have libusb and need to compile lm4tools package. Also, you need appropriate permissions. On my machine I created /etc/udev/rules.d/46-ev-board.rules and put there the followings lines: # Stellaris Launchpad SUBSYSTEM=="usb",ATTRS{idVendor}=="1cbe",ATTRS{idProduct}=="00fd",MODE:="0666" KERNEL=="ttyACM*",ATTRS{idVendor}=="1cbe",ATTRS{idProduct}=="00fd",MODE:="0666" It is lousy securitywise because is gives access to demo board to all users, but it works. Other folks posted similar setups. In another post you wrote that you figured out main trouble, that is that you need to use 'debug' USB port to connect to PC. 'device' port is the one connected to Stellaris processor and is for use of the program on demo board. The 'debug' port is debugging/programing interface and also gives an USB-UART (the other end of UART is connected to hardware UART on Stellaris processor). With that problem solved Launchpad should work without problems. FYI, I connected several Launchpads to several different Linux machines and things worked fine from the starts. To be clear: Stellaris errata looks really bad and for me beakpoints in gdb do not work. But lm4flash has no problem finding the Launchpad and programming works fine. -- Waldek Hebisch hebisch@math.uni.wroc.pl
Reply by ●April 22, 20152015-04-22
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
