fpga and usb interface
Don Latham
So, we could settle on the Digilent for the grunt work, leaving the input
circuits to be settled?
Don
--
"Neither the voice of authority nor the weight of reason and argument are
as significant as experiment, for thence comes quiet to the mind."
R. Bacon
"If you don't know what it is, don't poke it."
Ghost in the Shell
Dr. Don Latham AJ7LL
Six Mile Systems LLP
17850 Six Mile Road
POB 134
Huson, MT, 59846
VOX 406-626-4304
www.lightningforensics.com
www.sixmilesystems.com
Bob Bownes
get the code right and then integrate it into a custom board down the
road. I'd be more inclined to go that route long term to keep the
eventual costs down.
Eric Garner
Sent from my Banana jr (tm) Mobile Device
Tristan Steele
A nice introduction perhaps? :)
Thanks,
Tristan
bownes
tijddingen
tries to communicate is the requirement of requirements. There are
plenty of ideas, so boil them down to a small list that you feel you
can manage as a group, assign who does what, and go. It's almost like
work. ;-)
With respect to usb... As a suggestion, maybe you want to consider
first getting rs232 going first between fpga and pc. I can promise you
that is significantly easier and an almost instant reward of getting
things to work. This quick victory then mentally equips you for the
potential frustrations of getting usb working. Just saying. ;)
You can grab the ready to go rs232 modules here:
http://www.fpga4fun.com/SerialInterface.html
All you need to do is change the system clock frequency and baudrate,
and you've got a working rs232 module. I did that some time ago for
the nexys2 and like I said, it worked in one go.
Or if you are going to tell me, "but we need more than 115200 baud,"
that serves as a nice excuse to ask this question: "So now then, what
volume of data are you going to send back and forth?".
My point being ... I don't know the architecture you are
contemplating, but /if/ you do not need more than say 10 kB/s of
traffic to get your measurement data to the PC you may just want to
stick with the RS232 link. Not as cool as usb but just as effective to
get the job done. Plus when down the road you find out rs232 is
insufficient you can always invest the time /then/ to get usb working.
To have a project like this gain momentum, avoid all unnecessary bumps
in the road that /are/ avoidable. Otherwise you are stuck in the Land
of Needless Tedium before you even got started. And this is coming
from the perspective of someone who got rs232 working in under 1 hour,
and usb over the coarse of a, uhm, significantly longer period of
time...
For an fpga project that more than 1 person is going to work on you
would need some agreements. Especially due to the lack of face to face
communication. As a starter project I would not burden myself with
mixed language. I.e, pick one language of the set verilog/vhdl and go
with that. Forget schematic entry. Looks cool, but might become
impractical. Just my opinionated opinion. ;)
Something completely different. Is this counter going to be a
standalone unit that should be able to work without a PC attached? Are
you sure? Anyone with user interface experience on embedded devices in
the group?
regards,
Fred
On Jan 31, 5:16 am, bownes <bow...@gmail.com> wrote:
> You can view the whole archive on google groups.http://groups.google.com/group/opencounter
>
> Bob
Bob Bownes
On Tue, Feb 1, 2011 at 10:09 AM, tijddingen <tijdd...@yahoo.com> wrote:
> I think what the sum of the whole archive plus Tristan's question
> tries to communicate is the requirement of requirements. There are
> plenty of ideas, so boil them down to a small list that you feel you
> can manage as a group, assign who does what, and go. It's almost like
> work. ;-)
Indeed it is. I'm pretty much thinking we should start with a list of
requirements and let that drive all the other decisions. I know, never
put Marketing in charge of Product Definition...:) The trick is a list
of requirements, which so far is:
1) A Time Interval Counter
and
Open for discussion. :)
>
> With respect to usb... As a suggestion, maybe you want to consider
> first getting rs232 going first between fpga and pc. I can promise you
> that is significantly easier and an almost instant reward of getting
> things to work. This quick victory then mentally equips you for the
> potential frustrations of getting usb working. Just saying. ;)
>
I fully concur. Once you have RS232, you can turn it into anything
else, be it USB, ethernet, telnet, http, SNA, X.25, IEEE488. Ok, Most
anything.
> My point being ... I don't know the architecture you are
> contemplating,
Neither do we. See my comment above.
> but /if/ you do not need more than say 10 kB/s of
> traffic to get your measurement data to the PC you may just want to
> stick with the RS232 link. Not as cool as usb but just as effective to
> get the job done. Plus when down the road you find out rs232 is
> insufficient you can always invest the time /then/ to get usb working.
>
And change interface chipsets at will.
> For an fpga project that more than 1 person is going to work on you
> would need some agreements. Especially due to the lack of face to face
> communication. As a starter project I would not burden myself with
> mixed language. I.e, pick one language of the set verilog/vhdl and go
> with that. Forget schematic entry. Looks cool, but might become
> impractical. Just my opinionated opinion. ;)
>
I suppose. I have no experience with FPGA's so schematic based design
is more familiar. There needs to be a schematic at some point unless
you are going to be using the stock NEXSYS board and attaching
everything to that.
> Something completely different. Is this counter going to be a
> standalone unit that should be able to work without a PC attached? Are
> you sure? Anyone with user interface experience on embedded devices in
> the group?
>
I have a few years of both.
My presumption is a stand alone instrument that can be connected to a
PC or network for data collection.
Bob
Tristan Steele
- I like the idea of an RS232 interface.
- I personally really like using schematic entry for high level HDL designs. ie. create a symbol for each lower level module and "connect the dots" with a schematic. It seems to line up well with how I think it should look. :) Also, my vote is for Verilog to VHDL. :-)
- Is it worth aiming for a PC connected instrument to begin with? Surely it would make an easier development cycle to dump raw data to PC first. Depending on the user interface, it may make more sense to do this in a micro of some form (either a seperate chip or a soft core). This could even be "tacked on" using the RS232 interface? (ie. come up with a basic command set, use 2 serial ports on the FPGA and have one of these dedicated to the built in control interface. From the amount of FPGA programming I have done i would prefer to do number crunching on one chip and interface control on another (even if it is built into the same chip).
Just some crazy ideas. :)
Tristan
tijddingen
> - I personally really like using schematic entry for high level HDL
> designs. ie. create a symbol for each lower level module and "connect the
> dots" with a schematic. It seems to line up well with how I think it should
> look. :) Also, my vote is for Verilog to VHDL. :-)
> - Is it worth aiming for a PC connected instrument to begin with? Surely
> it would make an easier development cycle to dump raw data to PC first.
> Depending on the user interface, it may make more sense to do this in a
> micro of some form (either a seperate chip or a soft core). This could even
> be "tacked on" using the RS232 interface? (ie. come up with a basic command
> set, use 2 serial ports on the FPGA and have one of these dedicated to the
> built in control interface. From the amount of FPGA programming I have done
> i would prefer to do number crunching on one chip and interface control on
> another (even if it is built into the same chip).
probably not be the first project that requires an interface with a
display + some buttons. Are there any open projects that have already
tackled this and have a reasonably adaptable interface? Something that
talks either rs232 or spi would do nicely I would think...
regards,
Fred
tijddingen
> > Something completely different. Is this counter going to be a
> > standalone unit that should be able to work without a PC attached? Are
> > you sure? Anyone with user interface experience on embedded devices in
> > the group?
>
> I have a few years of both.
>
> My presumption is a stand alone instrument that can be connected to a
> PC or network for data collection.
How do you envision the interface and display for this standalone
instrument?
Do something custom, or use something that is already out there? If
the latter, do you have anything specific in mind?
regards,
Fred