[CCC DEV] Transterpreter/Plumbing ported to the AT90CANxxx: First attempt and a problem

[Matt Jadud]

Hi Stefan,

This is all great. I will say that you should definitely join the
developers list (developers at concurrency.cc). It's low traffic, and the
whole team is there. We're all happy to help (and several team members
are in or near your timezone.)

On Thu, Oct 21, 2010 at 06:09, Stefan Heymer <stefan.heymer at gmx.de> wrote:
> During my studies I worked in the areas of reactive systems, getting to
> know things like process algebras, CCS and CSP by heart. Working later
> in the field of telecom standards, notations (and communication
> paradigms) changed, but formulation of systems as collections of
> communicating processes still remained the same idea. Hence, I really
> much would like to take this view as a (concrete) system as a collection
> of communicating processes when developing embedded control software ---
> Occam-pi and the Transterpreter would let me do this.

We once gave a three-day workshop on CSP/occam at a telecomm firm in
Vienna. It feels like a natural combo.

> platforms, namely AT90CAN32, AT90CAN64 and AT90CAN128. These three
> processors are pin and bytecode compatible and differ only in flash and
> RAM memory sizes.

Those look like fun parts -- if your work involves the CAN bus, and if
you decide to do a CAN bus implementation in occam, I hope you'd be
willing to share it. But, I digress...

> for the enumeration of interrupts with a branch for the AT90s, listing
> their interrupts, and mapping them later in the manner of the code for

We often leave interrupts to "last", so to speak. Doing the
enumeration work is fine, but I wouldn't make any of my test programs
use interrupts. Get things working in a straight line, and then add
the interrupts. But you know that. (For serial, we often do blocking
serial first, to make sure things are good, and then we add in the
interrupt-driven line.)

> (embedding the statement "TCCR0B |= 3 << CS00" on line 98 in an #ifndef,
> and changing it to "TCCR0A |= 3 << CS00" for the AT90CANs).

Makes sense.

> Compiling the firmware worked like a charm, flashing it into the first
> board worked great, and the terminal software showed "...: program
> loading failed" as expected. Trying to compile a simple "hello world"

That sounds good. The devices are similar enough that it shouldn't be an issue.

> process worked, too, but flashing it into the controller using the
> AVRDude still yielded "...: program loading failed". Buggers.

>From what you're saying, it sounds like the first place I'd look is
whether or not the TVM (our short name for the Transterpreter) is
looking at the right location for the bytecode. That's a hard-coded
value -- on the Arduino, it is 0x5000. You can probably pass that as a
compile-time constant if you want, or change it in the sources. The
point is, if the VM you compile doesn't know where to look, it will
load garbage and fail.

> works with a virtual memory interface to cover the AVR's Harvard
> architecture) wrong, and already raised the BYTECODE_ADDR to 0x6000 (as
> the firmware is a bit bigger than for the Arduino).

It looks like the AT90s have the same memory architecture...

I'm not sure, at the moment, what would be leading to this failure.
I'll have to re-read your note and think about it more...

> Would you have any pointers for me to make loading of program code on
> the AT90CAN port of the Transterpreter runtime work? I would be _very_
> grateful, as I have some interesting projects on my table I would love
> to implement in Occam...

I've CC:'d your message to the developers list, and would again
encourage you to take a look there. I need to get moving towards the
workplace, and my day in GMT-5 is going to be pretty full, but it is
possible that someone over in GMT+0 or GMT+1 might have some insights
that will help get you moving.

For the team: this is really one of those cases where I wish we had a
distributed version control system... Stefan would have cloned/forked
our project, made his edits, and we could just look at his code...

Cheers,
Matt