 | | Something else is needed, I think...
|
|
I'm just wondering how many people agree with me on this point... I think that another code development system is needed for the RCX. Why? Well, it seems like everything that's already out there is either overkill (legos, pbforth for rcx), or (...) (26 years ago, 2-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) Sorry to disagree, but I think we already have a very good range of developing systems: (1) The LEGO software for newbies, (2) RcxCC + NQC + Spirit.ocx for the large majority of the projects, and (3) LegOS for those who want to go beyond the (...) (26 years ago, 2-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
I think this was only mentioned on the legos mailing list, but there are now two web-based compilers for LegOS. Write the code on whatever text based system you have, cut and paste it into a form on the web, and voila! Get a .srec file mailed back (...) (26 years ago, 2-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) ^^^...^^^ That is exactly the point that I was trying to make. (...) Again, though, such a system would bear the incredible weight of having a full-blown C/C++ cross-compiler and linking system as being part of the package. Making legos (...) (26 years ago, 2-May-99, to lugnet.robotics)
|
| |
| | RE: Something else is needed, I think...(long)
|
|
(...) I think there IS a bridge, and it's pbFORTH (and since I wrote it I like it :) Here is why I think the current pbFORTH is like the bridge you describe: 1. You don't need the GNU compiler set up to use pbFORTH. I used it to originally write (...) (26 years ago, 2-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) Well, that was what I thought, and I set out to do such a thing way back at the beginning. But the lack of enthusiasm was amazing (possibly not for the basic concept; the alternative hypothesis is that, since I'm a programming language (...) (26 years ago, 2-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) The point is that you still need some OS running on the bare hardware. The standard firmware isn't going to let you do what you need, and you still need something like LegOS anyway. Unless you want to recreate an OS from scratch (which is a (...) (26 years ago, 2-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) two radically different premises -- the former requiring nothing beyond the hardware, the latter requiring the hardware and an acknowledgeably limited firmware. It would seem to me that what lies exactly in the middle is something which (...) (26 years ago, 2-May-99, to lugnet.robotics)
|
| |
| | LegOS HOWTO
|
|
Considering the recent discussion on this list, I figure this is as good a time as any to point out that my LegOS HOWTO is now posted at (URL) don't be intimidated! I have aimed this page squarely at anyone with a bare minimum of C or C++ (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) I agree on this point. I've been forced to move to legOS not by intrinsic NQC limitations but by those imposed by the RCX firmware. I still prefer to use RcxCC/NQC when I don't need legOS: programs load much faster, it's a pleasant and (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) I don't know if you guys realize this but if anything like this is ever done we must definitely remain compatible (at least partially) with Spirit.ocx protocols. The Spirit.ocx control is a HUGE bonus we must not throw away!! It makes possible (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) we must definitely remain compatible (at least partially) with Spirit.ocx protocols. (...) outside world with endless possibilities, and processing power that it will never be able to match! (...) already been done for us. And please, do not (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) I am not sure how much you can extend the capabilities of the firmware while maintaining its basic dispatch loop. There are some very basic design constraints that would be difficult to change without redoing all of the firmware. If you (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...(long)
|
|
In article <000101be94cb$a8fd58...a@pro150>, Ralph Hempel <rhempel@bmts.com> writes (...) My QBasic program available from www.phesk.demon.co.uk/lego/ can download the Lego firmware from DOS - where can I find your new firmware to test it with, (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) If you believe you have good ideas for a language, my opinion is that you should propose something to the list, find people who want to work with you on this (assuming you don't want to work alone), ignore the people who say you know nothing (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) I think new firmware is a good way to go. I would vote for a completely new byte code, perhaps similar in spirit to the original, but designed fresh from the ground up. There is no source for the current firmware, although there is pseudocode (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) If you really want to design a new bytecode that is completely flexible, I suggest using the millions of manhours put into the Java Virtual Machine would be worthwhile. I looked at the idea of porting JVM to the RCX briefly before, but decided (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | RE: Something else is needed, I think...
|
|
(...) If we are going to the trouble of new bytecode, then we need a new compiler. If we design a new compiler, then what language will it be? Yes, we could use C as the base and compile to pcode which is essentially what NQC does if I'm not (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) My thoughts on the JVM: - too complicated for what we need or want - no direct support for interfacing with the RCX I envision the new byte code being specific to the RCX, and as simple as possible to get the job done, which is the exact (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) C may be the best choice for a base language to start with simply because its well known. Quite frankly, if the bytecode is written reasonably well, different compilers for different base languages should be very feasible - compilers based on (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) I agree, that would make pbForth much more appealing if the source could be compiled on a pc in a nice gui environment and then the bytecode loaded into the rcx. Not only could someone enhance the gui front end as Mark has suggested, but (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) I guess that depends on who you talk to. Personally, I want an object oriented language with multithreading support. I want to be able to write generic code that can be reused in multiple applications (ie, here is a module that follows a line, (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | RE: Something else is needed, I think...
|
|
(...) Do NOT underestimate the amount of work we are talking about. I took a working version of hFORTH for the PC and ported a few machine specific definitions and rewrote the IO drivers and debugged and tested using GNU tools, and I have 80 hours (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | RE: Something else is needed, I think...
|
|
(...) Once you get around the idea that the RCX does the compiling which makes it platform independent, you will see the light... (...) This is a good plan. You have my full support :-) Cheers, Ralph Hempel - P.Eng ---...--- Check out pbFORTH for (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | RE: Something else is needed, I think...
|
|
Maybe we could write a program that compiles c source code into forth :) just joking Joel Shafer joel@connect.net -- Did you check the web site first?: (URL) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) Thank you. Kekoa. I was starting to think I was completely alone in my attitudes. Just a couple of comments on what I think a new byte code should do or be 1) It should resemble machine language. The commands in the bytecode should be (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) I don't deny that these are reasonable things to want. But you don't need the JVM to get these. The problem with the JVM is that there is so much extra fluff associated with Java. You mentioned 64-bit floats and ints, security, etc. Why start (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) Basically what you are talking about at this level is an interpreted machine language. The only benefit you get from interpreting it rather than running directly on the hardware is that you can catch errors. However, if the bytecodes are (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) All I am saying is that there will be no existing product that does exactly what everyone wants. However, I think it is worth considering JVM as a starting point close to what we want since it represents a huge body of solid code. (...) (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) I don't think I am underestimating the amount of work, actually.Just because a language has a GUI toolkit does NOT make it user friendly or portable. (...) Then it's not self contained on TWO counts. One, as you mentioned, you need NQC to get (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) Yes. (...) Wrong. Because we could design the instruction set from scratch ourselves, a small set of instructions could be included in the entire instruction set which do things require a great deal of regular machine instructions to do. (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) Q: How large are the compiled FP emulation routines for the RCX? -Kekoa (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | RE: Something else is needed, I think...
|
|
Kekoa wrote: <actually he wrote stuff here that I snipped out> (...) Ah, a refreshing viewpoint :-) Getting concrete ideas and proposals out makes sense. If you don't have the time to propose a CONCRETE idea or plan, then you sure don't have time to (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) Well, having a bytecode for turning on a motor seems little benefit compared to calling a library function to do it. From the user's point of view, the effort and the result are similar. (...) Actually, you need to have a call stack and a (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) Maybe the JVM is, in spirit, close to what we want; but can you honestly say that porting the JVM to the RCX will be easier than writing something from scratch, perhaps using some of the better features of the JVM as inspiration? I personally (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) Total .text section is 5832 bytes, .rodata is 4 bytes, and .bss is 8 bytes. This is for all for all of the FP emulation routines, only those actually used will be linked in. This is only the helper routines, not anything from the math library. (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) Sorry to step in here. But there is no difference (as I see it) between having a system library function that runs the motors and having a byte code that runs the motors. It's all a matter of encoding. If I say: set_motor_speed(MOTOR1, 20); (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) This is good to know, I now know that any byte code interpreter that uses floating point will have to devote on the order of (at least) 6K to floating point if it wants to support floating point. Considering that any interpreter that uses the (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) I guess it depends on what you want in your firmware. I have been working on my own object-oriented kernel, and I have written an object-oriented kernel for an embedded I/O controller before, and it is a big job. That is just the OS, not (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) That was my point, that it was not a benefit for having an interpreted "machine language" over using native machine language. The only benefits are portability and error checking, and the error checking is problematic when you get to that low (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) So this is a nice start at least. Regarding things you like, I'm going to ignore 1) and 6) because they are not features of byte code, they are features of Java; you either use the JVM and you get them, or you do not use the JVM and you do not (...) (26 years ago, 3-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) For reference, the JVM specification is available online at this URL: (URL) are several features that promote compactness: 1) it is a stack-based bytecode. Operands are pushed onto the stack, a bytecode is executed, and results are pushed onto (...) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
Mark Tarrabain: Dave Baum: John A. Tamplin: Kekoa Proudfoot: Ralph Hempel: Luis Villa: et al: In the late '60s I had a '57 VW Bug ... absolutely loved it! But, it didn't go fast enough. So I replaced the engine with a 1500 cc. model. It went faster, (...) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | RE: Something else is needed, I think...
|
|
Nick wrote: (using embedded HTML!!!!) (...) Right you are, Nick. I'm the guy that kept discouraging do-it-yourself "general" solutions just before the RCX came out. Then I wrote pbFORTH ..... I've never even cracked the wrapper on my LEGO Mindstorms (...) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
Stephen's view: -> We want something higher level than FORTH or C so that it will be usable by *everyone*. We also want something higher level than NQC so it will be *usable* by everyone. In short, for semantic level we'd like something that puts (...) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) I say Java is the way to go, actually I am planning to do a JVM for the RCX. The JVM is not necessarily complex, It is possible to do a subset, SUN already does that with the JavaCard specification (that is Java running on smartcards). This (...) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) classes (...) Yes but in regard to 1) we do not have to implement a compiler, they arer already there, all we need is the VM. (...) There is a stack and a PC. (...) No way, OS/hardware specific stuff should be in the RCX specific (...) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
I say let us go ahead and make this JVM for the RCX. I am in, Any other volunteers? As I have previously announced (in the LegOS) group that I was going to do this one person has already agreed to volunteer. As a side note take a look at: (URL) (...) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | IR towers
|
|
Where can you buy more IR towers? -- Richard Clemens Associate Professor Computer Science Department West Virginia Wesleyan College Buckhannon, West Virginia 26201 clemens@wvwc.edu 304.473.8421 -- Did you check the web site first?: (URL) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | Re: IR towers
|
|
Rich Clemens wrote: <snip> (...) Rich: Dacta has them: Tower & cable #N979713 for US$25. 800.362.4308 - - - Nick - - - -- Did you check the web site first?: (URL) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
Java is a very good language, but *NOT* a very good choice of language for robot control. Java's greatest strength is its portability, but portable programs in hardware like the RCX, are not likely to accomplish much. (Have you ever tried to write a (...) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) JavaCard is highly specialized to a SmartCard application. As far as I know, the only way to communicate with a JavaCard interpreter is through the ISO APDU mechanism. You also don't have computation running in the background, since applets (...) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
Mark Tarrabain skrev i meddelandet <372E220C.D2F9AD52@l....bc.ca>... (...) But the whole point with FORTH is that it is self-contained, and the 'compiling' part is an integrated part of the language (normally quite small), and _used_ in programs, (...) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) Don't forget writing the bytecode interpreter. With JVM, we just have to port that. Writing a bytecode interpreter that is fast, general purpose, supports multithreading & synchronization etc. is no small task. (...) Java would not be used for (...) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | RCX and Java
|
|
Aren't robots real time systems? Isn't the RCX meant to be a component in such real time systems? Java (as implemented by current virtual machines) is NOT suitable as a platform for building real time systems. The implementation of garbage (...) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) ??? I think you are making a new interpreter sound harder than it really is. The standard firmware might not be incredibly fast, but it certainly supports multithreading, and synchronization wouldn't be hard to add. The only challenging thing (...) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | Re: RCX and Java
|
|
(...) I doubt anyone is considering using the RCX with any OS/language in a hard real-time system. The original firmware nor any of the replacements make the proper guarantees required for such a system (ie, a deadline-based scheduler), and I have (...) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) I think the basic issue here is we have different ideas in what we want in this interpreted language. You seem to want something closer to the current bytecode, while I want something closer to Java/C++. Certainly if you lower the requirements (...) (26 years ago, 4-May-99, to lugnet.robotics)
|
| |
| | Re: RCX and Java
|
|
Has anyone thought of porting OS9 to the RCX. OS9 is a multi-processing, multi-tasking, pre-empted OS that can be put into ROM. It is also a 8 bit OS. Uses Pascal, Basic, Assembly, & C for writing code. Level 1 OS9 fits perfectly into 32K of memory (...) (26 years ago, 5-May-99, to lugnet.robotics)
|
| |
| | Re: RCX and Java
|
|
(...) You are provoking me:-) At Enea we are thinking of porting OSE Basic to the RCX. OSE is a multi- processing, multi-tasking, pre-empted OS that can be put into ROM. OSE Basic is a version suitable for 8 or 16 bit microcontrollers with limited (...) (26 years ago, 5-May-99, to lugnet.robotics)
|
| |
| | Re: RCX and Java
|
|
I gather then, you know what OS9 is. I have been using OS9 Level I & II, OS9-68K and OS9-X86 for over 10 years. Sound like OSE is very much like OS9. OS9 was developed by Microware for embedded comtrolers like the H8. JAD (...) (26 years ago, 5-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) already (...) smartcards). (...) That is right, but this is mainly enforced by the class library, which offcourse will have to be way different for the RCX. What I was getting at was that we do not need to implement the whole java bytecode (...) (26 years ago, 5-May-99, to lugnet.robotics)
|
| |
| | Re: RCX and Java
|
|
(...) FYI I have been involved in two (big) projects using java for controlling industrial production one is used to control high speed sorting systems the other for controlling packing of newspapers comming directly from the rotation press. And yes (...) (26 years ago, 5-May-99, to lugnet.robotics)
|
| |
| | Re: RCX and Java
|
|
(...) When making a GSM call setup the latency for the call going into a base station/base station controller and out into the next in the chain is 20ms. If you fail you break the GSM specification. How are you going to guarantee that with Java? (...) (26 years ago, 5-May-99, to lugnet.robotics)
|
| |
| | Re: Something else is needed, I think...
|
|
(...) You could certainly throw some sort of "unsupported" exception when you see a d* bytecode, but the biggest issues aren't implementing 64-bit ints and floats but rather garbage collection and threading. JC doesn't require either, but some (...) (26 years ago, 5-May-99, to lugnet.robotics)
|
| |
| | Re: RCX and Java
|
|
(...) I don't think anyone is suggesting that Java is appropriate for a hard-realtime system. Personally, I would expect nothing less than an RTOS with a deadline-based scheduler and a low-level language. However, I think the RCX does not have any (...) (26 years ago, 5-May-99, to lugnet.robotics)
|
| |
| | Re: RCX and Java
|
|
(...) rotation (...) No, java was picked because the company did not wan't to use C++ as it had some bad experience with projects taking way too long to complete. It had used Visual basic (yieek) before but it tended to be slow and the code was not (...) (26 years ago, 10-May-99, to lugnet.robotics)
|
