the chip, hmm i am indeed using the C.1.1+ version with the V6 oopic
compiler. I have checked the output with a multimeter, sometimes it
doesnt give me the logic that i want, if it does the only pin that
has the changing logic is the I/O port 12 the rest doesn't have any
change in their logic.
Anyone else tried with V6 and gotten a diff results? >.< My
presentation is tomorrow, so far only managed to get one of the
motors to move. izzit the board's problem or the software problem? I
did get a PIC16F877 from Oricom but i would have to start from
scratch again if the oopic doesn't work. >.< anyone got any better
solution?
Thanks for answering my enquries. Sorry if my online time is weird
due to the difference in timezone. Thanks in advance.
Minghui
--- In oopic@yahoogroups.com, Brian Lloyd <brian-wb6rqn@...> wrote:
>
>
> On Apr 13, 2008, at 1:41 PM, rtstofer wrote:
>
> > --- In oopic@yahoogroups.com, Brian Lloyd <brian-wb6rqn@> wrote:
> >>
> >>> If you are using an older chip (< C.1.1) then use V5. If you
have
> >>> the newest chip, you have a problem. Perhaps someone else can
get
> >>> it
> >>> to work.
> >>
> >> I am getting to the point where I am wondering if it is worth it
to
> >> keep going with the OOPic.
> >
> > Don't take my test of V6 and oStepper as the gospel. I tried it
and
> > it didn't work immediately. I gave up and tried V5. Since I have
> > only B.2.2+ there no reason for me to bother with V6. And I
> > haven't...
> >
> > It is likely that someone else can get this to work. It's just
that I
> > have a short attention span - kind of like a 3d grader in that
regard.
> > If it doesn't work, I take a different approach.
>
> It wasn't your posting other than it is yet another data point for
the
> problems with the OOPic. We *KNOW* there are problems with the
OOPic
> and its development environment. How much have we gone over the
> problems with events? And still there is no fix. I don't know
about
> you but if something of that magnitude had escaped from my shop, I
> would have had the dev team set aside everything to get that fixed
so
> my customers could get back to work. And I would have kept my
> customers apprised every step along the way so they would have
some
> visibility into both the importance and timeliness of the fix.
>
> > I really believe the Stamp is a better developed platform and
there is
> > no question that the documentation is orders of magnitude
better. But
> > there are issues: the servo pulses are not continuous and don't
run in
> > the background. Same with PWM. The chip has to take a very
bizarre
> > approach to doing analog input. Given a few moments, I could
come up
> > with a long list of warts. But the warts are documented and
working
> > examples are given.
>
> And I agree with you 100%. As an architecture, the BS2 is, well,
> suboptimal. Integral A:D is really important to me and RCTIME is a
> real hack as far as I am concerned. I am teaching kids about
voltages
> and turning them into numbers. Doing that with the BS2 is, well,
> RCTIME sure gets in the way. I was teaching them about how
capacitors
> work and we did write a program to charge and discharge capacitors
> through a resistor and measure voltage and time on a 'scope. (Yes,
I
> have 5th-8th graders breadboarding circuits and then watching how
they
> behave using an analog oscilloscope.) But doing A:D using RC timing
is
> just too much to digest at one time. True A:D where a given voltage
is
> a number is actually easy to understand and to do something with.
>
> So I agree. As an *architecture* I *LIKE* the OOPic a lot more.
>
> But can I trust it? When there are problems I need them to be the
> student's problems, not the sytem's.
>
> > With both devices there is a tradeoff between ease of programming
and
> > sophistication of operation. There is nothing either of these
devices
> > can do that can't be done a lot better with the same underlying
chip
> > and 100 times as much programming effort.
>
> That I understand. No argument. I have written code in darned near
> every programming language and assembler on a LOT of machines.
>
> > As I mentioned much earlier in your posts, there is no motivation
for
> > moving to C.1.1 or V6. It is much better to search around for
B.2.2+
> > chips (www.junun.org?) and work with V5.
>
> I know. But it is unfortunate that I ended up with almost all
C.1.1+
> chips. Frankly there wasn't anything to say, "DON'T GET THE NEW
CHIPS;
> THEY ARE BROKEN."
>
> > In terms of breadboarding an idea, nothing beats the OOPic.
>
> So far, I agree.
>
> > Whether
> > it sees the light of day in the final design is another issue. I
have
> > 3 or 4 OOPics (2 in Mark III controllers) and I play with them
when I
> > want something down and dirty. When I want it to work, I move to
the
> > ATmega128 or one of the ARM7 devices. But this isn't feasible for
> > your classes.
>
> Nope.
>
> > In my view, all of these controllers would be outgunned with one
of
> > the high end Z80 clones running an enhanced version of Palo Alto
Tiny
> > Basic. A few functions need to be written to interface with the
> > hardware gadgets and the rest of the programming is just like
> > timeshare Basic. It would be blistering fast (50 MHz, 1 clock per
> > simple instruction), interpreted and able to handle all of the IO
> > gadgets. Unfortunately, I am not motivated enough to do the
work. I
> > did get PATB running on an EZ80F91 board but then moved on to
> > implement CP/M 2.2. CP/M would be an even better platform!
>
> I would tend to disagree. I come from that age, having actually
> written a full emulation of the Z-80 on a Nanodata QM-1 (we needed
it
> to test the UCSD P-system on a Z-80) and built several working
systems
> from scratch using the M6800 (a much better chip than the 8080 in
my
> estimation and the equal to the Z-80 but I digress). OS-8, RT-11,
CPM,
> and then MS-DOS were all jokes insofar as operating systems were
> concerned. (I list them together because that is their lineage.)
If
> you are going to do that then it is time to talk about a real OS
that
> provides preemptive task scheduling and decent message-passing
> interprocess communications.
>
> But this has nothing to do with the OOPic.
>
> > In the end, I just use the OOPic within its' limitations and am
quite
> > happy with B.2.2+ and V5.
>
> At this point I wish I had the option. My point is one about
customer
> service and support. I just don't see a lot of motion on Savage's
part
> to solve this problem. Sure we can change chips and work around
the
> problem but aren't we the customers? What happened to "customer
> support?"
>
> I was pondering the possibility of replacing the BS2's with OOPics
in
> some or all of our BoeBots. Not now.
>
> I guess I am just frustrated by once again having to work around
> someone else's problems.
>
> <grumble>
>
> --
>
> Brian Lloyd Granite Bay Montessori
> brian AT gbmontessori DOT com 9330 Sierra College Blvd.
> +1.916.367.2131 (voice) Roseville, CA 95661, USA
>
http://www.gbmontessori.com
>
> I fly because it releases my mind from the tyranny of petty
things . . .
> — Antoine de Saint-Exupéry
>
> PGP key ID: 12095C52A32A1B6C
> PGP key fingerprint: 3B1D BA11 4913 3254 B6E0 CC09 1209 5C52 A32A
1B6C
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/oopic/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/oopic/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:oopic-digest@yahoogroups.com
mailto:oopic-fullfeatured@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
oopic-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
No comments:
Post a Comment