> ... GALs, PLDs, PEELs, they are going down the same path as
dinosaurs...
Ha! Youth.
Try getting 5ns gate times from a PIC. Wanna calculate how fast you can
arbitrate and how fast I can?
Like micros, PICs are great if you have time to work with. If you don't
(or can't find a 1GHZ PIC) use hardware, Sonny.
Tom
Tom Becker
--... ...--
GTBecker@GTBe... www.RighTime.com
The RighTime Clock Company, Inc., Cape Coral, Florida USA
+1239 540 5700
handling multiple interrupt sources?
Started by ●March 27, 2005
Reply by ●April 3, 20052005-04-03
Reply by ●April 3, 20052005-04-03
Tom, I had thought I had seen C compilers for the inbedded
controllers. I had checked them out a while back (2 years ago?).
Do they come preassembled in a simple-to-use functional unit like
the BX-24 (maybe just add a clock oscillator)? Interrupt-driven sub-
programs would be nice to have too!
Since I do not mind programming in C at all, something like this
would be just great.
-Tony
--- In basicx@basi..., "tombhandley" <gr13tbs@c...> wrote:
>
> Tony, you can get free or very expensive C/C++ compilers for both
> chips. In the PIC case, I use CCS's C compiler but I normally just
> use the assembler since I have a lot of experince with it and I
have
> a little more control of the generated code though Compilers like
CCS
> and HiTech are 'blurring' the difference as they now generate very
> efficient code.
>
> While the previous 74x or CMOS 'glue' suggestions are fine, why
add
> the 'glue' when you can do it with one chip? As far as GALs, PLDs,
> PEELs, they are going down the same path as dinosaurs... Embedded
> contollers are so much easier to deal with at this level. The
tools
> are free and, depending on the device, you can build a programmer
for
> a few bucks. In my case, I spent lot's of bucks on tools and a
> programmer but you don't have to.
>
> - Tom
>
> --- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
> >
> >
> > I have no experience with the PIC/AVR devices, but they look
very
> > interesting. This morning as I was driving, I was thinking
about
> > the Basic language, and the BasicX implementation. With such
> strong
> > typing, it forces the user to really think about the data types,
> > which when I was learning "C" was slightly tough. I eventually
got
> > to REALLY REALLY like C, but I never got to love "objects" too
> > much. My applications never really needed complex objects
anyway.
> > I still try to increment counters and stuff with "+= 1"!
> >
> > So, I was wondering if there is a "CX" device similar to the BX.
> >
> > Then I figured that I might as well just get some high
horsepower
> > AVR device and do it myself. I like the Basic-X devices because
> all
> > the connecting of the various parts is done for me into one very
> > user-friendly 24+ pin device.
> >
> >
> > Are there similar (i.e. preassembled like the BX-24), but lower
> > level devices around?
> >
> > While PAL's are great, just for simplicity (to me), I'd rather
stay
> > relatively discrete....
> >
> > BTW, the real rally computer I have uses a Zilog-80 running at
> > 6Mhz. Written in ASM, though I presume written in C with hand-
> tuned
> > ASM sections, but NO floating point functions. All that was
> > synthesized by the programmer.
> >
> > He did a nice job. I just wish I could do a couple of tweaks on
> > some of the code, and have a couple of optional changes
> > (compensation for the rally master's rounding errors).
> >
> > -Tony
> [snip]
Reply by ●April 3, 20052005-04-03
Tom, you raise a good point as far as speed and I thought I mentioned
that in my earlier msg ;-)
- Tom
--- In basicx@basi..., "Tom Becker" <gtbecker@r...> wrote:
> > ... GALs, PLDs, PEELs, they are going down the same path as
> dinosaurs...
>
> Ha! Youth.
>
> Try getting 5ns gate times from a PIC. Wanna calculate how fast
you can
> arbitrate and how fast I can?
>
> Like micros, PICs are great if you have time to work with. If you
don't
> (or can't find a 1GHZ PIC) use hardware, Sonny. > Tom >
> Tom Becker
> --... ...--
> GTBecker@R... www.RighTime.com
> The RighTime Clock Company, Inc., Cape Coral, Florida USA
> +1239 540 5700
Reply by ●April 3, 20052005-04-03
Tounge in cheek, Tony.
Everything is going the way of the dinosaurs, that is true; but maturity
does not mean obsolence. PALs, per se, are passe but programmable logic
certainly is not. Today, you probably have a PIC in your toothbrush to
control the motor; tomorrow, it might be an FPGA that talks to your
dentist about your chemistry.
The truth is that we have many tools; some are new and most are well
worn. Tom
Tom Becker
--... ...--
GTBecker@GTBe... www.RighTime.com
The RighTime Clock Company, Inc., Cape Coral, Florida USA
+1239 540 5700
Everything is going the way of the dinosaurs, that is true; but maturity
does not mean obsolence. PALs, per se, are passe but programmable logic
certainly is not. Today, you probably have a PIC in your toothbrush to
control the motor; tomorrow, it might be an FPGA that talks to your
dentist about your chemistry.
The truth is that we have many tools; some are new and most are well
worn. Tom
Tom Becker
--... ...--
GTBecker@GTBe... www.RighTime.com
The RighTime Clock Company, Inc., Cape Coral, Florida USA
+1239 540 5700
Reply by ●April 3, 20052005-04-03
Tony, first looking at your original project. The first thing I
noticed is the accuracy requirements on the clock. I see no reason
why the built-in BX-24 RTC would not work in your application.
As far as processing sensory Input, I started asking myself; why
would you use external 'Glue' given such a slow input? Tom Becker
raises good points when it comes to speed, but your application is so
trivial (though not if you are designing it ;-), that a simple
embedded controller would do th job and simplify your Interrupt
requirements.
As far as C compilers, I wish we had one for the BasicX family. You
need to use their Basic language and compiler. One great thing is
access to low-level Atmel's chip registers which I use for a variety
of things via the Register.<register name> function. The other is
multitasking though I wish the time slice was faster. All things
considered, I prefer the BX-24/35 over the Stamp but I prefer the
Stamp development environment.
- Tom
--- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
>
> Tom, I had thought I had seen C compilers for the inbedded
> controllers. I had checked them out a while back (2 years ago?).
> Do they come preassembled in a simple-to-use functional unit like
> the BX-24 (maybe just add a clock oscillator)? Interrupt-driven
sub-
> programs would be nice to have too!
>
> Since I do not mind programming in C at all, something like this
> would be just great.
>
> -Tony
[snip]
Reply by ●April 3, 20052005-04-03
Tom and Tony,
You guys must have seen an early draft of part 6 of my articles :)
Now that we have a definition of the intermediate language between the
BasicX compiler and the BasicX runtime, I was going to speculate on some
new functions that could be written including a
BasicX assembler for really low-level stuff and a C to BasicX
intermediate language compiler that I also named "CX". The runtime is
still the BasicX platform as before. A third useful item is a BasicX
simulator that can be used to test and debug programs. A BasicX ICE is a
little beyond what is possible because we do not have access to the
actual BasicX runtime code itself.
I have posted a diagram I actually drew about a month ago to show some
of these possibilities:
http://home.austin.rr.com/perks/basicx/Articles/BX%20Platform%20Enhancements.JPG
The stuff in gray is unimplemented. Given my specification of the
intermediate language (
http://home.austin.rr.com/perks/basicx/Articles/BasicX%20Instruction%20Reference.pdf
), you have enough information to write one of these "missing" pieces.
In fact the pseudo-code (actually C), in the document comes from a bare
minimum simulator that I used to verify that I was documenting the
correct pseudo code.
Mike
http://home.austin.rr.com/perks/basicx/Articles/
>
> Tony, first looking at your original project. The first thing I
> noticed is the accuracy requirements on the clock. I see no reason
> why the built-in BX-24 RTC would not work in your application.
>
> As far as processing sensory Input, I started asking myself; why
> would you use external 'Glue' given such a slow input? Tom Becker
> raises good points when it comes to speed, but your application is so
> trivial (though not if you are designing it ;-), that a simple
> embedded controller would do th job and simplify your Interrupt
> requirements.
>
> As far as C compilers, I wish we had one for the BasicX family. You
> need to use their Basic language and compiler. One great thing is
> access to low-level Atmel's chip registers which I use for a variety
> of things via the Register.<register name> function. The other is
> multitasking though I wish the time slice was faster. All things
> considered, I prefer the BX-24/35 over the Stamp but I prefer the
> Stamp development environment.
>
> - Tom >
> --- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
> >
> > Tom, I had thought I had seen C compilers for the inbedded
> > controllers. I had checked them out a while back (2 years ago?).
> > Do they come preassembled in a simple-to-use functional unit like
> > the BX-24 (maybe just add a clock oscillator)? Interrupt-driven
> sub-
> > programs would be nice to have too!
> >
> > Since I do not mind programming in C at all, something like this
> > would be just great.
> >
> > -Tony
> [snip] >
> *>.
You guys must have seen an early draft of part 6 of my articles :)
Now that we have a definition of the intermediate language between the
BasicX compiler and the BasicX runtime, I was going to speculate on some
new functions that could be written including a
BasicX assembler for really low-level stuff and a C to BasicX
intermediate language compiler that I also named "CX". The runtime is
still the BasicX platform as before. A third useful item is a BasicX
simulator that can be used to test and debug programs. A BasicX ICE is a
little beyond what is possible because we do not have access to the
actual BasicX runtime code itself.
I have posted a diagram I actually drew about a month ago to show some
of these possibilities:
http://home.austin.rr.com/perks/basicx/Articles/BX%20Platform%20Enhancements.JPG
The stuff in gray is unimplemented. Given my specification of the
intermediate language (
http://home.austin.rr.com/perks/basicx/Articles/BasicX%20Instruction%20Reference.pdf
), you have enough information to write one of these "missing" pieces.
In fact the pseudo-code (actually C), in the document comes from a bare
minimum simulator that I used to verify that I was documenting the
correct pseudo code.
Mike
http://home.austin.rr.com/perks/basicx/Articles/
>
> Tony, first looking at your original project. The first thing I
> noticed is the accuracy requirements on the clock. I see no reason
> why the built-in BX-24 RTC would not work in your application.
>
> As far as processing sensory Input, I started asking myself; why
> would you use external 'Glue' given such a slow input? Tom Becker
> raises good points when it comes to speed, but your application is so
> trivial (though not if you are designing it ;-), that a simple
> embedded controller would do th job and simplify your Interrupt
> requirements.
>
> As far as C compilers, I wish we had one for the BasicX family. You
> need to use their Basic language and compiler. One great thing is
> access to low-level Atmel's chip registers which I use for a variety
> of things via the Register.<register name> function. The other is
> multitasking though I wish the time slice was faster. All things
> considered, I prefer the BX-24/35 over the Stamp but I prefer the
> Stamp development environment.
>
> - Tom >
> --- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
> >
> > Tom, I had thought I had seen C compilers for the inbedded
> > controllers. I had checked them out a while back (2 years ago?).
> > Do they come preassembled in a simple-to-use functional unit like
> > the BX-24 (maybe just add a clock oscillator)? Interrupt-driven
> sub-
> > programs would be nice to have too!
> >
> > Since I do not mind programming in C at all, something like this
> > would be just great.
> >
> > -Tony
> [snip] >
> *>.
Reply by ●April 3, 20052005-04-03
--- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
> OK, I think I see. I was confused. I had thought that it was
> toggling, but Like I said, I will have to assemble the circuit and
> see what it does...
Here is a page that describes the operation of a J-K.
http://web.cs.mun.ca/~paul/cs3724/material/web/notes/node14.html
Any good book on sequential logic design will also tell you everything
you need to know about them.
Don
Reply by ●April 3, 20052005-04-03
--- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
> I could not really find the operational difference between the HC
> and HCT models.
The difference is that each logic family has its own specifications as
to the maximum level that will be recognized as a logic zero and the
minimum level that will be recognized as a logic one. The area
between those is undefined - you don't want to be in that region very
long. Other specs give the maximum output level of a logic zero and
the minimum output level of a logic one.
There are also differences among the families as to the source and
sink capabilities of the outputs and the amount of current that the
input sources or sinks at each logic level.
To be certain, you have to examine the appropriate output specs of one
family and compare them to the input requirements of the other and
vice versa. Sometimes, the output of family A will be compatible with
the input of family B the the converse is not true.
Here is a page that discusses some of the compatibility issues:
http://www.explore-technology.com/electronics/L/Logic_families.html
Don
> wide difference.
>
> The 109 I could order was a CD74AC109E Which seemed the same as the
> 74HCT109. I guess I will find out if they are not sufficiently
> compatible.... > Thanks again!
> -Tony
> --- In basicx@basi..., "Don Kinzer" <dkinzer@e...> wrote:
> >
> > --- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
> > > I really love your suggestion [of using a J-K flip flop]. Even
> > > though the devices are 1970's technology ...
> >
> > The only thing that is '70s about this idea is if you choose to use
> > 74LS series logic. It functions perfectly well and is less static
> > sensitive than MOS based technologies. The 74HC and 74HCT series are
> > more modern and have wider operating voltage ranges as well as lower
> > power consumption. As a bonus, they are functionally and pin
> > compatible with the 74LS series.
> >
> > The 74HCT series can be intermixed with 74LS series devices. The
> same
> > is not true for the 74HC series. All three will work quite well with
> > the BX-24.
> >
> > Don
Reply by ●April 4, 20052005-04-04
You have some excellent points. The reason I was undertaking this
design problem is that it IS trivial, and I thought it was fairly
easily within my amateur's grasp, AND within my budget of close to
zero. I had a BX-24 on hand, as well as some logic gates, 5v
regulators, diodes, caps, etc.
I thought that the BX-24 COULD do the job, but I was not sure it was
fast enough to do the job. One of the limiting factors is the
relatively time-consuming task of output to the LCD display(s). The
availability of only one interrupt is a slight limitation. ANd I
really want to try to avoid polling hardware-sourced (not human-
sourced) inputs as much as possible.
So, this was primarily a design exercise. If I found that it
inspired me to go to an embedded controller, then that would be fun
too.
I am considering an embedded controller, but I have extremely
limited expertise (i.e. none) in the design of electronic circuits.
I have smoked more circuits than I have made work! So, the complex
stuff, like the layout of the controller would need to be bought as
a complete unit (like the BX-24), then I can try to do the
interfacing and programming.
So, I would love to use one of the new Atmel controllers with high
speed, and a bunch of memory! If it were available on a board. I
see stuff like the mega128 on boards, but not the more advanced
units so far. I am still looking.
-Tony --- In basicx@basi..., "tombhandley" <gr13tbs@c...> wrote:
>
> Tony, first looking at your original project. The first thing I
> noticed is the accuracy requirements on the clock. I see no reason
> why the built-in BX-24 RTC would not work in your application.
>
> As far as processing sensory Input, I started asking myself; why
> would you use external 'Glue' given such a slow input? Tom Becker
> raises good points when it comes to speed, but your application is
so
> trivial (though not if you are designing it ;-), that a simple
> embedded controller would do th job and simplify your Interrupt
> requirements.
>
> As far as C compilers, I wish we had one for the BasicX family.
You
> need to use their Basic language and compiler. One great thing is
> access to low-level Atmel's chip registers which I use for a
variety
> of things via the Register.<register name> function. The other is
> multitasking though I wish the time slice was faster. All things
> considered, I prefer the BX-24/35 over the Stamp but I prefer the
> Stamp development environment.
>
> - Tom >
> --- In basicx@basi..., "arhodes19044" <spamiam@c...> wrote:
> >
> > Tom, I had thought I had seen C compilers for the inbedded
> > controllers. I had checked them out a while back (2 years
ago?).
> > Do they come preassembled in a simple-to-use functional unit
like
> > the BX-24 (maybe just add a clock oscillator)? Interrupt-driven
> sub-
> > programs would be nice to have too!
> >
> > Since I do not mind programming in C at all, something like this
> > would be just great.
> >
> > -Tony
> [snip]
Reply by ●April 4, 20052005-04-04
I will check our stuff when I have a spare minute today.
it sounds like just the thing I would be looking for.
-Tony --- In basicx@basi..., Mike Perks <basicx@a...> wrote:
> Tom and Tony,
>
> You guys must have seen an early draft of part 6 of my articles :)
>
> Now that we have a definition of the intermediate language between
the
> BasicX compiler and the BasicX runtime, I was going to speculate
on some
> new functions that could be written including a
> BasicX assembler for really low-level stuff and a C to BasicX
> intermediate language compiler that I also named "CX". The runtime
is
> still the BasicX platform as before. A third useful item is a
BasicX
> simulator that can be used to test and debug programs. A BasicX
ICE is a
> little beyond what is possible because we do not have access to
the
> actual BasicX runtime code itself.
>
> I have posted a diagram I actually drew about a month ago to show
some
> of these possibilities:
> http://home.austin.rr.com/perks/basicx/Articles/BX%20Platform%
20Enhancements.JPG
>
> The stuff in gray is unimplemented. Given my specification of the
> intermediate language (
> http://home.austin.rr.com/perks/basicx/Articles/BasicX%
20Instruction%20Reference.pdf
> ), you have enough information to write one of these "missing"
pieces.
> In fact the pseudo-code (actually C), in the document comes from a
bare
> minimum simulator that I used to verify that I was documenting the
> correct pseudo code.
>
> Mike
> http://home.austin.rr.com/perks/basicx/Articles/
>
> >
> > Tony, first looking at your original project. The first thing I
> > noticed is the accuracy requirements on the clock. I see no
reason
> > why the built-in BX-24 RTC would not work in your application.
> >
> > As far as processing sensory Input, I started asking myself; why
> > would you use external 'Glue' given such a slow input? Tom Becker
> > raises good points when it comes to speed, but your application
is so
> > trivial (though not if you are designing it ;-), that a simple
> > embedded controller would do th job and simplify your Interrupt
> > requirements.
> >
> > As far as C compilers, I wish we had one for the BasicX family.
You
> > need to use their Basic language and compiler. One great thing is
> > access to low-level Atmel's chip registers which I use for a
variety
> > of things via the Register.<register name> function. The other is
> > multitasking though I wish the time slice was faster. All things
> > considered, I prefer the BX-24/35 over the Stamp but I prefer the
> > Stamp development environment.
> >
> > - Tom
> >
> >
> >
> > --- In basicx@basi..., "arhodes19044" <spamiam@c...>
wrote:
> > >
> > > Tom, I had thought I had seen C compilers for the inbedded
> > > controllers. I had checked them out a while back (2 years
ago?).
> > > Do they come preassembled in a simple-to-use functional unit
like
> > > the BX-24 (maybe just add a clock oscillator)? Interrupt-
driven
> > sub-
> > > programs would be nice to have too!
> > >
> > > Since I do not mind programming in C at all, something like
this
> > > would be just great.
> > >
> > > -Tony
> > [snip]
> >
> >
> >
> >
> >
> > -----------------------------
-------
> > *>.
> >
> >
