December 2012 - Oberon - mailman3.inf.ethz.ch

Can ETHO be ported to ARM?
by eas lab 13 Jan '14

13 Jan '14

No, not the <language>, but the unique interface of S3/V4. What matters is the human-interface. That's what determines your productivety [maximum gain for minimum pain]. Not needing to switch between awkward F-keys and the screen, and having easy access to multiple text-files together, and each text-view having <what the bottle does, written on the bottle, instead of in the filing cabinet>. Porting ETHO to linux [both S3 & V4] was a killer app:. you get the Inet capability of *nix together with the superior human-interface of ETHO, plus you can view *pdf, LaTex..etc. on the same screen. For tricky problems, needing simultaneous views of: email/s, USEnet/s, your test-logs EHO is unbeaten, especially with the text colouring facilities, which help extract the meaning of difficult explanations. Because opeing/closing a new ETHO-for-linux takes a second, it's viable to have several copies running in the various dirs, which are handling current problems. Real life doesn't allow fixing one problem at a time. Can those of us who want to escape the WinTel monopoly, hope to use ARM based CPUs with an ETHO-like interface, by a porting of the existing/proven code? == Chris Glur. PS. LNO's inability to easily navigate the dir-tree, limits its utility.

3 7

Re: [Oberon] The Oberon answer to Arduino
by Aubrey.McIntosh＠Alumni.UTexas.Net 09 Jan '13

09 Jan '13

On Wed, Dec 26, 2012 at 2:28 AM, Arnim Littek <arnim(a)actrix.gen.nz> wrote: > > > On Tuesday 25 December 2012 11:29:25 you wrote: > > > > I am getting some hard questions on my KickStarter > > > > project< > > > > > > http://www.kickstarter.com/projects/1378252804/681865516?token=bfb4 > > Maybe I'd better get a higher level view before I say anything about the > schematic. Simply the fact that the design stems from 2004, means that > most > of a decade later, you might be wise to consider your options in light of > your > highest level objectives. > > a) understandability for your students - OK, got that. > > b) serial control of lab instruments - is RS232 still the best way for you > to > do this? > This depends on whether it is my instrument, or logging data off of an existing instrument. That probably means that those details should all be on a daughter board. For a new instrument, I would not use RS-232. Some of the applications that are unique to me are leaking into this "general" device. Actually, if I call this "a case study" it is a good thing. My specialty in chemistry is analytical chemistry. It is important to weigh items to a reliable 0.000 1 g. I have students each weigh the same set of clean nickels (US $0.05 coin that is nominally a metric 5.00 g standard, readily available in the US, resistant to wear, and has "serial numbers" embossed on them) on each analytical balance in the lab, and then take apart the data to see how each balance, and each student, are performing. To take this lab to the next level, I want to record the time, barometric pressure, temperature, humidity, and the balance output. The analytical balances cost about $5,000, so I am pretty much stuck with legacy interfaces or a converter board. In the case of the Mettlers in our lab, this is RS-232 out of a DB-9 connector. The environmental stuff should be recorded inside the weighing chamber of the balance without heating it up, the RS-232 port is on the outside. So, for this project, the daughter board should receive RS-232 and a host of other transducer inputs. It should transfer, with very high reliability, the data to a database server. I probably want to use WiFi or IR for this. I don't know the practicality of IR. All of this is backstory stuff. I think I should hide it from the KickStarter project, but I am just guessing there. > > c) you've got a socket for nearly everything. Is that because you weren't > confident in your design, or for other reasons? Sockets raise the price, > and > reduce the reliability of the finished assembly. > Interesting that you notice that. I am astonished at how much the sockets and headers add to the cost. I am pretty dissatisfied with the every I have thought of. I socket the LEDs so that I can swap them out, and generate current-voltage curves for different parts. I could accomplish this in a lab by having different models of board with directly soldered parts. I socket the hobby part so that I can swap out whatever I am working on that moment. That probably could be a customer added socket. I have mixed feelings about the transparent latch. My firmware defaults to transparent and I don't think I have ever actually pulled the chip to do an experiment. I might want to have 1 or 2 socket-ed in a lab, and have the rest of them directly soldered. Another situation for 2 models, I suppose. I pulled parts from one prototype to build out the next prototype. LOL. I even de-soldered sockets to go to the next board. I think this was a bad time-money tradeoff decision, but I grew up poor and have some poor people habits that keep me poor. Since the board is also a programmer, I have put a ZIF socket on some revisions. That really adds to the cost. The current board is a little too tight for a ZIF socket. I worry about students destroying chips prying them out of a socket. I have good luck with a chip puller, or even a slim bladed pocket knife inserted under the chip and twisted, but some students have bad attitude and a streak of vandalism. It seems feasible to make this a customer decision in the KickStarter environment. I would then have hard numbers at purchasing time, and I could buy 5% excess of everything for those who make an after purchase change of mind. > > d) ref. b), if you use USB, then you can simplify the power supply. > However > there are provisos on power via USB. For my own part, I find FTDI USB > interface chips good for anything I've wanted, and because the drivers are > widely, and well, supported, which matters to me as a Linux proponent. > The original revision, back in 2008, was to go to the PIC 18F4550 part. I changed the board to take power from USB, and to have fairly short traces for the USB data. I uploaded those EAGLE files<https://docs.google.com/open?id=0Bx35YZ-0A4ffajNRVzd0R1BxZVE> . I forgot about the FTDI part in the past 8 years. I dropped an FTDI daughterboard into a prototype board, and ran jumper wires over to my board. It worked really well. I have laid out artwork where that chip is on my board. I can't remember if I ordered that artwork or not. I seem to have a pipeline of built out prototypes, bare board prototypes, files with ECOs on them, files with unrelated projects that might fill an empty spot in a prototype run. It's getting too complex for me to manage. > > e) how much help did all of those LEDs provide you on the existing samples > of > the board? Are there better ways to communicate the same information? > > The LEDs let me and a group of students see what is going on very quickly and without any new tools intruding in the experience. If I directly solder them, the total support is only about USD $1.10 for the board. > I'll leave that as a starting point, and we'll see where it takes us... > > Arim > -- Aubrey McIntosh, Ph.D. 211 E. 5th St. Morris MN 56267 (512)-348-7401

2 1

The Oberon answer to Arduino
by Aubrey.McIntosh＠Alumni.UTexas.Net 03 Jan '13

03 Jan '13

I am getting some hard questions on my KickStarter project<http://www.kickstarter.com/projects/1378252804/681865516?token=bfb40102> . They are basically of the form, why would someone buy my item instead of an Arduino. These questions came from people I respect, whom I asked to comment, so I want to have a strong and respectful answer. I have done some reading, and I have read some pretty testy exchanges between some PIC enthusiasts and the Arduino enthusiasts. Basically, the Arduino folks say that being able to use their wire it up user interface is compelling and the PIC folks are in the past, and the PIC folks are saying that the libraries are closed and have some critical design bugs and they want an architecture where you can control stuff down to the bits. At one level, my project is about a teaching tool. However, just knowing about the parts is not enough. I want the project to also be a nicely designed tool. I suppose that I envision something like a programmers VOM. Something to program chips via ICSP, step through simple logic sequences, safely accept user programs to do innovative things. I suppose I have to add that it needs to fill a niche that the Arduino does not fill. So this brings to mind the question, should I go with a MIPS processor? They are available for about $5 each, and there is an Oberon compiler for them. There is a similar situation for the SPARC, the 68HC11, and other processors. It would be trivial to load commands in the Oberon environment to either of these processors. They would stay as part of the firmware, until they are freed up. There would have to be some small design change to have the code in EEPROM and the volatile data in RAM, including the initialization flags. .... So, does it make more sense to use the legacy, V4 Oberon system with a few communication tools thrown in to accomplish this? I am confident that I can pull this off, and I have done a lot of the background work to do so. Does it make more sense to update these compilers to the Component Pascal environment, so that there is a product with a lot of modern cross compilers, a nice IDE, and a custom made board that competes sort of laterally with the Arduino? I can envision an interface made out of something like Kepler and the Hardware compiler language whose name I can't remember, to make a complete system, but in the Oberon flavor. I think this could be the killer app that I have thought Oberon needed for the past 20 years. I hope you guys have an enlightened moment about this soon. I'd love to see a community project come together. -- Aubrey McIntosh, Ph.D. 211 E. 5th St. Morris MN 56267 (512)-348-7401

5 22

Re: [Oberon] The Oberon answer to Arduino
by Bernhard Treutwein 01 Jan '13

01 Jan '13

>> I wish I could be a catalyst to bring forth the "Killer Oberon App" >> but I don't see it happening. > > Perhaps a stand alone universal micro controller development system > (programmer, debugger, editor, compiler) written in Oberon. > jumping in lately ... having been just lurking ... hmm, ther is the .NET micro framework (see e.g.http://www.oberon.ch/netmf.html and Cuno Pfister's book mentioned there). And we have John Gough's Component Pascal (renamed Oberon/L) ... and we have BlackBox with its complete source ... Shouldn't it be possible to create something like BlackBox for .NETMF as killer app ... -- Bernhard

2 1

Someone else has a KickStarter PCB project
by Aubrey.McIntosh＠Alumni.UTexas.Net 31 Dec '12

31 Dec '12

Someone else has KickStarter project for a PCB<http://www.kickstarter.com/projects/628969371/isd-ioio-shield-dock> . -- Aubrey McIntosh, Ph.D. 211 E. 5th St. Morris MN 56267 (512)-348-7401

1 0

Towards a syntax directed editor: IDE
by eas lab 29 Dec '12

29 Dec '12

aka Old-paradigm rediscovered. The new paradigm/illusion, about 50 years old now, is commumicating via written memos, with little-man-in-box. The original/valid view of computers is of a multi-dimensional switch. All this talk about "typing and fingers" is absurd. The old railway-diagrams vividly emphasise that at all stages the next valid token is one of only-a-few; which is most economically [in effort] just selected from a menu. For new users, to see what few steps are needed: ---- Desktops.OpenDoc Find.Panel ~ use: reserved word *.Text => gives: Oberon.Report.Text 'served words listed below.' shows there are only 4*13+8=60 reserved words in Oberon. --- end of 3-step-log-demo for new users--- AFAICS, the only time for typing-and-fingers is for the special event of the user THOUGHTFULLY inventing a new identifier. Once invented, the identifier can belong to the menu, which could/should also be 'scoped'. Which seems to me to give a syntax-directed editor? Imagine each new language just being entered into its own data-file. Syntax coloring by several editors already are a step towards a syntax directed editor. Perhaps this won't work for dirty languages like bash or C++. How do dirty-languages manage syntax coloring? 'lisp' would be boring? Or perhaps not ! My simplest imagined input, for ETHO is that the token at the cursor [not caret, which requires an exta clik] is copied/appended to the source-text. The caret is an extra dimension and has memory and need not be wasted when the cursor will do. Q. does any ETHO code, other than <placing the mark>, use 'the cursor'? I want to copy existing code. Pet.Tool already gets close to this ability, with: } <shift> + space: select word at cursor } <ctrl> + '*': bold face word at cursor In fact it needs the caret and not just the cursor. I imagine: any-key-DOWN hi-lites the cursored-token, which can be viewed for confirmation before, that-key-released copies the token to the destination. So Pet seems to be a good starting point to evolve test code. But, LEO gives me only: System.Directory Pet.* == Pet.Obj And then LNO gives me only Pet.ReadMe and my rather big set of 357 *.Mod files in their separate partition of N-O has no Pet.Mod Q. was/is Pet.Mod available ? Of course it would be extended to copying whole structures from, the menu, corresponding to eg. Statement = [ Assignment | ProcedureCall | IfStatement | CaseStatement | \ WhileStatement | RepeatStatement | ForStatement | LoopStatement | WithStatement | EXIT |\ RETURN [Expression] ]. I find the railway-diagram-representation more intuitive. Of course this whole idea is already CONFIRMED by ETHO: you don't piano-play the keyboard like a journalist/novelist. You select, visually recognised [bigger than keys] items and assemble them. Let's just extend the good, proven method of ETHO. == TIA. Please criticise my idea. Early abandonment saves wasted effort. PS. LEO & presumable other ETHO has a nice -> System.Directory Scheme* which seems relevant to, programming via <selecting from the language's initial builtin list, and then from the evolving definitions>. PSS. Q. Is Scheme*.Mod available? How much ETHO source is hidden? Is there any policy that contributors' code must be open to be included in the distribution? PSSS. My thread about ARM:ETHO was not about hobby-size micro-controllers, but about: can we escape the WinTel monopoly and still have the magic of ETHO. It's the proven HumanComputerInterface that's important.

2 2

Re: [Oberon] The Oberon answer to Arduino
by peasthope＠shaw.ca 29 Dec '12

29 Dec '12

My mail server returned the Cc of this on December 26 but there is no evidence of it reaching the list. A second copy follows. ================== Aubrey, I admire your enthusiasm and effort; so don't take this as criticism. A collaborative or community project needs more "argument" before participants are convinced of a course of action. Inevitably some egos will be threatened or offended; some participants you might hope for, will take their toys and go home. From: <Aubrey.McIntosh(a)Alumni.UTexas.Net> Date: Mon, 24 Dec 2012 16:29:25 -0600 > ... the PIC folks are saying > that the libraries are closed and have some critical design bugs and they > want an architecture where you can control stuff down to the bits. Such as the XO? It's a complete machine including advanced Open Firmware to help with startup and debugging, good wireless and a display which can be read in broad daylight as well as in usual cave conditions. > At one level, my project is about a teaching tool. Precisely what OLPC is about! Of course that doesn't preclude other purposes. > So this brings to mind the question, should I go with a MIPS processor? > They are available for about $5 each, ... Whereas in G1G1 the XO is $400 and on eBay about $120. Apparently the policy in Uruguay is for every primary school child to have one. If Uruguayans can afford them, maybe people in industrialized countries can too. The difference between $5 and $120 is easily justified when you allow for the XO being a well designed complete machine with completely open specs; and allow that the cost of software surpasses the cost of hardware by orders orders of magnitude. > I'd love to see a community project come together. Many of us agree; but a big obstacle is that people are still pulling in too many directions. To solve this a consensus of focus is needed. First make a list of candidate hardwares. Then evaluate the pros and cons of each. Then decide an acceptable compromise.Then try to move it forward. Best Regards, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +13606390202 Bcc: peasthope at shaw.ca http://carnot.yi.org/ "http://members.shaw.ca/peasthope/index.html#Itinerary "

1 0

Re: [Oberon] The Oberon answer to Arduino
by Aubrey.McIntosh＠Alumni.UTexas.Net 27 Dec '12

27 Dec '12

On Wed, Dec 26, 2012 at 1:45 AM, Arnim Littek <arnim(a)actrix.gen.nz> wrote: > On Wednesday 26 December 2012 19:09:04 you wrote: > > I wrote this reply with the idea it might post to the entire group. If > you > > are ok with that, please make it so. > > I'll leave that to you. The degree to which you release information at > which > stage, is your call. You have in mind how much you'll release to the > Oberon > group, and the Kickstarter group... Ok, I'm going to copy the group, as I think discussion of an embedded project & Oberon is a natural interest area. I don't feel much need to be secretive with the Oberon group. If the KickStarter funding does make, it likely will be from people who follow KickStarter, not people who follow Oberon. > > I carefully did not mention Oberon in the KickStarter project. I think > > other people on this list are much better compiler talent. I thought > they > > might make suggestions for a board that would interest them. I thought > > they might suggest that I use a MIPS chip for my board, and make their > own > > KickStarter project to deliver a compiler and system compatible with it. > > And if not their own KickStarter project, then let me know if they are > > interested, and how much calendar time and what funding it would take to > > make it real, and I could try fit that in and hope. > > Hmm. Of course it is hard to know what other lurkers there are on the > list, > who (like me in this case) pop out of the woodwork on this occasion. > > > Yes. My thoughts are that the loader would put code into Flash, and most > > of the variables would live in RAM. I mis-spoke, I was using EEPROM as a > > shorthand for "stable but difficult to write to" memory. I am unsure > where > > the initialized flag and the pointer to additional modules would need to > be > > for the modules loaded by the bootloader. > > There are tradeoffs to be made, and some of these (speaking in terms of C > compilers for embedded systems) will involve what variable goes in what > storage. For some micros, running from Flash is pragmatic, because it is > nearly as fast as SRAM, but some micros really want stuff in SRAM if speed > is > an issue. Then loading variables from Flash to SRAM is part of the > package - > sometimes handled almost invisibly, with appropriate linker setup. I don't > know how Chris Burrows' products handle this, but presumably he must have > analogous memory management capability. > > > I have placed a .zip file on Google > > Docs<https://docs.google.com/open?id=0Bx35YZ-0A4ffTTR1ZlVlQmhxOXM>. > > At the moment, anyone with this link can grab a copy. The files named > > RS232_Control_5_003 are the EAGLE files for the legacy (16F877) board > from > > April 2004. This is what I will deliver for the KickStarter $5 reward. > > I'll see if I can go over it tonight. > > > The files named RS232_Explorer_5_002 are the EAGLE files for the > companion > > RS-232 explorer board. This is not promised in any of the KickStarter > > rewards. It is this board that is photographed toward the bottom of the > > project. > > > > The new (revision) board that I will make if the KickStarter project > funds > > does not exist. One of the KickStarter activities is that I will discuss > > the choice of CPU core before I make the board. That should be clear in > > the KickStarter language. If it is not clear, I need to hear about the > > confusion very clearly, and clarify the language so that no one can be > > confused. In principle, KickStarter is about a new way to cultivate > > creativity and not a store. > > I've got that message, but that doesn't mean everyone else has. > > > > I'm past through-hole electronics. For any prototype I'd build for > me, > > > I'd > > > prefer surface mount. Unless you go for more exotic packaging like > fine > > > pitch > > > QFN/DFN/BGA, they'll be easier to hand-place anyway. And any decent > > > sensor packages I'd want to hang off it will be SMT anyhow. > > > > I am very interested in the above comment. I made a daughter board for > the > > PIC32 evaluation board. I used the Hirose connector that Microchip used, > > and ran the lines out to 0.1" thru holes. I tried using a Bi/Sn/Cu/Ag > > solder to have something low melting. I could not buy any solder paste > > with Bismuth in it, so I used homemade (I'm a chemist). I had a fair > > amount of difficulty. It was completely impossible for me to solder > things > > that tiny. I always ended up with a blob that shorted everything. This > > was in 2008. I took the spare boards and had a board house assemble it > for > > me. I have new appreciation for the term FUBAR. > > > > I'm interested in a process that I can do in a home lab, or that students > > can do in a teaching lab. Do you think that 20 year old college students > > can work with SMT parts without needing high dollar equipment? > > You mentioned a senior electronics tech or something earlier on. Talk to > him > about solder flux and what it does for fine pitch ICs. It helps if the > soldering equipment is useful, but I use some fairly old gear at work, and > get > by. Good soldering iron tips that are designed for a particular role, make > complex-looking tasks quite simple, especially when applied with decent > solder > flux. The above assumes you have some temperature control over your iron > too. > > Decent solder helps. All good solder for fine pitch ICs has solder in the > core > - which runs out and tins your tip, as well as the electronics you're > soldering. Get fine solder too - fat solder is never used by > professionals. > The roll on my shelf here is 0.56mm, and I'd not use any bigger stuff for > my > private work. > > hmm. I suppose I should buy a cheap bag of out of spec parts and have another go at it. I suppose I could make a board that just repeats lots and lots of the PIC32 & the USB part artwork. Does anyone sell "practice your soldering" kits or does everyone John Wayne it? > > > Have you done anything Oberon-ish on the PIC16F877 target yet? I > can't > > > imagine that kind of pain.... But if you've done your previous work on > > > that > > > board in PIC asm, you have undergone all of it, esp. if you've done > > > enough code to start fiddling with their bank switching - Ugh. > > > > I have hand compiled Oberon code to run on the PIC16F877, to try to > develop > > the right code patterns. This was before I read Wirth's paper that > > announced an even smaller language for a different PIC part. I was ok > with > > all of the bank switching, and I had interrupt routines that worked in > that > > environment. (I think I feel a headache coming on with the memory.) I > > could probably make a compiler, but my skill level is so low I would take > > the rest of my life to finish it. > > For my money, almost any micro on the planet, 8 or 16 or 32 bit, has a > better > architecture and instruction set than PIC. The PIC architecture > propagates so > many bad habits - it should have been killed off at least a decade ago. > > And the C compiler tools are hobbled by the limitations of the > architecture, > and generally not of the highest quality, in my experience. Even the best > of > the lot, Hi-Tech, purchased by Microchip a year or two ago, has it's > problems. > I report bugs every time I do any real amount of work with it. > I like regularity, simplicity, completeness. I think the MIPS has that, but I have not done a survey of the other chips in the market. It is probably not good engineering to choose a chip based only on the cpu core. It is tempting to think that an Oberon system can push quality code onto the part in a clean environment. It is also tempting to think that it is ok to write all the code from the silicon on up in an embedded environment, so that the "lack of legacy code" does not matter. It is tempting to think that Component Pascal, with its paradoxical smaller number of productions but also extensions for large projects would be a good choice. Yet there is not proof of concept in the marketplace. > > I did bit bang RS-232 on 2 channels off the daughterboard. I monitored > all > > sorts of RS-232 signal lines, not only RX/TX. I don't remember if it > maxed > > out at 19,200 or 9,600. I recognize that this is not good performance, > and > > it demands too many signals to make a commercial project. The thing that > > it did do was to convince me that, for a short time, I actually > understood > > RS-232. > > bitbash has it's place, but UARTs are cheap on a decent micro. PICs have > never had them in oversupply.... like they never wanted to do any serious > comms. Some AVRs can be set up to have over half a dozen USARTs, all with > DMA > support, if you really want. They don't cost any more than PICs... Same > goes > for the ARM Cortex parts available from a dozen different silicon vendors, > if > you can climb the learning curve fast enough. That's where Chris B has > hands-on experience.... > > > I think that is what I am supposed to give students. They should > > understand stuff when they finish a project, so that they can have a > deeper > > understanding of the fancy stuff they use later in their career. > > Interesting that you, as a chemist, are foisting good hands-on embedded > systems experience on your students. > > > I don' t know how you'd get Chris Burrows to chime in - he's been there > > > and done a lot of this, it seems. > > > > I bet Chris would answer any question actually directed to him. Hi > Chris ! > > He does seem open and cooperative, rather than competitive/secretive sort. > > > Fire/Police/Emergency responders. I planned to use a display like the > B&N > > Nook, the ePaper stuff. This is all broad brush conceptual, I don't know > > if the PIC32 has enough output signals to interface with the ePaper > > displays. I have lived most of my life in Hurricane country, > > The PIC32 family has grown since 2008, and LCD displays are on their list, > although I am not familiar, since I don't design in displays in my normal > course of activities, work or otherwise. > > > Thank you for your comments. And, as you have noticed, my KickStarter > > project is absolutely silent on Oberon. I want to keep the KickStarter > > promises fairly minimal. > > Your comments on managing scope apply also in the commercial world. > Managing > expectations is not a trivial task. > Yeah. Opening up design questions in a KickStarter project runs the risk of making some people think I'm indecisive while I'm hearding cats and pulling out my hair. > > I'll go look at your schematic shortly, > > Arnim. > -- Aubrey McIntosh, Ph.D. 211 E. 5th St. Morris MN 56267 (512)-348-7401

2 1

Re: [Oberon] The Oberon answer to Arduino
by peasthope＠shaw.ca 26 Dec '12

26 Dec '12

Aubrey, I admire your enthusiasm and effort; so don't take this as criticism. A collaborative or community project needs much more "argument" before participants are convinced of a course of action. Inevitably some egos will be threatened or offended; some participants you might hope for, will take their toys and go home. From: <Aubrey.McIntosh(a)Alumni.UTexas.Net> Date: Mon, 24 Dec 2012 16:29:25 -0600 > ... the PIC folks are saying > that the libraries are closed and have some critical design bugs and they > want an architecture where you can control stuff down to the bits. Such as the XO? It's a complete machine including advanced Open Firmware to help with startup and debugging, good wireless and a display which can be read in broad daylight as well as in usual cave conditions. > At one level, my project is about a teaching tool. Precisely what OLPC is about! Of course that doesn't preclude other purposes. > So this brings to mind the question, should I go with a MIPS processor? > They are available for about $5 each, ... Whereas in G1G1 the XO is $400 and on eBay about $120. Apparently the policy in Uruguay is for every primary school child to have one. If Uruguayans can afford them, maybe people in industrialized countries can too. The difference between $5 and $400 or $120 is easily justified when you allow for the XO being a well designed complete machine with completely open specs; and allow that the cost of software surpasses the cost of hardware by orders orders of magnitude. > I'd love to see a community project come together. Many of us agree; but a big obstacle is that people are still pulling in too many directions. To solve this we need to find a consensus of focus. First make a list of candidate hardwares. Then evaluate the pros and cons of each. Then decide an acceptable compromise. Then try to move it forward. Best Regards, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +13606390202 Bcc: peasthope at shaw.ca http://carnot.yi.org/ "http://members.shaw.ca/peasthope/index.html#Itinerary "

1 0

Oberon Digest, Vol 104, выпуск 22 (Guenter Dotzel)
by vic 26 Dec '12

26 Dec '12

26.12.2012 13:00, oberon-request(a)lists.inf.ethz.ch >Send Oberon mailing list submissions to > oberon(a)lists.inf.ethz.ch > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.inf.ethz.ch/mailman/listinfo/oberon > or, via email, send a message with subject or body 'help' to > oberon-request(a)lists.inf.ethz.ch > > You can reach the person managing the list at > oberon-owner(a)lists.inf.ethz.ch > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Oberon digest..." > > > Today's Topics: > > 1. Re: Oberon Digest, Vol 104, Issue 22 (Guenter Dotzel) > 2. Re: The Oberon answer to Arduino (Jan Verhoeven) > 3. Re: The Oberon answer to Arduino (Arnim Littek) > 4. Re: The Oberon answer to Arduino (Jan Verhoeven) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 25 Dec 2012 12:04:37 +0100 > From: Guenter Dotzel <gd(a)modulaware.com> > Subject: Re: [Oberon] Oberon Digest, Vol 104, Issue 22 > To: oberon(a)lists.inf.ethz.ch > Message-ID: <50D98845.2030108(a)modulaware.com> > Content-Type: text/plain; charset=UTF-8 > > I already tried recently but failed badly to encourage people on this list to only quote what is really essential to see what you are replying to. > > > > ------------------------------ > > Message: 2 > Date: Tue, 25 Dec 2012 17:43:39 +0100 > From: Jan Verhoeven <jan(a)verhoeven272.nl> > Subject: Re: [Oberon] The Oberon answer to Arduino > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Message-ID: <201212251743.39145.jan(a)verhoeven272.nl> > Content-Type: text/plain; charset="utf-8" > > On Monday 24 December 2012 23:29:25 Aubrey.McIntosh(a)alumni.utexas.net > wrote: > > I am getting some hard questions on my KickStarter > > Which was to be expected. Easy money is gone down the drain since the > americans sold out-of-control-mortgages to european banks. And they > believed them! > > > why would someone buy my item instead of an Arduino. > > They won't. Your project breaths just one thing: hobbyist. Nobody will > invest a penny in it. > > The arduino was at the right time in the right place among the right > kind of people using the right kind of tools. > I was there long time ago. And was too soon (and the wrong audience). > You are too late. You cannot catch up with Arduino. Arduino is a mature > system with a large installed user base. Websites, wiki's, third party > suppliers, available on dealextreme. Yours is a nice idea, at most. > > The days of designing your own hardware to sell to others are over (for > over a decade). Arduino was in the nick of time and within the right > (braindead) audience. > Have you seen this: http://www.futurlec.com/ET-PIC_Stamp.shtml > > ETT have a lot of affordable MCU circuits, off the shelf. These boards > work. No need to debug the hardware (as is still the case in your > Controls, I guess), just focus on the software. > > AVR : PIC = Cat : Dog > > > I suppose that I envision something like a programmers VOM. Something > > to program chips via ICSP, step through simple logic sequences, safely > > accept user programs to do innovative things. > > Ah, you mean http://www.futurlec.com/ET-ARM_Stamp_Board.shtml > > Try to beat that at USD 25. You don't want to know how ridiculously > cheap airmail rates from Thailand are. http://www.ett.co.th/ > > > So this brings to mind the question, should I go with a MIPS > > processor? > > Go with Futurlec. They supply working boards for the price of the CPU > plus the bare board. > > > compilers to the Component Pascal environment, > > Nope. There used to be a Mod51 Modula-2 compiler for the 8051. Not sure > if they sold a single copy of it. > > > board that competes sort of laterally with the Arduino? > > Not in your life time. It's not very polite to say so, but if I would > say the opposite I would be gambling with your money. > > > I think this could be the killer app that I have thought Oberon > > needed for the past 20 years. > > The days of Oberon are over. If Oberon HAD days at all. It's a fun issue > reading about and talking about. But nobody wants to program a > controller in a safe way. A controller is programmed in assembler so > you can do whatever you want. > If things get hairy, you buy a creditcard sized PC and there Oberon may > come in handy. > > > I hope you guys have an enlightened moment about this soon. I'd love > > to see a community project come together. > > Look at embedded artists. Can you come up with something like this? > http://embeddedartists.com/products/boards/lpc11d14_qsb.php > > I know the answer to my question. No single developer can. Look at the > price and the features. > > -- > Met vriendelijke groeten, > > Jan Verhoeven > http://www.verhoeven272.nl > > > > ------------------------------ > > Message: 3 > Date: Wed, 26 Dec 2012 12:55:27 +1300 > From: Arnim Littek <arnim(a)actrix.gen.nz> > Subject: Re: [Oberon] The Oberon answer to Arduino > To: oberon(a)lists.inf.ethz.ch > Message-ID: <201212261255.27430.arnim(a)actrix.gen.nz> > Content-Type: Text/Plain; charset="iso-8859-15" > > Interesting thread. I've been lurking on the Oberon list for years - this is > the first to elicit a response. > > What makes Oberon attractive? The ability to go to high level programming > with less fuss and code infrastructure than most languages. The fact that it > can be taken to low levels is also particularly attractive to the kinds of > folk interested in Arduinos and PICs. > > Some Arduinos are built on interesting micros, all Arduinos are built on > micros better than the 8-bit PICs, which are IMHO relics of the past that > belong in a museum. (Unfortunately I have to work with them professionally - > cough cough) > > However, the PIC32 on the MIPS architecture is likely to be a completely > different beast - I've looked at it for a long time without finding reason to go > there, because the PIC32 engines don't do low power all that well (yet?). I > do like MIPS, and think that would be in some senses, esp. in terms of > teaching, a better platform than the low power ARM micros in the same space. > > MIPS support is wider than Microchip, fortunately. Making a decent compiler > for MIPS is realistic, and adding Oberon to the list could be a good thing for > many people, including those of us on this list with an embedded slant. > > Arnim > > On Tuesday 25 December 2012 11:29:25 Aubrey.McIntosh(a)alumni.utexas.net wrote: > > I am getting some hard questions on my KickStarter > > project<http://www.kickstarter.com/projects/1378252804/681865516?token=bfb4 > > 0102> . > > > > They are basically of the form, why would someone buy my item instead of an > > Arduino. These questions came from people I respect, whom I asked to > > comment, so I want to have a strong and respectful answer. > > > > I have done some reading, and I have read some pretty testy exchanges > > between some PIC enthusiasts and the Arduino enthusiasts. Basically, the > > Arduino folks say that being able to use their wire it up user interface is > > compelling and the PIC folks are in the past, and the PIC folks are saying > > that the libraries are closed and have some critical design bugs and they > > want an architecture where you can control stuff down to the bits. > > > > At one level, my project is about a teaching tool. However, just knowing > > about the parts is not enough. I want the project to also be a nicely > > designed tool. I suppose that I envision something like a programmers VOM. > > Something to program chips via ICSP, step through simple logic sequences, > > safely accept user programs to do innovative things. > > > > I suppose I have to add that it needs to fill a niche that the Arduino does > > not fill. > > > > So this brings to mind the question, should I go with a MIPS processor? > > They are available for about $5 each, and there is an Oberon compiler for > > them. There is a similar situation for the SPARC, the 68HC11, and other > > processors. > > > > It would be trivial to load commands in the Oberon environment to either of > > these processors. They would stay as part of the firmware, until they are > > freed up. There would have to be some small design change to have the code > > in EEPROM and the volatile data in RAM, including the initialization flags. > > > > .... > > > > So, does it make more sense to use the legacy, V4 Oberon system with a few > > communication tools thrown in to accomplish this? I am confident that I > > can pull this off, and I have done a lot of the background work to do so. > > > > Does it make more sense to update these compilers to the Component Pascal > > environment, so that there is a product with a lot of modern cross > > compilers, a nice IDE, and a custom made board that competes sort of > > laterally with the Arduino? > > > > I can envision an interface made out of something like Kepler and the > > Hardware compiler language whose name I can't remember, to make a complete > > system, but in the Oberon flavor. > > > > I think this could be the killer app that I have thought Oberon needed for > > the past 20 years. I hope you guys have an enlightened moment about this > > soon. I'd love to see a community project come together. > > > > ------------------------------ > > Message: 4 > Date: Wed, 26 Dec 2012 02:05:32 +0100 > From: Jan Verhoeven <jan(a)verhoeven272.nl> > Subject: Re: [Oberon] The Oberon answer to Arduino > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Message-ID: <201212260205.33026.jan(a)verhoeven272.nl> > Content-Type: text/plain; charset="iso-8859-1" > > On Wednesday 26 December 2012 00:55:27 Arnim Littek wrote: > > Interesting thread. I've been lurking on the Oberon list for years - > > this is the first to elicit a response. > > Arnim > > And now for the $6000 question: will YOU buy it, HERE and NOW? > > Because that's the only thing that counts. Positive feedback does not > work, as you might have experienced. > > -- > Met vriendelijke groeten, > > Jan Verhoeven > http://www.verhoeven272.nl > > > > ------------------------------ > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon > > > End of Oberon Digest, Vol 104, Issue 23 > *************************************** -- реклама ----------------------------------------------------------- Акция в Книжном Клубе - мировые бестселлеры по 10 грн! Доставка почтой. Оплата по факту http://bookclub.ua/join/

1 0