Being master of a Pi
MagIO2
Posts: 2,243
I want my propeller to be the master of the Raspberry Pi, meaning that the Propeller is connected to the serial interface of the Pi which still boots up to a login prompt. The propeller then can login and do whatever it wants ..
First iteration to check the connection was a shorty which forwards the traffic from PST to the Pi and from Pi to PST like so:
Both objects are standard FullDuplexSerial setup @250000 for the PST and @115200 for the Pi. But this already fails because the output shows that the propeller misses a byte here and there. Of course I could slow down the speed of the Pi's serial interface, but maybe I also want to transfer data later in the project and want to have as much speed as possible.
Questions:
Anybody did something like that with the Pi?
Does anybody know which terminal types can be used in /etc/inittab for the getty? It is set to vt100 which means some extra work to filter those sequences for setting position and color ....
I tried "man getty", but it only tells that the term parameter exists and what it means, but not which values are valid
(
Anybody has a vt100 emulation already (which runs at 115200baud).
Ideas?
First iteration to check the connection was a shorty which forwards the traffic from PST to the Pi and from Pi to PST like so:
cognew( toPi, @stacks )
cognew( fromPi, @stacks+200 )
PUB toPi | out
repeat
out := pst.rx
pitty.tx( out )
PUB fromPi | in
repeat
pst.tx( pitty.rx )
Both objects are standard FullDuplexSerial setup @250000 for the PST and @115200 for the Pi. But this already fails because the output shows that the propeller misses a byte here and there. Of course I could slow down the speed of the Pi's serial interface, but maybe I also want to transfer data later in the project and want to have as much speed as possible.
Questions:
Anybody did something like that with the Pi?
Does anybody know which terminal types can be used in /etc/inittab for the getty? It is set to vt100 which means some extra work to filter those sequences for setting position and color ....
I tried "man getty", but it only tells that the term parameter exists and what it means, but not which values are valid
(Anybody has a vt100 emulation already (which runs at 115200baud).
Ideas?
Comments
http://www.shaels.net/index.php/propterm
and from http://forums.parallax.com/showthread.php/149751-Dumb-Terminal?p=1202530&viewfull=1#post1202530
Pocket Term: http://www.brielcomputers.com/files/PTfirmware.zip
Coggyterm/PropCOMM: http://forums.parallax.com/showthrea...T100-emulation
Serial Bluetooth Helper: https://www.dropbox.com/s/mm5b663t5u...oth_Helper.zip
That`s why the propeller might need to parse responses as fast as possible.
Switching getty into a different mode not sending those special sequences starting with [ would help.
I have never done this but I think the answer to your question is in "terminfo"
vt100 is a terminal type whoes capabilities are defined in the terminfo data base.
On debian the terminfo database is a bunch of files in /usr/share/terminfo for example /usr/share/terminfo/v/vt100 which I guess is the one in use here.
So what we need is to specify a terminal type for that getty that basically has no terminal features like colours or cursor positioning etc.
Seems there is a terminal type "dumb" for really basic output.
No idea if that works as I don't see "dumb" in the terminfo files but worth a try.
Else select some basic ansi terminal type. Like "ansis". Have a look in /usr/share/terminfo/a/
What happens if you don't specify a terminal type at all? Just leave off the "vt100".
See here http://www.tldp.org/HOWTO/Text-Terminal-HOWTO-16.html
You can disable that by removing "console=ttyAMA0,115200" from /boot/cmdline.txt.
The situation is that the Propeller is a microCONTROLLER, whereas the Raspberry Pi was specifically designed with a SOC for a microCOMPUTER.
The Pi has a lot bigger system to harness. At that is ordinarily done in the Linux Kernel that is installed on the Raspberry Pi. Once you have a Linux OS or another Unix-based OS (such as Android) involved, there are a large amount of assumptions about how the microcomputer will be deployed, and just about all of the asumptions presume a human user interface inolvement for all services.
I am not clear on what you hope the Propeller to achieve with the Raspberry Pi attached (maybe to open up a communications conduit). Some tasks can have the Raspberry Pi enhance the utility of the Propeller, but other tasks might be more appropriate for just more Propellers.
This is very much about understanding that a microCOMPUTER comes with an OS that changes the whole approach to program design. So, the role that you define for the Propeller is to mimic a human super-user in Linux. It is a very powerful position, but requires precise knowledge of what you want Linux to do.
While the Pi maybe set for VT100 commuications with color and other features, the Linux Terminal really is listening and responding to ASCII for control of the Pi. I am not sure you have to bother with a more restricted configuration terminal, just restrict messaging to the Propeller.
You can have a serial communications default on the Pi selected as default, and it can have a much simpler configuration and can just send a 'prompt character' to the Propeller at startup rather that some human friendly header message. All of that is a matter of fully understanding Linux and how to configure the programs that automatically run at startup. Doing so on the Linux side would make the Propeller code simpler. Baud rates can start out slow, and later be reconfigured when higher speeds are required. A slow baud rate will be much more fault tolerant to long wires and poorer connections, ideal for bench work.
1) The Pi (or simiar) offeres a huge memory space and a lot more raw processing speed than the Prop. On top of that we get a decent file system and networking and USB. Linux allows a billion possibilities, web servers, file servers, databases and so on and so on. It can run any huge program we are likely to come up with. Not only that we can develop code on it and importantly we can develop code for the Propeller on it. propgcc and openspin run just fine on a Pi. Even Simple IDE if you want plug in that screen and keyboard. What the Pi does not have is: Lots of I/O and the possibility of real-time, microsecond by microsecond, real-word interfacing.
2) Enter the Prop. That offers a ton of I/O pins and real-time control. Just
what we need.
It does not take much imagination to see that there is an ocean of possibilities made possible by putting these two together. And that is what we are working towards making possible.
That super robot you are building could have a Pi and a Prop or two to good effect. No matter where you take it in th world you can program it because it hosts it's wn development system!
We should not presume that people don't understand the different roles these componenets play in a system.
The way to "restrict messaging to the Propeller" is to tell all programs that might be called up by the propeller not to use any escape sequences. The way to do that is to set the terminal type as we are discussing.
On the other hand you are right and I would not do it this way at all.
Rather I would write my own program for the Pi that opens the serial connection to the Pi, reads lines that come in and then passes them to the operating system to execute with a "system" call. This can be done very easily with a few lines of node.js or Python or whatever.
Basically create your own "shell". That shell program then has the ability to restrict or reinterpret any commands that come in.
Real-time programing is a bit hard to tack down -- sometimes it is deterministic, sometimes it isn't. There is 'soft' deterministic real-time and 'hard' deterministic real time.
And if I want to study programming a microcomputer, I simply study the Linux OS on whatever I choose to use. The Raspbery Pi offers a tiny low power altrnative, but the topic remains mostly Linux and what Linux has to offer.
Here we are talking about stripping out the messaging features that presume a human user interface at the Propeller end of the serial port. It is not hard to do. But most of the literature that will tell you what to tweak and where to look for changes are in Linux user groups. It is important too know which distribution of Linux you have installed on the Pi to properly manage directories.
If you really want to master the Raspberry Pi, Linux is a big part of the knowledge base.
Even the headless Linux server farms that run the internet have Superusers that monitor and manage the facilities.
____________
If the Propeller sends "ls", it will get exactly what it asked for. So, the Propeller programmer has to restrict commuications to get desired results, or the Raspberry Pi has to restrict the user that the Propeller logs in as to directories and resources that are appropriate for the Propeller.
Either way, it is a lot of Linux knowledge to resolve the issues. Here is a list of current Linux distros on the PI.
http://elinux.org/RPi_Distributions#Comparison
No harm in studing how to program a micro-controller and anything else up to a
super computer or google sized farm. Whatever you want to do. Or all of them.
"Real-time programing" is really easy to tack down:
1) You have computings task to do.
2) You have a time deadline by which those tasks have to be done.
3) If you ever miss the deadline you have failed.
So what is that?
If I'm predicting the weather for tomorrow, we are down to hours. If my forcast comes out the next day it's pretty pointless. Weather prediction is a real-time task. I'm going to need some big machines to do it.
If I'm controlling a car engine I had better make all my measurements, calculate the required outputs and hit those fuel injectors as fast as the engine requires. We are down to sub milliseconds here. Time to get an micro-controller.
If I'm bit banging a serila protocol at 115200 or more baud we are down to microsecnds or less here. Perhaps dedicated hardware would be a better solution. No it won't. ls and many other programs adapt their output to the terminal type they think they are connected to. The terminal type is told to them by the terminfo database. The terminal type is specified to the getty program when you start it.
In the case of "ls" the Prop would have to disable color output by giving it an option: In the case of the login prompt, one can disable it by changing the prompt specification in .bashrc or wherever.
And so on.
Or one could just tell all programs that the terminal is "dumb". Yep it is. That's why we have forums like this:)
Since Linux is a multiuser/multigroup General Puropse OS (GPOS, as apposed to RTOS), it migtht just be better to create a unique group and user identity for the Propeller to login as, and then configure the Terminal for the Propeller login and other items as you require for the Propeller. Why so? It would leave the other logins intact to be used as the defaults expect. And the system would not have to dumb down for the Propeller.
Of course, this all had me wondering if a true RTOS is available for the Raspberry Pi, and apparently FreeRTOS is now supported on OpenAVR. Admittely, yet another big subject. But I suspect that using the FreeRTOS with the GPIO might be a powerful combo for some items beyond the Propeller's resources of speed and memory.
Of course, 'real time programing' and a 'real time OS' are not always the same. The Propeller often does real time programming without the burden of an OS.
http://en.wikipedia.org/wiki/FreeRTOS
I think you have a very good idea there. The propeller should not log in as "root" or any other normal user. Perhaps have a "propeller" user account that it can use.
However that is totally orthogonal to the capabilities of the terminal that Linux is dealing with when "propeller" logs in.
So called "real-time" operating systems can be nice. But given that you have a Propeller to do the real-time stuff (without an OS at all) it makes no sense to put FreeRTOS or whatever on the Pi. That just means you have lost the amazing convenience of having Debian there and all the possibilities it offers. Yes. When you feel the "need for speed" you kick the OS out.
Somebody famous defined an "operating system" as "that thing that gets between the programmer and what he wants to do." Or something like that. I'll try and find the reference.
Well .. as written in my initial post this is the first iteration for attaching the Pi via it's serial interface. Before that I used the USB and a nice tool which makes a serial interface availabel on a network port. The propeller was listening to commands coming from the Pi.
What I don't like on this approach is, that the propeller is passive.
What I don't like on the "build your own shell" approach is, that I have to build my own shell where on the other hand everything is already there. But then the Pi will be passive.
What are my plans:
It's again for my home-automation.
The propeller will be the heart of it. Keeping track of the time with the help of a DCF77 receiver. Attached to RF sender to switch on/off power and for regulation of the heating, attached to an IR sender for steering devices like the TV, radio ....
The Pi will be the gateway to the internet/home network and do other things which I am currently not aware of.
So, it looks like it would be practical to allow both to be active and indeed it will end up in implementing something on both sides ...
As Java is running on the Pi, it might be worth to try my PropellerHUB code, which is a first iteration of a message dispatcher system.
Don't know where it ends ...
The Propeller specific login is a good idea in all cases.
At some point, it would be fun to look at a lightweight RabbitMQ (or some other massage package) implementation for the Propeller. Ahh, so many things and so little time!
Scroll down through the man page and you will find raw mode as the heading.
http://man7.org/linux/man-pages/man3/termios.3.html
Here is something that might help.
Let's assume your Prop is logging in as user "pi". In the /home/pi directory you will find a hidden file called ".bashrc". Note the leading ".".
Edit that file. Have a search for "color" in there. You will find all the places where color prompt is turned on, Use of color in ls is enabled etc.
Comment out all those color enabling parts.
Logout, log back in again. BINGO all coloring is gone.
Now when your Prop logs in it should be escape sequence free.
Of course it is better to create a "propeller" user on your Pi for the Prop to log in as.
All that termios stuff is great if you want to access the serial port directly via your own C/C++ program. Languages like node.js Python, Java have simpler higher level ways of doing that. Assuming you want to write your own shell.
Personally I would write a little shell in node.js that reads lines from the terminal and executes them via "system" returning the output to the port. It's only about 10 lines of code.
Before logging in, the Propeller is going to get the system default... regardless of what it wants. (unless you want to degrade the login to suit the Propeller.)
So the login routine on the Propeller has to filter out trivial human interface, then login appropriately.
After the login, the Propeller can be automatically channeled into a workspace for it that simplifies the interface. Some people will want to use Bash, others might just prefer using Python, or C.
But the challenge is to get through the login and to arrive at a workspace that does what the Propeller user wants.
Is there really a one-size fits all solution to this login? If so, it is likely that the code is best written in C and then available to be compiled into a rather long and growing list of Linux alternative distributions on the Raspberry Pi.
Some people really hate BASH.
If you are going to be involved in Linux, some study of systems administration is unavoidable. It isn't merely about picking at a bit of code here and there. You may just break the OS and have to reload and start over.
Better to disable the kernel console on that port and remove the getty that runs on it after boot up. Easily done as discussed above.
Then have a process running on on the Pi listening to the port and responding to commands.
I would even be loath to just pass received commands on to the OS for execution but rather implement a set of commands to do what you actually want the Prop to be able to do.
I am just trying to figure out a clean way of doing this. To a new Linux user it is not all that clear and it really is a system administration topic.
Eliminating the console Terminal (the services to the video and usb keyboard and mouse) can simply be achieved by not using a #5 runtime level, and instead using #3 runtime level. The internet interface remains intact, but I suspect that the Pi might use less power as it won't be running XWindows in the background.
It seems that one can read the init runlevel files or the /etc/inittab file to see which version of Getty is used and how it is specifically configured. If it is okay, just use it as is. If not, tweek it to work well with the Propeller. You can have different getty configurations in different run levels.
/etc/inittab is where you can remove the VT100 emulation with all the Esc characters and such. Get the manual listing for your particular version of Getty and study tutorial on all the options to get the ones that suit your Propeller application the best.
/etc/Inittab also has a line that can change the startup runlevel from 5 to 3. So get to know how to edit this file.
You say I am being overly complex, but I tend to feel that claims of easy use to new learner over-simply the fact that a Linux OS requires consideration.
Linux has very good Free documents in pdf on-line. I have been reading the Linux Systems Administrator pdf in this regard. But it take a bit of time to learn the Linux way of doing things.
So, you really may desire to edit the /etc/inittab file to have getty configured to exactly the way you want it to behave. Getty actually comes at getty, agetty, mgetty, and minigetty... with variations in abilities. So it might be wise to see what your Linux has and study the HOWTO to properly configure.
etc/issue may have an initial message sent by getty that can be reduced to nothing... mine of this notebook is a short message that says "Debian GNU/Linux 7 \n \l"and it may be the \n \l that are annoying the Propeller's login.
I still think it is a good idea to have the Propeller assigned its own login identity and password. It may help tracking problems in the future and will confine any files that it creates to one set of directories.
http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/getty.html
Historically, Linux pretty much lots interest in supporting a wide variety of serial terminals after about VT102 as personal computers had overtaken the use of dumb terminals.
But first try removing the \n \l and any other special codes from the etc/issue file. You might reduce that text to just one tiny key word that the Propeller listens for and that confirms the connection.
Heater and I seem to have entirely different views on how to do this. That's okay. I have figured out how I would like to do it to key the Linux system from becoming too customized to keep track of.
More getty explainations here..
http://www.tldp.org/HOWTO/Text-Terminal-HOWTO-15.html
http://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/os/
So we can have working Raspberry without an OS. A bare metal ARM machine programmable in asm with working graphic chip onboard! which we can control.
This is a dream... Now, we can connect a Propeller to Pi via its GPIO and use it for heavy duty processing and displaying via HDMI. These heavy duty tasks can be programmed in asm or c without an operating system.
Good.
Is there a flaw in this line of thought?
Anyway ... thanks pik33, for this link ... definitely worth being bookmarked! First thing I'd do is to teach the raspberry how to display the propeller font! ;o) But seriously ... what would be important is to also get network up and running.
But ... in my case it would mean too much re-inventing, because I want the raspberry pi to be the web-interface for the propeller. (have a look: https://github.com/MagIO2/Web2Home---lcars/wiki/Screenshots ) So, coding a bare metal apache primarily sounds like a lot of work and less like a lot of fun.
@Jon: No flaw ... that's exactly what I do ... well except of the game-part, which is a web-part in my case. But the propeller is handling the RC, IR, DCF77 and a LCD-display with some buttons and maybe some 1-wire devices.
And it will have the power to shutdown/wakeup the raspberry.
Without knowing the demands the game might make it seems like a totally reasonable line of thought.
Pi runs the big stuff, takes care of graphics and networking etc Prop takes care of the I/O.
You can easily connect the UART on the Pi GPIO directly to the Prop.
You can even run Simple IDE and develop C and Spin code for the Prop on the Pi itself. (Shout if you need a SimpleIDE package built for the Pi).
For graphics on the Pi I would forget about X Windows.
I have been playing around with Open GL and the Qt libraries. With that you can render GPU accelerated OpenGL directly to the frame buffer, full screen. It's small and fast. (Shout if you would like a build of the latest Qt v5.2 that does that. It took me about three days to compile it!)
I'd forget about going bare metal. What do you want to do write an OS and device drivers or make a game?
You can always get direct access hardware registers if you really want to and you can set your program to be a high priority task if it looks like something is fighting with it.
Besides, it's much nicer to have portable code and be able to test on a PC.
Now, who is going to write all the Forth words required to make use of the networking, video, GPU, audio, USB and other hardware features on the Pi?
You really presume too much... I have tried again and again to say that Forth is a wonderful for looking into the details in the actual silicone.
EForth provides a complete array of ANS Forth lexicon from about 30 primatives, so the majority of the programing into generic Forth has been created for the user. As far as as other .. higher level features, load Linux on the Pi. After all, it is essentially a SOC with full Linux support. Why should anyone want to decend to Forth to reinvent Linux?
Forth can be used to find a way to improve interfaces for later installation into a full Linux installation.
two days ago I started playing around with openHAB, http://openhab.org/index.php/start/
This is a java based open source automation server with "binding"-components to interface with almost any
house automation protocol like knx, asterisk, z-wave and 38 others including TCP/IP, UDP, serial etc.
There is also a rasperry pi version.
I'm not sure if this would help.
Here is a demo-server
http://demo.openhab.org:8080/openhab.app?sitemap=demo
you can control in your browser
or with this android-app
https://play.google.com/store/apps/details?id=org.openhab.habdroid
download runtime-modul
https://openhab.googlecode.com/files...time-1.3.1.zip
Zip-file containing the binding modules
https://openhab.googlecode.com/files...dons-1.3.1.zip
Editor for configuration files
https://openhab.googlecode.com/files...-win-1.3.1.zip
configuration files for a local demo
https://openhab.googlecode.com/files...tion-1.3.1.zip
documentation is still quite rudimentary but there are several support offers
attached the configuration files I used for a small test demo
the difference to the standard demo is just an item
best regards
Stefan
Introduction to video and USB: described in link I attached.
Audio in Pi is like in the Propeller: duty dac or PWM. I think it is now simple duty dac, so when using noise shaper we maybe can have better sound from Pi than what it is now.
All of drivers code is available from Linux souces so we may use it to write a Forth (or Basic) equivalent.
MMU is not running when kernel.img starts so we have a normal physical addressable ram and IO.
Now I am thinking what tasks can Pi do better and what can be better done by the Propeller. Of course pi: video and number crunching and USB kbd/mouse (mouse code is not finished in these tutorials). Maybe audio.
SD? I don't know. Maybe a Pi. It requires FAT32 formatted SD for start. I wrote a SD driver for DE2-115 in Verilog, so I can do it for Pi (if only I have some time). There is a neat GPL-licensed good working (tested on DE2/Nios) FAT32 C library available, which can run on top of any sector read/write driver, so SD will be easy to do.
And of course the Propeller can play SID tunes while the Pi can emulate a 6502.