[Oberon] The Oberon answer to Arduino

[Aubrey.McIntosh at Alumni.UTexas.Net]

On Wed, Dec 26, 2012 at 1:45 AM, Arnim Littek <arnim at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.inf.ethz.ch/pipermail/oberon/attachments/20121226/624ca0ce/attachment.html