February 2016 - Oberon - mailman3.inf.ethz.ch

Pepino LX9, USB, and other hardware running OBERON
by Lars 20 Feb '16

20 Feb '16

Since the Pepino LX9 has USB, does this mean someone actually wrote drivers for USB for Oberon? I thought it was too large of a project and too difficult to implement USB. Or does the pepino, when running oberon OS, simply not utilize USB and that's for other Operating systems? http://saanlima.com/store/index.php?route=product/product&product_id=64 I'm confused as I thought Oberon system was against complexities such as USB, so how does Pepino USB work with oberon? Additionally, what other hardware is available that runs oberon operating system? So far we have: OberonStation Pepino LX9 Are there more?

5 7

Re: [Oberon] strings in oberon-07
by Lars 20 Feb '16

20 Feb '16

On Tue, February 16, 2016 5:36 am, Guenter Dotzel wrote: > Lars, > here's a recent string handling/website example: > > http://www.modulaware.com/mdlt/index.php?n=98&width=1920&height=1067 Hi, thanks. I am going to reread it as I have just skimmed over it. I did not find the word "concat" anywhere on the page. From what I remember long ago Wojtek once complained about having to do CONCAT() everywhere in his code, or something similar, on a usenet post instead of just going stringa + stringb + stringc write in the code, inline, without all the concat calls which does not improve readability. The plus sign is not the required operator, it could be "&" or whatever. Oberon doesnt have a way to write operator code, as that would be operator overloading like in FPC or C.. and is against such features. So you are stuck with Oberon module with limited ability. How do you solve the CONCAT problem. I did not see it discussed in your article, but I just skimmed it so far, and will re-read. Lars Real World Programmer Concatting strings since, 1983, when I first burped or cried.

2 1

Re: [Oberon] Preaching against USB
by skulski＠pas.rochester.edu 20 Feb '16

20 Feb '16

Ken: so you are preaching against USB! Good! > The FX2 is a 8051 based microcontroller Yes it is. It is an "enhanced 8051" with 4 clock cycles per instruction. The most important part of the FX2 is its USB part, which is a specialized coprocessor which handles the USB on its own. Thus the 8051 only has to set it up and then get out of the way. BTW, the new FX3 now uses ARM rather than the 8051. > You need to get hold of the C compiler - Keil uVision - at whatever cost. In many projects the cost is zero because Keil compiler was a part of the Cypress development kit. It was limited to 4kB code, which is enough for many projects. If you need more code then you have to buy the full compiler. > You have to fight your way around the 8051 architecture. Sure. Same with any architecture you are using. RISC5 is no exception. If you are doing something then you need to know what you are doing. Unfortunately. > I never did come to terms with the code that ran the USB > - I just accepted that was present on the device, > and tried to concentrate on getting my application to work. Sure. That's what most programmers do. > I ended up implementing bit-banged SPI on the FX2 SPI is one of the hardware modes of the 8051 serial port. If you read that part of the FX2 manual (which is outstanding) then you could set the port to the SPI mode. SPI would then be handled in hardware. I usually read manuals, so I discovered that feature and I used it. > Did I learn anything useful about USB from my FX2 experience? > - just never use an 8051 or FX2 ever again! My experience was the opposite. 8051 is a great part. Very well documented. The FX2 is exceptionally well done. The documentation was outstanding. The Cypress support was very good. They answered all my questions. My experience was very positive. > The FX2 adds about $5 the product. There's really no place > left for it nowadays when you can by an easy to use USB > to serial converter IC for under $0.50, and every ARM > chip from $1.50 upwards has USB on chip. Times are changing. It is called progress. On the other hand, 8051 is a very capable chip. I highly recommend asking Keil to send you a free CD with their free 8051 compiler, if they are still offering the CD. This compiler is limited to 2kB, so the Cypress version was better (4kB limit). However, there was one treasure on that CD: a very comprehensive book on 8051. A glorious book. Unfortunately, the title page was missing, so I do not know who wrote it. The concluding chapter of that book discussed fuzzy logic implementation on 8051. This chapter justified reading the whole book. I learned a lot! > I am a solid proponent of keep it simple. I am a proponent of reading the manuals... Many of them are very well written and worth studying. You may even start liking the 8051 after you see how well documented it is. BTW, the Michael Pont book is about 8051. I still highly recommend reading that book because it is in many respects as good as any Wirth book. Do not get discouraged by the 8051. It is the clarity of thinking that matters. Thank you, Wojtek

3 2

Re: [Oberon] RISC5 implementation issues.
by skulski＠pas.rochester.edu 20 Feb '16

20 Feb '16

Paul wrote: >FPGAs are a little off-topic for many Oberoners Should not be if we want to advance the FPGA Oberon. We may consider a separate mailing list if the community does not want to see FPGA discussions. Otherwise they have to bear with the HW engineers. > I agree with Magnus, the tools add the relevant clock buffer > as part of their job, and the source code is kept simple and clear. The RISC5 code only looks simple and clear, but in fact it is not. The very fact that you need to refer to the FPGA editor proves that lots of details are hidden under the rug. We analyzed the RISC5 code at SkuTek and our conclusions were much the same as Walter's. Speaking on behalf of our electrical engineer Dave, some parts of the code seem to rely on unspecified timing relations between the signals. The core works due to particulars of a given FPGA and the current FPGA compiler. If this is true then the core is not portable. > Hopefully the below simple hardware LED counter for the Spartan 3 > board (easily adapted to almost any other board!) might be indulged, > and interesting for enough people :) Simple circuits like this are interesting, but if one wants to learn FPGA programming then I would rather treat this topic more seriously. I either recommend a systematic approach by reading a few books, or perhaps open a serious discussion on the RISC5 architecture and implementation. RISC5 deserves a similar level of detail as PicoBlaze, which is of a similar level of complexity. In both cases the printed documentation is similarly good. But if you look at the Picoblaze code, you will see a great example of well structured and well documented code. If you look at RISC5, to me the code seems to be terse and obfuscated. I would welcome a well structured, well commented code of the fundamental part of the Oberon System. Also, RISC5 deserves having both the Verilog and VHDL implementations. We can start with an automated translation and go from there. Finally, I would welcome the participation of The Chief Justice in our discussions. A glaring difference between PicoBlaze and RISC5 is that their Chief Justice is participating in the community. Our Chief Justice is only showing his back to us. He is not helping the case. A simple counter example: Concerning the counter code below, I am puzzled by the statement "always @(posedge CLK50M) clk <= ~clk;". If I understand the intent, it creates a signal that is controlled by CLK50M. Why not use the CLK50M directly? You can run the counter at the CLK50M frequency and use higher order bits. On the other hand, if you are saying "no, I cannot do this, so I have to divide clock because of timing" -- well, you have just proven the point that this seemingly simple code has issues that extend well beyond the apparent simplicity. Welcome to the real world of FPGA programming! But then, do not say it is simple. It requires a systematic approach, explaining the implementation issues, timing issues, perhaps routing and implementation implications, etc. It is exactly what Walter is saying and we fully support. Do not say that not simple is simple, because it only creates confusion. Wojtek -------------------------------- (test.v) `timescale 1ns / 1ps module TestTop( input CLK50M, //50MHz output [7:0] leds); reg clk; reg [31:0] cnt; assign leds = cnt[31:24]; always @(posedge clk) //25MHz cnt <= cnt + 1; always @(posedge CLK50M) clk <= ~clk; endmodule (test.ucf) NET "CLK50M" LOC = "T9" ; NET "leds[0]" LOC = "K12"; NET "leds[1]" LOC = "P14"; NET "leds[2]" LOC = "L12"; NET "leds[3]" LOC = "N14"; NET "leds[4]" LOC = "P13"; NET "leds[5]" LOC = "N12"; NET "leds[6]" LOC = "P12"; NET "leds[7]" LOC = "P11"; -- Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mail…

2 1

Preaching against USB
by skulski＠pas.rochester.edu 20 Feb '16

20 Feb '16

enso wrote: >[USB] requires a working computer system with substantial resources, > the opposite of what you need in an embedded or experimental system. Not true. I built embedded systems with EZ-USB from Cypress. It is a very popular chip originally developed by Anchor which Cypress acquired. I used the FX and FX2 versions. (The newest version is FX3.) The working USB system consists of a single chip plus a few capacitors. There are no "substantial resources" involved. The chip has 16 kB RAM and it is enough for a very substantial project. The FX2 software can be very simple because most of the USB protocol is handled internally by the ASIC part of the chip. A page or two of code is sufficient for a simple system. Example software is provided in FX2 documentation. A more complex one can use an embedded OS which Cypress named Frameworks. It is neat, small, well written in plain C, and very well documented. The FX2 Technical reference manual is an outstanding source of knowledge both on the chip and on the USB protocol and architecture. > An asynchronous serial port sends data when it's ready, Not that simple. A good reference book will explain a bit more. I recommend Patterns for Time-Triggered Embedded Systems by Michael Pont (available from Amazon). This book is very much in Oberon spirit. I once wrote to Michael Pont that his architecture is very close to Oberon System. He never heard of Oberon prior to my e-mail, but he checked and acknowledged the similarity. His software provides an example how Oberon System could have been if it was supported by a good industrial manager like Michael. > whereas USB has to packetize the data, causing > unnecessary processing and making the timing less certain. Let me point out that the USB-2 can achieve about 25 MBytes per second. It supports up to 256 devices on a single bus. It has extensive identification of devices and it can load and execute drivers. Saying that these features are "unnecessary processing" is not even wrong. USB-3 is even more impressive, but I am not an expert on USB-3. My working knowledge only covers (parts of) USB-2. > A serial port was an always-ready peripheral, easily configured > with a couple of registers. One host and a single peripheral. It is not much. As soon as you want to develop something more substantial (like a network) "easily" does not apply anymore. You must read a few books. I recommend Serial Port Complete by Jan Axelson, or the Pont's book pointed above. > Initializing a USB connection requires extensive negotiation > and large tables, requiring kilobytes of RAM and a working CPU. Use EZ-USB and USB will become almost as simple as the serial port. All you need is some easy reading. The USB Complete by Jan Axelson is a good beginning, and then the first few chapters from the FX or FX2 Technical Reference Manual will put you on a path to success. The FX/FX2 chips will take care of "extensive negotiation" for you. It is very easy. Just a couple books and a couple months and you will become a proficient USB developer, if you are not one already. > Attaching a simple HID device like a keyboard, > for those who complain about PS/2 ports, is not that easy. Use the Cypress chip to handle the complexity and off you go. Also check the following page: http://janaxelson.com/index.html You can also use FTDI if you want a canned solutions. I recommend Cypress because with Cypress you can take the lid off if you want to. > Finally, as ubiquitous as USB is, it is not something > that should be 'taught'. It is a dumb, bloated and obfuscated > spec with multiple standsards, connectors and extensions > that is much like the US tax code. I thought this mailing list was for engineers. I am surprised to find a politician among us. Thank you, Wojtek

3 2

(no subject)
by None 18 Feb '16

18 Feb '16

2 1

Re: [Oberon] 8051 book with Fuzzy Logic chapter
by skulski＠pas.rochester.edu 18 Feb '16

18 Feb '16

John Roberts wrote me (in private): > It is possible the book you read on the Keil CD > is "The Final Word on the 8051" by Matthew Chapman. > If you can confirm this is the proper document you read > [do you still have it accessible, or your Keil CD > or the files from it?], perhaps we can track down > a trustworthy location (and/or contact the author) and > you can announce the proper information to the Oberon list. John, this is exactly right! I still have the Keil CD labeled "Keil Development Tools CD-ROM" Release 0.5 2001. I am glad I kept it. I loaded it into the CD drive H:. The file is named FINALWD.PDF in directory H:\GUIDES. It is dated 4/17/1997. File size on the CD 1,515 kB. The book has 255 pages. And indeed, on the bottom of page 255 it says © Matthew Chapman 1994. I missed that note. So yes, we can announce that the mystery has been solved. I think it is a very good book. The final chapter on fuzzy logic is very interesting. It is one of those masterpieces that make a lasting impression (at least on me ;-). Thank you for finding it on the net! Wojtek

1 0

Patterns for Time-Triggered Embedded Systems by Michael Pont
by scrutinizer 17 Feb '16

17 Feb '16

On 17 February 2016 at 04:56, <skulski(a)pas.rochester.edu> wrote: ... > Patterns for Time-Triggered Embedded Systems by Michael Pont ... the book is online (pdf and zip for library): http://www.safetty.net/publications/pttes here is an excerpt from an amazon.co.uk review, Sept. 2010: ... available free on the internet (legitimately) as part of academia the author had to make four years of work available for free.

1 0

(no subject)
by None 17 Feb '16

17 Feb '16

2 1

Re: [Oberon] Pepino LX9, USB, and other hardware running OBERON
by Bill Buzzell 17 Feb '16

17 Feb '16

"So essentially it's a blackbox abstracted away, out of site, out of mind, and you don't "learn" about USB? i.e. hiding it under the rug, pretending it's RS232 when in fact there is a USB blackbox somewhere in there... I'm okay with this, just wondering why Wirth is okay with that or Oberon folk are okay with it. I could also have it completely wrong. i.e. at some point the USB has to be abstracted away and hidden from site, in order for oberon to work with usb without knowing much about usb - so in some sense it is a black box. But how is that any different from a rasp pi with usb that no one really understands fully. are we just moving goal posts here and pretending this is an "ethical" usb choice? It seems to be the ethics of oberon is that you have to understand all parts of the system. Can you fully understand the Pepino USB system or is it just a hardwared blackbox? Sorry for my ignorance, I'm still in the research stages of seeing how Pepino actually works. FPGA's are also quite confusing." As soon as someone figures out a way to totally be gone with USB that is a GOOD thing and to be considered PROGRESS. Same with the mouse and keyboard. It is ADVANTAGEOUS to be without massive protocols which serve no purpose but to get in the way. This is the type of system where you should AT LEAST be able to read the TTL signals and make your own mouse driver. What is PS-2? Cut the cord, skin the wires and read the bare wires output. This is desirable. In fact, I am attempting to establish a more direct TCP-UART bridge using the ESP8266 which will bypass USB completely, and happens over WiFi. There is already headers on the Pepino for the ESP8266. In actuality, the NRF24l01 offers a more 'bare metal network' than the ESP8266 even. The FTDI chip serves as the "COM port ---> RS232" communication channel to speak to the FPGA, which is the industry standard way to make a good "plug-and-play" system via USB. It is a most sensible way to go, at least for now but certainly not the only way. In fact,you want a $5 'pc'? You learn to program compilers WELL using a ProjectOberon board and simply build a target compiler for the ESP8266, and viola, you will have a SUPERIOR $5 computer that is running Oberon, not Linux.

3 2