Mecrisp on the TI Stellaris Launchpad

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.

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.

Bingo.

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.

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

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

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

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

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

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.

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

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

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

Which one still has "typical development environment"?

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

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.

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/

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

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 l m4flash thing.. just grab the source off of sourceforge or github or wherev er 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 ri ght 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 po p up boxes, where as minicom requires you to use a bunch of shortcut keys t o 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 sy ntax highlighting and some other helpful features. Not the most full-featur ed, but at least it doesn't make you do keyboard commands to navigate throu gh different modes to get things done.

Getting the software tools you need on a Linux environment isn't all that b ad, most of the time it's a matter of seeing if it's in the repositories, m aybe adding a new repository to your sources list, or as a last resort down loading the source and installing. On something like Raspberry Pi the remai ning issue is whether or not the software you want actually supports ARM, b ut with so many platforms being ARM based, I think that will continue to be less of an issue as time moves forward.

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

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

------------------------------------------------------

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

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

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

Not sure what this means.

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.

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

BTW, I am running Raspian out of the box. The whole rPi thing was given to me by a friend who got it from work when they decided it wasn't useful for them.

Even if I don't use it for this project, I plan to return to the rPi and Linux on some other project. It can't really be all that hard to learn.

--

Rick

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

I don't know gtkterm, but the 'canonical' package people often talk about is minicom (not miniterm as you mentioned). However it has an annoying 'curses' (DOS-style) GUI - I prefer picocom because it doesn't have menus on obscure keypresses to configure it, you just tell it the serial device on the command line and away you go: picocom -b 115200 /dev/ttyUSB0

So do that then ;-)

sudo apt-get install tin NNTPSERVER=nntp.aioe.org tin -r

then hit shift-S and type the name of a newsgroup you want to subscribe to. Navigate with the arrow keys. You can of course set it up with your newsserver and name etc (look in ~/.tin/), but the above should work directly.

'Other newsreaders are available', as they say.

The default username is 'pi' and the password 'raspberry'.

You don't need a terminal emulator as such - the window that displays your session is already a terminal emulator. If it's on the Pi display then that could be a program like xterm or gnome-terminal, if you're using SSH then it could be a Windows program like PuTTY. That provides the terminal-to-pixels conversion, and then all you need to do is ensure that character stream that reaches it is in the right format. Typically this is done by propagating a TERM environment variable around (which SSH will do for you but picocom won't), for example TERM=vt100, so as long as whatever is outputting text know it's aiming for a vt100 it'll generate the right characters for PuTTY or whatever, even if they pass through three machines on the way.

Anyway, for simple stuff you probably don't need to tell your heating controller or whatever to output vt100 codes - ASCII works just fine, the terminal settings only matter for things like cursor movement and graphics.

So all you need is a program to display the traffic on the serial port - picocom or minicom will do, but they aren't 'terminal emulators' as such.

Theo