Prop II on-chip development question
Harley
Posts: 997
Having read about Ken's comment on what might ultimately be in Prop II, I'm wondering about the 'on-chip development' interface. Has there been any comments from Parallax on what this requires?
One needs a keyboard and display. And an i/f to a printer. And maybe an i/f to any USB computer to provide means to download from Internet and compile files and save them, etc. I'd like to see a diagram of how Prop II would i/f to the rest of the world.
Anyone have any word on how this on-chip development system would be used?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
One needs a keyboard and display. And an i/f to a printer. And maybe an i/f to any USB computer to provide means to download from Internet and compile files and save them, etc. I'd like to see a diagram of how Prop II would i/f to the rest of the world.
Anyone have any word on how this on-chip development system would be used?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Comments
The only word on this was that it probably was not going to be included in the initial release of the Prop II. That was mentioned by Chip some time in the past as part of the discussion of how much ROM would be included.
I'm sure there's nothing yet other than mparks' Sphinx system which he demonstrated at the last UPEW. This includes a simple editor, Spin compiler / assembler and simple O/S that uses a PS/2 keyboard and TV display and runs off an SD card.
An on-chip development system is a long-term goal of Chip's, but I suspect we won't see anything for a couple of years (2-3 probably) after samples of the Prop II are available. It will take that long to develop a stable/well-tested set of I/O drivers for a variety of displays and keyboards and port something like Sphinx with a decent screen editor. My personal opinion is that we will need USB HID drivers for keyboard and mouse and we'll need some kind of VGA-sized display. PS/2 keyboards will be 2-3 years older and will be increasingly hard to get. We may need digital display drivers (and matching hardware) as analog displays become less and less the norm. Similarly, there'll be newer standards for digital storage media. We're already seeing FAT16 disappearing and memory cards over 2GB becoming the norm.
It may be that we will see a "command line" compiler and assembler that's executed directly from ROM and passed a source program in RAM. That would avoid having to build I/O drivers into the ROM where they'll become obsolete quickly over the lifetime of the chip. You'd need some kind of editor and I/O routines that would be loaded from EEPROM or other external storage and those could be updated as need be.
I would expect any on-chip development to use a microSD card for the file system. The microSD will, at least initially, contain the editor/compiler/os, etc. This will allow complete testing and most likely remove any dependency on ROM for this.
I have asked for an option to boot a binary file (optionally encrypted) from microSD (at least FAT16, but FAT32 if possible) without the requirement for having a boot EEPROM/FLASH.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I had a TRS-80. I don't want another one, regardless of how fast it might be.
-Phil
Just imagine if full duplex serial, a tv driver, and tcp ip stack where in rom. Could save lots for apps that communicate by these means.
Being able to boot from sd card would be a usefull feature.
I think the best objects from the obex that are not likely to change like fsrw will should be placed in rom
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
24 bit LCD Breakout Board coming soon. $21.99 has backlight driver and touch sensitive decoder.
Right now, other devices are used to develop code for Propellers, and sometimes those other devices end up with "issues". If the Propeller is to be sold over an extended time period, there is a level of stability possible in the reference development tools being written on the chips themselves, for an absolutely known consistent interaction path with the devices.
I'm positive that was part of the appeal back then when Chip was musing about the idea of it. Throwing back to the 80's really wasn't a consideration as much as control and stability were. There was some discussion over the current tool set and the PC, and ugly things...
The idea of how to do it is an intriguing one. Guess the simplest use case would be ASCII text, over serial I/O, using a larger sized EEPROM for storage.
Anyway, I think it would be cool, and that's all I've really thought about it. There is something comforting about simply being able to use a Propeller, with a minimum of enabling technology, if you have a propeller!
I totally second useful bits of code in the ROM, BTW.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 11/23/2009 5:14:45 AM GMT
However, with a microSD card, it no longer has to be in ROM. The cards are cheap and small. So the nice feature would be to be able to boot from an SD file without the requirement for an EEPROM or FLASH chip. So the ROM will need to have code to boot from an SD file.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
But still, I do not understand why Parallax wants that.
At a first glance, that might look like a good idea to some. Not for me.
Disregarding my personal preference, the on-chip development system will introduce a lot of dependencies and more or less freeze the hardware to a single layout.
* What type of display (PAL? NTSC? VGA?) on what pins?
* What keyboard (English, German, Italian layout?) on what pins?
* Type of external storage on what pin?
* Mouse on what pin?
* What screen resolution?
* Preferences? Where will they go?
* ...
The SPIN-interpreter is rock solid (albeit I don't like SPIN) but we have seen some fixes with the Propeller Tool. That would be cast in silicon (ROM) and there is no chance of fixing it. Or we will see revisions of the Prop II that fixes issues. A new mask will cost "only" 120k$. OMG! Who will pay that?
Also, this will waste resources (maintennance for Propeller Tool and on-chip development) and cost time and money.
Really, that's a incredibly bad idea!
Build an development-system that runs on the prop and can be recompiled to fit your hardware-layout. Flash it to EEPROM, throw a switch and boot into it. That's the way to go.
Fill the ROM with tables like sine, tangens, ln, log, fonts, fonts & fonts
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
Post Edited (Nick Mueller) : 11/23/2009 7:53:11 AM GMT
Phil, don't worry about much ROM being spent on a development environment. It would probably only take about 16KB. The original BASIC Stamp development environment on the PC was written in x86 assembly and it fit into a single 13KB .EXE file. It included a full-screen editor, compiler, and downloader. I'd like to apply Lempel Ziv compression to all file data in ROM, so we could fit megabytes of source code in there.
By the way, the main reasons for the many rev's of the Propeller Tool have had to do with Windows issues, not the core tool functionality.
I think people don't even realize anymore what a stable platform would mean to their state of mind. There's an immense peace that comes from stability. When you always have to take one step back for every two steps forward, it eats at you, and has a subtly depressive effect. A rock-solid stable environment, though, will·instill a load of confidence in you and make you feel like you're sailing·under blue skies on calm water, not in the modern fog and choppy waves we're all used to nowadays. I haven't had a stable environment since the Apple ][noparse][[/noparse]. I miss the days when things just worked, and I want to bring them back.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/23/2009 8:03:36 AM GMT
I'm glad to hear someone willing to say what so many of us in these forums quietly believe, but so few seem willing to state in so forthright a manner. Windows is indeed an "ever convolving dysfunction". It is a tool whose primary purpose appears to be to confound and confute its users instead of assisting them.
Keep up the good work.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I was just curious how well such a development system would work. Seems to have considerable limitations compared to an IDE like the Prop tool. And with only 8 cogs, some would get used up with display, keyboard and SD card drivers, etc.
At first reading it sounds like a great idea. But then thinking of having so much with an IDE, I have a poor feeling that it would cripple writing good programs. And probably would take much development time for the on-chip 'IDE' which might become obsolete/too fixed rather quickly. Wish Chip had mentioned more on this 'feature'.
I wrote this before I read further and saw Chip's comments. Though, I still wonder how well it would work and how many Prop II resourced would remain available, like the cogs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Post Edited (Harley) : 11/23/2009 8:30:00 AM GMT
Keyboards and screens (TV or VGA or even mini LCD) are cheap and plentiful now. There are rollup keyboards now, projected keyboards starting to appear, and even cheap projected displays. Imagine the education market that this opens up when a pc is not required. Small and portable. Easy to program - just try doing a VB.net program without prior knowledge! Write a game, interface to robotics, etc.
The Prop II will truly be a computer on a chip.
In the 80's if the mainframes and minis crashed so often the companies that built them would have been sued out of existence. Lucky for us MS didn't build the car - just imagine having to pull the engine out randomly and reinstall without any fixing, just to keep it going. *grin*
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Thirty years later Chip would like to sell you Propellers. He would also like to sell you a development system for them. That uses the same Propellers.
I think it is an audaciously brilliant idea.
I imagine the thing should be on a circuit board about the size of the palm of your hand, or smaller. It should have connectors for keyboards, USB, screen, SD cards. What ever it needs to run as a dev environment out of the box. It should cost about 50 dollars.
You probably need it as there are no reliable PC's at this time.
Not sure why the IDE software needs to be in the ROM where it's impossible to update but if it is that small why not?
Alternatively I'd like to see BST cross compiled for the ARM architecture so that I can run it on my mobile phone or on a tiny cheap system like this: beagleboard.org/
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
But this is a completely different route. And then, there is no need for the IDE in the ROM.
Build a dedicated board who's purpose is to enable development (including a IDE) with the code in EEPROM (write protected). Then you have what so many want. It'll be cheap and could be updated.
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
I have a box. It's 3 years old. It weighs 1,250 grams and it's about an inch thick at the fat end. It has a 11.1" screen, nice keyboard, large(ish) hard disk, wireless network and gives me between 5 & 11 hours development time on the battery. It even powers my propeller development board over the USB port so I can work in the car, on a bus or on a plane. Oh, and when I'm near a network (like the departure lounge) I can download and unzip code from the Obex, post to the forums and do all my other development and office work on it.
It never crashes. It gets rebooted about once every 3-6 months for a kernel update (because I can, not because I have to). Between reboots it is simply suspended or hibernated (depending on how long I'm going to be unplugged). I don't see the attraction in a stand alone environment. I never have.
Someone please supply me with the clue I'm so obviously missing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
1) A few old grey haired amateur radio guys will still be able to get messages through for you using tube tarnsmitters and recievers.
2) A few will still be able to program their Propeller based computing systems. All other platforms being rendered useless due to the unavailability of MS activation servers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I have always considered and often used multiple processors. They are cheap, although not always so, and they can save assembly costs, case sizes, repair times, etc. Often these additional costs are never considered.
Here are 2 photos of my designs from 1981 onwards. Sorry about the quality. The NL18 is the pcb only - the two large 28 pin chips are MC68705P3S. The NL16 has three processor chips, MC68705P3S, MC68705U3S and a MC68701.
In 1981 I designed the NL12 (just a larger footprint than the NL18 shown). The MC68705P3S was sampling and when released that year they cost $150 each ($1500 each in today's terms). I used hundreds at this price. Five years later they were $20 (used 100,000's) and by about 1987 they were $8 each. This pcb replaced four (4) 12"x12" logic boards, the power supply and the metal case that housed them.
So now you know why I like multiple micro chips
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 11/23/2009 11:06:11 AM GMT
Regarding the ROM space/contents I am more of the idea to have an OTP (not know what is the difference in ic design between the otp and the standard mask rom) with just a boot loader on it. Beside this Parallax can offer a set of already made/configurable packages (spin interpreter, fonts, sin table ... ) that the user can upload on his needs. Looking at PropI since the ram/rom are contiguous and addressable with the same commands (if it has been this way) a user (not needeng rom tables, spin, fonts ...) will be able to make his own lmm application running directly from rom and have all the hub ram for data. In such conditions also the eeprom is not necessary.
In other words I'd like to have just the booter that, like now, looks first at the serial port, have the code to write to external eeprom/sd and internal otp (to download the program) and after that start executing from a given rom address. If ther there is the software that copy the eeprom to hub and then starts spin all will work like usual BUT if this ROM address is the first instruction of my(your) lmm application it opens a totally new world
BTW: COG feature wish: It is possible to have a special register that is always overwritten with the last result? To explain better: what if the first instruction (reg0 on actual Prop1/cog) is written by every instruction regardless of its wr/nr flag? This means that the original instruction can be executed just once (but many times this is just first time setup instructions eg. video registers, counters ...). If you have then eg. in reg1 a mov reg5, reg4 the reg4 will be moved to reg5 uppon wr flag but always moved to reg0. In the same time an add reg5, reg4 nr will add the content of reg4 to reg5 without modifing thre reg5 but the result will be stored in the reg0. This will lower the instructions count for many algorithms thus increasing the processing speed and saving some temporary registers to store intermediate values. What is your opinion about this?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
· Propeller Object Exchange (last Publications / Updates);·· Vaati's custom search
My understanding from what Chip has said previously, is that the die size for mask rom is so much smaller than any programmable memory. There is also something to do with the process being used.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
You know a development system is a boot strap, and a known stable point, not the be all end all. It is the elementary expression of use that empowers the user to come to trust the device because there is no question of whether or not the device can or will trust the user. This matters.
The Apple ][noparse][[/noparse] is an interesting case in point. If you have an Apple, you can program an Apple. In fact, if you have an Apple, you can not only program the Apple, but build on to the Apple, as the machine is completely, totally open. There is just enough software in the machine to open the doors for all that comes later. Nobody seriously developing on the Apple computer used a lot of what was in the machine, once they got their tools boot strapped. But, almost everybody got started by !F666G reading the nicely commented ROM listing, using the routines found there as the basis for their own stuff. There are no secrets at the hardware layer either, where the machine is exposed at a level where simple visual examination can tell a person all they need to know. Not only that, but interfaces are provided for said user to integrate their needs with the base machine.
@Chip: 16KB!!! Frankly, I'm shocked. Looking at what SPIN does in 512 longs makes me believe. [noparse]:)[/noparse]
Totally 100 percent agreed on a simple serial interface. That's a very low bar for communication, and a whole lot can be done with even a modest bit rate.
My first serious exposure to computing was on Apple ][noparse][[/noparse] computers. 1 MHZ 6502, nothing fancy at all. I then owned various other computers, and noted the distinct lack of the core tools somebody needs to just pick up the machine and use it. Find one in a bin today, turn it on, write code 2 minutes later. Still true. This is not true for many machines. Some had to be cracked open, others require intermediate enabling technologies, and access to data to use fully. An Apple does not.
That impacted me back then, and it's not just nostalga. For me personally, it's important to not require enabling technology to make use of skills, and where it must occur, that enabling technology really needs to read and write in open formats, and itself be open so that I may examine it and completely trust it.
http://cm.bell-labs.com/who/ken/trust.html
Now, it's not important that people always operate in this mode, but it is important that it remain possible for them to do so. I'm writing this on an XP box that I have a fair amount of trust for. Not complete. The damn thing does stuff that I either don't want done, or that I don't know is done, but it is doing the things I want it to do at a level where I'm not concerned. The Vista machines at work are not something I trust, because they simply don't trust me. Pretty hard to return the favor, and I'm moved by one of my peers being completely unable to capture the results of an online test.
The scenario is they took the test, but the score server was down, so they could not record the results to be filed. So, they thought to capture an image for use later when somebody could be contacted. There was a complex verification code being displayed. Had that test been taken on an XP computer, no issue. Archive would be possible. On the Vista computer, the DRM layer sits between the user and all multi-media content, with a kernel layer strobe checking the hardware every few ns to detect unauthorized peering at bit streams. That layer decided to not allow my peer to do anything but view that test result. No combination of software and or use case tricks would archive that screen. A photo, or leaving it on the machine for several days were the only options. This is not trivial stuff, IMHO.
My skill on these things in practice is moderate to somewhat dangerous, depending on what area of the computing dicipline we are talking about. Want to clone an expensive license you paid for? I'm probably your guy. Want to write hard core assembly? Well, I'm getting there, LOL!! Over the years, I've watched people make 6 figure investments, only to find some bit of code that does not trust them, render those investments and more importantly the skills mapped to them useless.
I don't know about you guys, but I find my skills, such as they are, hard won and important. I absolutely cannot stand having to re-map them to "new" technology that adds very little value over the existing technology. Secondly, when forced to do this for revenue generating reasons, I frankly feel like a cheap (expletive), and nobody likes that. You know the clowns that regularly pull this are laughing somewhere dark and smoky probably.
The trend toward smaller and smaller technology has escalated the trust issue. Part of what makes an Apple an Apple is the scale of the tech is such that it can be, for the most part, directly examined and reasoned about. It can also be tested with other simple, trusted enabling technology such as a scope, meter, etc... to understand what it does and why it does it and how it does it.
The scale of tech is rapidly leaving that range, leaving us in a position where we must trust the tech, or forgo using it. At the same time, we live in an increasingly hostile world, where ordinary people are not so trusted anymore. Our tech does good things, but then it does nefarious things too, and the trick seems to be to balance that such that the average person believes the issue is moot, or a net gain sufficient to carry the risk. This is not ok with me on any level. Never has been, never will be.
Of course I deal, like everybody else does, but I also am careful enough to maintain those skills needed to compute on open hardware and with open code where I can, want to, or must.
You know I am a criminal. Several of you are as well. I once bought a nice PC, a DVD player, built up some sound system, and decided I wanted to build my own, custom DVD player thing. A lawfully obtained media, media player device, computer, and software, and license were unable to play that DVD, unless I accepted a layer of operating software not open to me, untrusted. Thankfully, others were pissed proper at this state of events and dealt with it, leaving open code for the world to close the loop. Obtaining that code here in the US is a crime, executing it is a crime, and viewing my own media on my own machine is a crime. It is a crime for no reason other than the producers of that media do not trust me to abide by the law and use the content in the manner in which is was licensed.
So I did this, and it was a nice setup. Insert DVD, press the "play the damn movie" button (and yes, I had a play the damn movie button), and the movie would simply play. No menu, no previews, no nothing, just the movie. My wifes first exposure to DVD was on this Linux machine, and she really liked it. Later, life situation changed, and she ended up sitting in front of a machine that did not trust her, and she found that machine exploited her and there was very little to be done about it. Some titles had 12 minutes of previews that a person is forced to watch before the actual content. This is morbid really, particularly after first viewing.
Today, I have a Blu-Ray player. The thing is closed huge. It is downright hostile, and does not trust me at all. In fact, it maintains a state of constant awareness of the state of everything from the media to the display with layers of encryption, virtual machine code embedded in the media, just in case my device ends up not being trusted, more layers of encryption between that device and the display, and on and on to the point where I often wonder whether or not we may one day have to register our own eyes.
All of that effort simply because I personally am not seen as trustworthy enough to actually own the devices I use. If it's not open, you really don't own it. The whole affair is more like a rental than anything else.
So then forgive me for that rant. Coming back around full circle to the Propeller.
There is an obscene amount of waste today due to these matters of trust. Complex devices ending up in land fills because they do not trust the users who possess them. Phones, media delivery systems, and god knows what else. That waste is criminal, given the amount of human effort it took to build up the enabling technologies necessary to produce it.
Someday in the far future, some kid is going to pick up a device with a Propeller in it, be curious, and come to use that device as if it were their own. Contrast that to many of the things kids might find today, and that's somehow just not a bad thing. It is, in fact, the same exact use case scenario that every one of the giants today experienced in their youth, and that experience was enabling in that they were able to build their empires for nothing more than a keen, curious mind, ability to observe, tinker, build and grow.
I often wonder whether or not they fear that little kid today, upstart, building the next great thing out of sight, un-owned, and whether or not that fear, or simple greed, drives them to take more than ordinary steps to insure that if something like that does occur, the chain of ownership of both technology, and the ideas behind it insure that kid pays them tithes they themselves never had to pay. Maybe that's just me, but maybe again, it's not.
Here in the United States, we have a doctrine of personal freedom that challenges this whole state of affairs. By law and mutually agreed social contract, we recognize the simple empowerment granted to us, and take steps to make sure it remains simple, pure so that any person here may exploit that personal freedom to live their life in a full, robust way, possibly improving ours along the way as well.
This whole mess runs counter to that, and I only bring that bit of politics here for context. Please take it as such, and nothing more than explanation as to how I arrived where I did on the core elements of computing freedom and why it's important.
I'll shut up now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
I have the Grey hair, and my father still has some of the old hot glass things. The Seckshund family line is assured.
I still have some 8051 types with MCS Basic, it was the getting the stuff in and out that led me to the Prop's KBD and Vid/VGA self containment. It is probably why I still yearn for my Nascom, and·reboots before you get you finger off the reset button.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Style and grace : Nil point
How about the "do not steal this dvd" blah blah ? I bought it! so why bothering me with that !?.. the bootleg copies do not have those nice messages... the "pirates" never ever see them... only the "legal" customers... why pissing them off ?
The DVD player soft in Mac OS X does not allow you to skip all that !. thank some nice and understanding guys and gals we have VLC and MPLAYER.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Visit some of my articles at Propeller Wiki:
MATH on the propeller propeller.wikispaces.com/MATH
pPropQL: propeller.wikispaces.com/pPropQL
pPropQL020: propeller.wikispaces.com/pPropQL020
OMU for the pPropQL/020 propeller.wikispaces.com/OMU
Cluso Said, "However, with a microSD card, it no longer has to be in ROM. The cards are cheap and small. So the nice feature would be to be able to boot from an SD file without the requirement for an EEPROM or FLASH chip. So the ROM will need to have code to boot from an SD file."
I wholly concur.· Booting up from a file off of SD--even if only a fixed name and without a menu--is a near must.· It would allow device-makers to reconfigure behavior of their customer's devices (i.e., let customers reconfigure their devices in the field) without needing to connect a PC.· This in turn potentially means that both EEPROM and a USB or a·serial connector become optional, potentially reducing product cost and complexity.· Moreover, many applications (HW/SW) are going to need the memory card for data or storage, so why force them to dedicate lines for both EEPROM and SPI.· Perhaps those two can share some lines, but I don't understand the details yet.· But simplicity of design has the fewest "gotchas."
But I'm wondering about whether it should be micro SD.· I've read that SPI functionality is "optional" in the micro SD spec.· Do the controllers for the majority of cards implement SPI anyway?· And if SPI is not available to control the card in the MMC mode, wouldn't we be looking at needing to pay SD royalties?· I don't mind so much a royalty fee being embedded in the purchase price of an SD card, but having to pay annual membership fees for the pleasure of making SD hardware would be a definite burden for a small company making a small run.· I think it's on the order of a couple grand or so, which, for example, in the case of a product with a $20 "profit" otherwise, would mean one would have to sell 100 units/year just to pay the membership fee.·· And that woud cut a lot of ideas off right there, it seems to me.·
On a related matter, on this forum, others have mentioned that it'll get harder and harder to find 2GB or under cards that can use FAT16.· I'm not sure about FAT16, but, technically, I believe that FAT32 devices are supposed to pay a royalty of about $0.25/hardware unit (to Micro$oft, of course).· Well, actually, that doesn't sound so unreasonable...because it's a per unit charge (if I understand things correctly), as opposed to an annual membership fee thing, so one would only need to pay the royalty on the devices they sold, and a quarter doesn't seem like a deal-breaker.· But if, at the same time, we need to access the card in the SD mode, then that is potentially a big barrier, as it appears to require paying those annual membership fees.· It could probably be ignored for one-offs, but not in production.· Can FAT32 be used with SPI?· Offhand, I don't know.· The whole idea that the consortium that owns SD IP charges both coming and going (hardware and cards) is the essence of greed in my opinion and stiffles creativity for the little guys.· At the very least, they should exempt small companies, provide a drastic discount,·or establish a minimum quota before such a membership fee goes into effect.· Oh, perhaps larger cards can be formatted for lower capacities, but that could waste considerable storage capacity·of the card.
Anyway, although I don't know the details of how those matters will work out, we absolutely must have to have SD/MMC card boot capability (built into the ROM) if at all possible, even if the driver behind it can't be updated (as we can always load a newer driver upon booting if needed).· Yes, there are other solutions such as using FemtoBasic and so on to accomplish the boot, but those require an EEPROM.· My question to the forum is, "Are there any roadblocks you can see that would preclude such SD/MMC boot functionality being built into the ROM?"
And finally, allow me to close by revealing my ignorance about this built-in development environment.· There seems to be some concern about it eating up resources (at least on a single Prop II system, anyway), for example COGS and I/O lines.· Regarding the COGS, unless the system were providing real-time debugging, would any COGS be required after compilation?· I mean, COGS for video and a keyboard, etc., could be used while a user was developing a program and also while compiling, but, after that, couldn't all of that just be dumped presuming the .bin had been stored to an SD/MMC card, afterwhich the system would just reboot to run the compiled program.· One could reset (etc.) to get back to the development system if, for example, the·boot loader were·configured to look for a development environment file on the SD card.· If not present, then that's a production machine.· Or perhaps it could check an I/O pin connected to a button, etc.· Well, as a newbie, I'm sure I'm missing something but I'd like to understand the resource concerns better.· I can see how I/O pins might be more of a problem.· I was wondering if switches (either manual or electronic) could be potentially used to decouple I/O devices (video/keyboard) if such were not needed while running a program as opposed to development.· But, of course, many if not most of the running programs will still want the I/O.· Anyway, I think I'm missing something one way or another.· BTW, perhaps some button could be held/pressed on reset to configure the development environment to use the correct I/O pins for the system at hand.· Well, I guess a config file on an SD card could do that better.· Anyway, haven't thought about this, so I'd better stop.
As to whether having the built-in development environment would be useful or not, I'm of the opinion that it would come in handy in many ways that we are not able to think of at this juncture.· And it might greatly enhance Parallax's market opportunities, something that helps all of us.· Moreover, just like the COG-approach, it's something fairly novel and/or lacking on many systems.
Update:· From Wikipedia for Secure Digital:· "Royalties for SD/SDIO licenses are imposed for manufacture and sale of memory cards and host adapters (1000 USD per year plus membership at 1500 USD/year) but SDIO cards can be made without royalties and MMC host adapters do not require a royalty."
Post Edited (JRetSapDoog) : 11/23/2009 2:25:44 PM GMT
2GB SD cards will be around for a _long_time. There are many devices (like my digital camera) that will not work with SDHC cards, but it will work just fine with an SD card formatted with FAT32. It's not the filesystem, it's the interface methodology. I did come across a kludged 4GB SD card once, but it really did not work on most hardware as a lot of manufacturers seem to use signed maths in their drivers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
I typically do have a serial connection to a terminal program that shows where my WIP is (or should be). That wouldn't work when doing all on one chip.
And what if you develop a programm with video output and want to debug it? Connect two screens? Run out of COGs? Run out of RAM? Boot from development-system back and forth to work and have to select the source-file and what line to display over and over again? Can't look at source code and what your program does at the same time?
That setup is really {censored}
Nick
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!
The DIY Digital-Readout for mills, lathes etc.:
YADRO
humanoido
While I agree the Apple ROM was pretty solid, it had its bugs. Where you say "it could be updated", I guess you mean "You could load a new version of the rom by putting in a special "soft card" that allowed you to load new rom code into bankswitched RAM which was then switched over the old ROM". And just to be a pedant, but the Apple ][noparse][[/noparse] DOS was loaded from disk. The DISK][noparse][[/noparse] card contained a very simple bootstrap that allowed it to load enough of the disk to allow it to load itself. This is how we could use Apple DOS 3.2 with 13 sector disks, and DOS 3.3 with 16 sector disks. Nothing to do with updating the ROM.
Ahh.. Muffin..
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.