Well, it was the huge and open ended scope and expense of Multics development that led to the simple lean and mean Unix which in turn inspired the lean and mean Linux. I am surprised you are not all in favour of that.
At the end of the day it's not the technological benefits that win out but the mind share. The capability of many people, individuals or companies, to work together to create what they want.
Well, it was the huge and open ended scope and expense of Multics development that led to the simple lean and mean Unix which in turn inspired the lean and mean Linux. I am surprised you are not all in favour of that.
At the end of the day it's not the technological benefits that win out but the mind share. The capability of many people, individuals or companies, to work together to create what they want.
Why not join the party?
I most definitely am for good lean systems that are shared in mind. For this reason I have used Unixens for a long time, and even supported Linux for a long time. Now I can not compile a useful Linux kernel with the needed modules for very minimal functionality in under 256KB, that is in itself a red flag, then there is the user land which is many times bigger for a near minimal install (bash and and the standard GNU utilities, that are standard to *nix take a few MB alone, then add GCC, ouch).
The size in and of itself is not a good indicator, the better indicator is the code complexity that has lead to the size, and this is the issue that caused so many problems with Multix. Remember that Multix began as a simple lean OS, then they decided that it should do this that and the other, in the OS, that ruined Multix. And now with modern Linux we are saying that the OS should do this that and the other, and are adding complexity in order to achieve those goals, same exact thing that happened with Multix. I like Unix for being lean, I like the early versions of BSD and Linux for the same reasons, I do not like the versions that have become worse than Multix.
Though when any system goes to far, it is time to take a step back and ask ones self if the benifit of using it is worth it.
Next is to port another OpenSource *nix to the Raspberry Pi, along with its GUI. That is MiNT plus DR-GEM, with the needed portions of the BIOS, and XBIOS. MiNT is under a BSD like license, GEM is GPLv2, and the BIOS and XBIOS code has to be written for the HW, so license is not an issue.
Sorry. I thought the compiler was done and we had moved on to the loader.
I am looking for infor on the loader now, though that is slow going. As it would have to be largely OS dependant I am looking to write a new one. Though finding the information is not that easy.
I thank you for that. I did not know that SVN could be used with github. I do know that there is a RISC OS version of git out there somewhere, though the old sites that used to host it are gone, and the master branch source for git will not compile on RISC OS with out significant modification.
When using a UART transport, you can encode 1,2 or 3 bits into a single UART byte
Thank you very much. That gives a very good overview, and it gives the spin file in a usable text format, with out making me download a text editor that understands unicode, thank you much.
In fact PLoadLib.c is a fully functional Propeller loader all by itself. You just have to compile it with MAIN defined. (Well, it also needs the appropriate osintxxx file for the I/O on your platform.)
My loader repo should be redundant now as the changes I made are now in the upstream prop-gcc version.
In fact PLoadLib.c is a fully functional Propeller loader all by itself. You just have to compile it with MAIN defined. (Well, it also needs the appropriate osintxxx file for the I/O on your platform.)
My loader repo should be redundant now as the changes I made are now in the upstream prop-gcc version.
I do thank you for that. I am already looking at the information on the Propeller loading protocal, and I see it is rather simple. One could easily bitbang the RPi GPIO with a microsecond timer used for keeping time correctly, with even having to worrie about serial IO at all. Though the standard serial interface is so simple in RISC OS it realy does not matter, and the extended FTDI interface provided by the FTDI module is also very simple (that is a hallmark of RISC OS, all API's tend to be simple).
It apears that I will soon be back to working on my 3D Printer firmware, with out Linux, just RISC OS, and I will see about making a branch of openspin using SVN (as that apears to be possible).
The one frustrating thing is that files tend to loose there type information on github (something that is not needed, though so, github could store type information, and send it as a MIME type [in other words follow the standard]). Though I can add an obey file (RISC OS Script) that retypes those things that need there type preserved (like the icons, and obey files), and give instructions to set that obey to type obey and run it.
On the issue of the onboard FTDI on some propeller boards causing trouble:
Is there a way to connect to pins 30 and 31 dirrectly for uploading code to the Propeller with out having to worry about the FTDI reseting the propeller in mid upload? Could one just make to pull the reset pin high through a RPi GPIO to keep the FTDI from reseting the Propeller?
Simplest way of preventing FTDI reset I could come up with was to have an external I/O signal hold the junction of R23/R24 low as per the attached diagram. The diagram is from the propeller project board, but the other boards with FTDI chips should have the equivalent circuit.
The best solution is to replace the FTDI with Silabs CP2110. Then you do not need a driver nor do you have reset issues. FTDI for a hobby board that is for your purposes only is OK, but is a real pain for products that you intend to sell that will require the end user to update firmware on. There is an eval board called the CP2110EK that you can test with. I have a command line prop loader for it also for Mac/PC if you are interested.
The best solution is to replace the FTDI with Silabs CP2110. Then you do not need a driver nor do you have reset issues. FTDI for a hobby board that is for your purposes only is OK, but is a real pain for products that you intend to sell that will require the end user to update firmware on. There is an eval board called the CP2110EK that you can test with. I have a command line prop loader for it also for Mac/PC if you are interested.
I was saying if not using the FTDI, though leaving it on the board. There is no use for the onboard FTDI chip on the verious propeller boards, though I can not remove it with the tools I have, and I want other people to avoid the extra expense of a serial cable (unfortunately the Propeller Proto Board that does not have an FTDI is no longer available ). I would wish the loader to support as many hardware interfaces as possible (direct serial [using a third pin to reset], FTDI Serial, BitBanged GPIO, etc).
The FTDI is not needed on any system (on any desktop system you can use a serial port of some form, and on the RPi you can use the GPIO's (configuring two of them as serial is the easiest way)).
Simplest way of preventing FTDI reset I could come up with was to have an external I/O signal hold the junction of R23/R24 low as per the attached diagram. .
Or even just a jumper, so you can enable RST for download and then kill it, so you know glitches cannot sneak into the system.
I think a monostable (+ jumper) could be used to generate a reset, on systems with no DTR available, if the protocol can tolerate losing the first char ?
Many repeat the early stuff to tolerate slow reset-recovery.
Simplest way of preventing FTDI reset I could come up with was to have an external I/O signal hold the junction of R23/R24 low as per the attached diagram. The diagram is from the propeller project board, but the other boards with FTDI chips should have the equivalent circuit.
OK, so the question is is this a part of the new protoboard, and other boards that use the FTDI? I hope so.
I realy wish Parallax would bring back the Propeller Proto Board.
OK, so the question is is this a part of the new protoboard, and other boards that use the FTDI? I hope so.
I realy wish Parallax would bring back the Propeller Proto Board.
I guess I shall have to experiment a bit.
Yes, holding the base of the reset transistor low should work for the Propeller Quickstart, Platform USB, and Protoboard USB, or any other board that uses the FTDI chip and transistor.
Comments
At the end of the day it's not the technological benefits that win out but the mind share. The capability of many people, individuals or companies, to work together to create what they want.
Why not join the party?
The size in and of itself is not a good indicator, the better indicator is the code complexity that has lead to the size, and this is the issue that caused so many problems with Multix. Remember that Multix began as a simple lean OS, then they decided that it should do this that and the other, in the OS, that ruined Multix. And now with modern Linux we are saying that the OS should do this that and the other, and are adding complexity in order to achieve those goals, same exact thing that happened with Multix. I like Unix for being lean, I like the early versions of BSD and Linux for the same reasons, I do not like the versions that have become worse than Multix.
Though when any system goes to far, it is time to take a step back and ask ones self if the benifit of using it is worth it.
Next is to port another OpenSource *nix to the Raspberry Pi, along with its GUI. That is MiNT plus DR-GEM, with the needed portions of the BIOS, and XBIOS. MiNT is under a BSD like license, GEM is GPLv2, and the BIOS and XBIOS code has to be written for the HW, so license is not an issue.
I am looking for infor on the loader now, though that is slow going. As it would have to be largely OS dependant I am looking to write a new one. Though finding the information is not that easy.
I do thank you.
I thank you for that. I did not know that SVN could be used with github. I do know that there is a RISC OS version of git out there somewhere, though the old sites that used to host it are gone, and the master branch source for git will not compile on RISC OS with out significant modification.
I can not seem to find anything despite looking.
There is a complete, concise, working code example here - sometimes it is easier to take a low-level coded working example
http://forums.parallax.com/showthread.php/146354-Multiple-propeller-chips?p=1167623&viewfull=1#post1167623
code comment says :
["lets a Propeller chip load up another Propeller chip in the same way the PC normally does."]
When using a UART transport, you can encode 1,2 or 3 bits into a single UART byte
But anyway, I made a version of the loader used by prop-gcc that uses a GPIO pin on the Raspberry Pi to reset the Propeller: https://github.com/ZiCog/pi-propeller-load
Everything you need to know about the loading protocol can be gleaned from looking at the code in this module: https://github.com/ZiCog/pi-propeller-load/blob/master/src/PLoadLib.c. It's quite small and simple.
In fact PLoadLib.c is a fully functional Propeller loader all by itself. You just have to compile it with MAIN defined. (Well, it also needs the appropriate osintxxx file for the I/O on your platform.)
My loader repo should be redundant now as the changes I made are now in the upstream prop-gcc version.
It apears that I will soon be back to working on my 3D Printer firmware, with out Linux, just RISC OS, and I will see about making a branch of openspin using SVN (as that apears to be possible).
The one frustrating thing is that files tend to loose there type information on github (something that is not needed, though so, github could store type information, and send it as a MIME type [in other words follow the standard]). Though I can add an obey file (RISC OS Script) that retypes those things that need there type preserved (like the icons, and obey files), and give instructions to set that obey to type obey and run it.
Is there a way to connect to pins 30 and 31 dirrectly for uploading code to the Propeller with out having to worry about the FTDI reseting the propeller in mid upload? Could one just make to pull the reset pin high through a RPi GPIO to keep the FTDI from reseting the Propeller?
I was saying if not using the FTDI, though leaving it on the board. There is no use for the onboard FTDI chip on the verious propeller boards, though I can not remove it with the tools I have, and I want other people to avoid the extra expense of a serial cable (unfortunately the Propeller Proto Board that does not have an FTDI is no longer available
The FTDI is not needed on any system (on any desktop system you can use a serial port of some form, and on the RPi you can use the GPIO's (configuring two of them as serial is the easiest way)).
I think a monostable (+ jumper) could be used to generate a reset, on systems with no DTR available, if the protocol can tolerate losing the first char ?
Many repeat the early stuff to tolerate slow reset-recovery.
OK, so the question is is this a part of the new protoboard, and other boards that use the FTDI? I hope so.
I realy wish Parallax would bring back the Propeller Proto Board.
I guess I shall have to experiment a bit.
When you drop a spin file on the !OpenSpin IconBar Icon a Window will open that looks like:
With the field that says "Spin File" replaced with the name of the spin file. Then just use the buttons to compile as wanted.
I second that wish.
Yes, holding the base of the reset transistor low should work for the Propeller Quickstart, Platform USB, and Protoboard USB, or any other board that uses the FTDI chip and transistor.