[Oberon] [Fwd: RE: objects and jewels]

[Jörg Straube]

Hi Frans Pieter

If you want to use Oberon as programming environment for Arduino, you either need an Oberon cross-compiler to AVR RISC code (so the Oberon program runs natively on the Arduino) or you could use the Firmata protocol to control the Arduino.
The Firmata approach seems simpler.

So basically the following has to be done:
- Load the Firmata FW onto the Arduino. This FW reads serial commands and translates them to the underlying Arduino HW
- Write an Oberon module that communicates serially via the Firmata protocol with the Arduino.

Joerg


On 24.02.2013, at 21:40, Frans-Pieter Vonck <fp at vonck.nl> wrote:

> To wrap it up (spring holidays are coming to an end).
> I want to use oberon in an educational setting to program microcontrollers.
> The most used platform  for starters nowadays is the Arduino. However, the
> arduino language, based on Processing which is based on Java, is not an
> ideal language to start learning programming. Moreover the underlying
> drivers of the arduino are al written in C++ which makes it even harder to
> understand (and therefore teach) what goes on under the hood.*
> 
> First I tried to mimic the arduino programs as close as possible. I found
> out that Arduino is object oriented with dynamic types. For example a
> servo is initialized like this servo1.init(1);
> Oberon07 does not have dynamic binding of types. Probably for good
> reasons. The closest thing to dynamic types is using procedure types,
> which renders a statement like this. servo1.init(servo1,1)
> 
> I tried to use type extension to create led objects.
> Leds are connected to a pin. A pin has a function and the function has
> some parameters to be set.
> The information about the led object can be recorded in it's attributes,
> however, it seems to me that in the microcontroller world this creates a
> lot of redundant information. The state of the pins are all registered in
> the microcontroller registers. Set and get methods can be directed
> directly to the registers and not to the objects. This is my argument why
> an object orientation with dynamic types is not necessary for
> micro-controllers.
> Maybe you have a better explanation and yes I've read Steps Beyond,
> Chapter 14 Oberon-2.
> 
> For now I stick to the modular approach.
> Every object like Led or Servo gets its own module. In the modules a base
> object is defined like a record. State of objects are recorded in
> registers which can be accessed through get and set procedures.
> 
> LED.Init(led1,port1,pin2);
> 
> I will experiment with procedure types when I want to create an descendend
> objects like blinking led, or a two way led.
> 
> Greets,
> F.P.
> 
> *This is also true for the so much laureated Lego Next. Java on top of C++
> libraries. A very expensive dialectical nightmare.
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2334 bytes
Desc: not available
Url : https://lists.inf.ethz.ch/pipermail/oberon/attachments/20130225/4977a6e5/attachment.bin