Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #33903 > unrolled thread

Re: ball-hours

Back to article view | Back to comp.lang.forth

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: ball-hours rickman <gnuarm@gmail.com> - 2014-10-15 00:25 -0400
    Re: ball-hours bruce.person@gmail.com - 2014-10-14 23:51 -0700
      Re: ball-hours rickman <gnuarm@gmail.com> - 2014-10-15 03:15 -0400
    Re: ball-hours Joerg <news@analogconsultants.com> - 2014-10-15 05:36 -0700
      Re: ball-hours rickman <gnuarm@gmail.com> - 2014-10-15 16:22 -0400
        Re: ball-hours Joerg <news@analogconsultants.com> - 2014-10-15 16:12 -0700
          Re: ball-hours rickman <gnuarm@gmail.com> - 2014-10-15 22:48 -0400
            Re: ball-hours Joerg <news@analogconsultants.com> - 2014-10-16 11:21 -0700
              Re: ball-hours rickman <gnuarm@gmail.com> - 2014-10-16 15:24 -0400
                Re: ball-hours Joerg <news@analogconsultants.com> - 2014-10-16 13:37 -0700
                  Re: ball-hours rickman <gnuarm@gmail.com> - 2014-10-16 17:42 -0400
                    Re: ball-hours Joerg <news@analogconsultants.com> - 2014-10-17 07:14 -0700
                      Re: ball-hours rickman <gnuarm@gmail.com> - 2014-10-17 14:03 -0400
                        Re: ball-hours Joerg <news@analogconsultants.com> - 2014-10-17 12:03 -0700
                          Re: ball-hours rickman <gnuarm@gmail.com> - 2014-10-17 15:23 -0400
                            Re: ball-hours Joerg <news@analogconsultants.com> - 2014-10-17 12:44 -0700
                              Re: ball-hours rickman <gnuarm@gmail.com> - 2014-10-17 18:37 -0400
                  Re: ball-hours rickman <gnuarm@gmail.com> - 2014-10-16 20:59 -0400
                    Re: ball-hours albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-17 08:43 +0000
                      Re: ball-hours rickman <gnuarm@gmail.com> - 2014-10-17 13:53 -0400
                    Re: ball-hours Joerg <news@analogconsultants.com> - 2014-10-17 07:50 -0700
          Re: ball-hours Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-10-15 20:42 -0700
            Re: ball-hours rickman <gnuarm@gmail.com> - 2014-10-16 01:50 -0400
              Re: ball-hours Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-10-16 00:49 -0700
                Re: ball-hours rickman <gnuarm@gmail.com> - 2014-10-16 05:14 -0400
              Re: ball-hours Joerg <news@analogconsultants.com> - 2014-10-16 11:58 -0700
          Re: ball-hours "Elizabeth D. Rather" <erather@forth.com> - 2014-10-16 08:32 -1000
            Re: ball-hours rickman <gnuarm@gmail.com> - 2014-10-16 15:32 -0400
            Re: ball-hours Joerg <news@analogconsultants.com> - 2014-10-16 13:45 -0700

Page 1 of 2  [1] 2  Next page →

#33903 — Re: ball-hours

On 10/14/2014 3:37 PM, Joerg wrote:
> rickman wrote:
>>
>> I use a program under Win32Forth to run my test fixture.
>>
>
> I have to go by what talent pool is available and regarding Forth that
> looks pretty parched. Tomorrow I am going to meet with a new SW
> contractor. For the upcoming project I need someone local because later
> we'll have to work together a lot in the lab. Plus if I use my mountain
> bike I can get there without a car and partially without roads :-)
>
> What you usually find locally is C and sometimes assembler. Occasionally
> people know Basic but then that's about it.
>
> It's similar with hardware. Being able to secure local talent is a major
> factor driving 8051 family designs. Unfortunately I can't do that with
> the new project because I need a ton more horsepower but first I am
> going to see what the SW guy is familiar with.

I was actually talking about you learning a language, but either way.

It is funny how in the forth community Forth is considered to be easy to 
learn and very facile for many tasks, especially when you need to 
interact with hardware or anything else where you don't have all the 
details clearly laid out.  But outside that community Forth is treated 
like a three eyed toad.

I seem to recall that you use the 8051 because you want a 20 year 
product life or something like that, right?  Does that affect your 
talent pool?

http://www.forth.com/embedded/swiftx-embedded-systems-development-tools.html?MCU=8051

http://www.mpeforth.com/xc7.htm#f7targets

 From your web page it looks like you are a half hour east of 
Sacramento, California in Cameron Park.

I am cross posting to the forth group.  Tell us a few details and we'll 
see if anyone can accommodate your needs.



-- 

Rick

[toc] | [next] | [standalone]

#33904

On Tuesday, October 14, 2014 9:25:03 PM UTC-7, rickman wrote:
> On 10/14/2014 3:37 PM, Joerg wrote:
> 
> > rickman wrote:
> 
> >>
> 
> >> I use a program under Win32Forth to run my test fixture.
> 
> >>
> 
> >
> 
> > I have to go by what talent pool is available and regarding Forth that
> 
> > looks pretty parched. Tomorrow I am going to meet with a new SW
> 
> > contractor. For the upcoming project I need someone local because later
> 
> > we'll have to work together a lot in the lab. Plus if I use my mountain
> 
> > bike I can get there without a car and partially without roads :-)
> 
> >
> 
> > What you usually find locally is C and sometimes assembler. Occasionally
> 
> > people know Basic but then that's about it.
> 
> >
> 
> > It's similar with hardware. Being able to secure local talent is a major
> 
> > factor driving 8051 family designs. Unfortunately I can't do that with
> 
> > the new project because I need a ton more horsepower but first I am
> 
> > going to see what the SW guy is familiar with.
> 
> 
> 
> I was actually talking about you learning a language, but either way.
> 
> 
> 
> It is funny how in the forth community Forth is considered to be easy to 
> 
> learn and very facile for many tasks, especially when you need to 
> 
> interact with hardware or anything else where you don't have all the 
> 
> details clearly laid out.  But outside that community Forth is treated 
> 
> like a three eyed toad.
> 
> 
> 
> I seem to recall that you use the 8051 because you want a 20 year 
> 
> product life or something like that, right?  Does that affect your 
> 
> talent pool?
> 
> 
> 
> http://www.forth.com/embedded/swiftx-embedded-systems-development-tools.html?MCU=8051
> 
> 
> 
> http://www.mpeforth.com/xc7.htm#f7targets
> 
> 
> 
>  From your web page it looks like you are a half hour east of 
> 
> Sacramento, California in Cameron Park.
> 
> 
> 
> I am cross posting to the forth group.  Tell us a few details and we'll 
> 
> see if anyone can accommodate your needs.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> 
> 
> Rick

Define "local".

Is Sacramento or Grass Valley local enough?

I know of a few very good Forth'ers within that local range.

a Forth Person

[toc] | [prev] | [next] | [standalone]

#33905

On 10/15/2014 2:51 AM, bruce.person@gmail.com wrote:
> On Tuesday, October 14, 2014 9:25:03 PM UTC-7, rickman wrote:
>> On 10/14/2014 3:37 PM, Joerg wrote:
>>
>>> rickman wrote:
>>
>>>>
>>
>>>> I use a program under Win32Forth to run my test fixture.
>>
>>>>
>>
>>>
>>
>>> I have to go by what talent pool is available and regarding Forth that
>>
>>> looks pretty parched. Tomorrow I am going to meet with a new SW
>>
>>> contractor. For the upcoming project I need someone local because later
>>
>>> we'll have to work together a lot in the lab. Plus if I use my mountain
>>
>>> bike I can get there without a car and partially without roads :-)
>>
>>>
>>
>>> What you usually find locally is C and sometimes assembler. Occasionally
>>
>>> people know Basic but then that's about it.
>>
>>>
>>
>>> It's similar with hardware. Being able to secure local talent is a major
>>
>>> factor driving 8051 family designs. Unfortunately I can't do that with
>>
>>> the new project because I need a ton more horsepower but first I am
>>
>>> going to see what the SW guy is familiar with.
>>
>>
>>
>> I was actually talking about you learning a language, but either way.
>>
>>
>>
>> It is funny how in the forth community Forth is considered to be easy to
>>
>> learn and very facile for many tasks, especially when you need to
>>
>> interact with hardware or anything else where you don't have all the
>>
>> details clearly laid out.  But outside that community Forth is treated
>>
>> like a three eyed toad.
>>
>>
>>
>> I seem to recall that you use the 8051 because you want a 20 year
>>
>> product life or something like that, right?  Does that affect your
>>
>> talent pool?
>>
>>
>>
>> http://www.forth.com/embedded/swiftx-embedded-systems-development-tools.html?MCU=8051
>>
>>
>>
>> http://www.mpeforth.com/xc7.htm#f7targets
>>
>>
>>
>>   From your web page it looks like you are a half hour east of
>>
>> Sacramento, California in Cameron Park.
>>
>>
>>
>> I am cross posting to the forth group.  Tell us a few details and we'll
>>
>> see if anyone can accommodate your needs.
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>>
>> Rick
>
> Define "local".
>
> Is Sacramento or Grass Valley local enough?
>
> I know of a few very good Forth'ers within that local range.
>
> a Forth Person

I don't know the area.  I think the requirement is that the person be 
able to work in the lab with the guy when he needs it.  He doesn't want 
someone who can only work from far away.

I mentioned Forth to the guy and his reason for not using it was the 
lack of available talent.  Even if the perfect Forth guy shows up that 
doesn't mean he will hire him.  I think he has concerns about finding 
people in the long term.  He seems to have no trouble finding C people, 
but he hasn't worked with the ARM yet, but he wants to.  Someone who has 
experience with both 8051 and ARM CPUs would have a leg up.

The OP is a hardware guy so he doesn't do much software.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#33909

rickman wrote:
> On 10/14/2014 3:37 PM, Joerg wrote:
>> rickman wrote:
>>>
>>> I use a program under Win32Forth to run my test fixture.
>>>
>>
>> I have to go by what talent pool is available and regarding Forth that
>> looks pretty parched. Tomorrow I am going to meet with a new SW
>> contractor. For the upcoming project I need someone local because later
>> we'll have to work together a lot in the lab. Plus if I use my mountain
>> bike I can get there without a car and partially without roads :-)
>>
>> What you usually find locally is C and sometimes assembler. Occasionally
>> people know Basic but then that's about it.
>>
>> It's similar with hardware. Being able to secure local talent is a major
>> factor driving 8051 family designs. Unfortunately I can't do that with
>> the new project because I need a ton more horsepower but first I am
>> going to see what the SW guy is familiar with.
> 
> I was actually talking about you learning a language, but either way.
> 

The only language I'd rally like to learn is Spanish :-)

But seriously, I do not want to get too involved in the actual
programming job because I am fully loaded with analog/mixed projects
already and want to reserve at least a few hours per week for mountain
biking.


> It is funny how in the forth community Forth is considered to be easy to
> learn and very facile for many tasks, especially when you need to
> interact with hardware or anything else where you don't have all the
> details clearly laid out.  But outside that community Forth is treated
> like a three eyed toad.
> 

Problem is, there is no Forth community out here. The last die-hard
Forth aficionado I personally met was about 30 years ago in Europe.


> I seem to recall that you use the 8051 because you want a 20 year
> product life or something like that, right? ...


Not on this project but otherwise, yes. One of my designs containing an
8051 will celebrate its 20th next year. Still in production and no end
in sight. Second source is another concern and you can only get that for
a small selection of 8051 uC.


>   ... Does that affect your talent pool?
> 

For other projects it does. We need to make sure that 10 years down the
road it will be possible to find someone locally who can re-write the
code. With 8051 that's usually not a problem.


> http://www.forth.com/embedded/swiftx-embedded-systems-development-tools.html?MCU=8051
> 
> 
> http://www.mpeforth.com/xc7.htm#f7targets
> 
> From your web page it looks like you are a half hour east of Sacramento,
> California in Cameron Park.
> 

Yep, near Hwy 50 just before Placerville. But the project is already
committed to a local guy if he feels comfortable to do it. Which I
should know by tomorrow. It has to be local in this case.


> I am cross posting to the forth group.  Tell us a few details and we'll
> see if anyone can accommodate your needs.
> 

Can't reveal too many details but from a code point of view essentially
several FFTs, one of them a big one, 1024 point complex (I/Q) every
5msec, overlapping. Extract phase, some complex-conjugate math to
extricate component values every 5msec (sort of a poor man's reverse
network analysis), followed by filtering, some more math or a LUT, then
modulating the result onto an audio carrier. Sprinkled with user
interface handling and calibration routines. Back of the envelope calcs
indicate that this will reasonably fit into a 100MHz ARM but of course
I'd rather have a few more megahoitzes.

-- 
Regards, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#33926

On 10/15/2014 8:36 AM, Joerg wrote:
> rickman wrote:
>> On 10/14/2014 3:37 PM, Joerg wrote:
>>> rickman wrote:
>>>>
>>>> I use a program under Win32Forth to run my test fixture.
>>>>
>>>
>>> I have to go by what talent pool is available and regarding Forth that
>>> looks pretty parched. Tomorrow I am going to meet with a new SW
>>> contractor. For the upcoming project I need someone local because later
>>> we'll have to work together a lot in the lab. Plus if I use my mountain
>>> bike I can get there without a car and partially without roads :-)
>>>
>>> What you usually find locally is C and sometimes assembler. Occasionally
>>> people know Basic but then that's about it.
>>>
>>> It's similar with hardware. Being able to secure local talent is a major
>>> factor driving 8051 family designs. Unfortunately I can't do that with
>>> the new project because I need a ton more horsepower but first I am
>>> going to see what the SW guy is familiar with.
>>
>> I was actually talking about you learning a language, but either way.
>>
>
> The only language I'd rally like to learn is Spanish :-)
>
> But seriously, I do not want to get too involved in the actual
> programming job because I am fully loaded with analog/mixed projects
> already and want to reserve at least a few hours per week for mountain
> biking.
>
>
>> It is funny how in the forth community Forth is considered to be easy to
>> learn and very facile for many tasks, especially when you need to
>> interact with hardware or anything else where you don't have all the
>> details clearly laid out.  But outside that community Forth is treated
>> like a three eyed toad.
>>
>
> Problem is, there is no Forth community out here. The last die-hard
> Forth aficionado I personally met was about 30 years ago in Europe.

I think you may be surprised.  I've already heard from three programmers 
from the few posts I've made in just three groups.  Unless you want me 
to send then directly to you, I am referring them to this thread.


>> I seem to recall that you use the 8051 because you want a 20 year
>> product life or something like that, right? ...
>
>
> Not on this project but otherwise, yes. One of my designs containing an
> 8051 will celebrate its 20th next year. Still in production and no end
> in sight. Second source is another concern and you can only get that for
> a small selection of 8051 uC.
>
>
>>    ... Does that affect your talent pool?
>>
>
> For other projects it does. We need to make sure that 10 years down the
> road it will be possible to find someone locally who can re-write the
> code. With 8051 that's usually not a problem.
>
>
>> http://www.forth.com/embedded/swiftx-embedded-systems-development-tools.html?MCU=8051
>>
>>
>> http://www.mpeforth.com/xc7.htm#f7targets
>>
>>  From your web page it looks like you are a half hour east of Sacramento,
>> California in Cameron Park.
>>
>
> Yep, near Hwy 50 just before Placerville. But the project is already
> committed to a local guy if he feels comfortable to do it. Which I
> should know by tomorrow. It has to be local in this case.
>
>
>> I am cross posting to the forth group.  Tell us a few details and we'll
>> see if anyone can accommodate your needs.
>>
>
> Can't reveal too many details but from a code point of view essentially
> several FFTs, one of them a big one, 1024 point complex (I/Q) every
> 5msec, overlapping. Extract phase, some complex-conjugate math to
> extricate component values every 5msec (sort of a poor man's reverse
> network analysis), followed by filtering, some more math or a LUT, then
> modulating the result onto an audio carrier. Sprinkled with user
> interface handling and calibration routines. Back of the envelope calcs
> indicate that this will reasonably fit into a 100MHz ARM but of course
> I'd rather have a few more megahoitzes.

I thought your current project was for an 8051?  I guess that was old 
projects or maybe old programmers... lol.  Your other post seemed to be 
talking about bitbanging the I2S port to the CODEC.  How does that work 
into the 100 MHz need?  Bitbanging a serial port of any kind can be CPU 
cycle intensive.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#33930

rickman wrote:
> On 10/15/2014 8:36 AM, Joerg wrote:
>> rickman wrote:
>>> On 10/14/2014 3:37 PM, Joerg wrote:
>>>> rickman wrote:
>>>>>
>>>>> I use a program under Win32Forth to run my test fixture.
>>>>>
>>>>
>>>> I have to go by what talent pool is available and regarding Forth that
>>>> looks pretty parched. Tomorrow I am going to meet with a new SW
>>>> contractor. For the upcoming project I need someone local because later
>>>> we'll have to work together a lot in the lab. Plus if I use my mountain
>>>> bike I can get there without a car and partially without roads :-)
>>>>
>>>> What you usually find locally is C and sometimes assembler.
>>>> Occasionally
>>>> people know Basic but then that's about it.
>>>>
>>>> It's similar with hardware. Being able to secure local talent is a
>>>> major
>>>> factor driving 8051 family designs. Unfortunately I can't do that with
>>>> the new project because I need a ton more horsepower but first I am
>>>> going to see what the SW guy is familiar with.
>>>
>>> I was actually talking about you learning a language, but either way.
>>>
>>
>> The only language I'd rally like to learn is Spanish :-)
>>
>> But seriously, I do not want to get too involved in the actual
>> programming job because I am fully loaded with analog/mixed projects
>> already and want to reserve at least a few hours per week for mountain
>> biking.
>>
>>
>>> It is funny how in the forth community Forth is considered to be easy to
>>> learn and very facile for many tasks, especially when you need to
>>> interact with hardware or anything else where you don't have all the
>>> details clearly laid out.  But outside that community Forth is treated
>>> like a three eyed toad.
>>>
>>
>> Problem is, there is no Forth community out here. The last die-hard
>> Forth aficionado I personally met was about 30 years ago in Europe.
> 
> I think you may be surprised.  I've already heard from three programmers
> from the few posts I've made in just three groups.  Unless you want me
> to send then directly to you, I am referring them to this thread.
> 

One of them contacted me already. They are sort of local but not really
local-local, like in the same village, down the road from here. We will
have lots of situations such as "Hey, I got stuck with the test rig, can
you come over real quick?" or "The relief valve over yonder blew a
gasket, can you replace it?".

[...]


>>> I am cross posting to the forth group.  Tell us a few details and we'll
>>> see if anyone can accommodate your needs.
>>>
>>
>> Can't reveal too many details but from a code point of view essentially
>> several FFTs, one of them a big one, 1024 point complex (I/Q) every
>> 5msec, overlapping. Extract phase, some complex-conjugate math to
>> extricate component values every 5msec (sort of a poor man's reverse
>> network analysis), followed by filtering, some more math or a LUT, then
>> modulating the result onto an audio carrier. Sprinkled with user
>> interface handling and calibration routines. Back of the envelope calcs
>> indicate that this will reasonably fit into a 100MHz ARM but of course
>> I'd rather have a few more megahoitzes.
> 
> I thought your current project was for an 8051?  I guess that was old
> projects or maybe old programmers... lol. 


No, no, that was just an example for why certain architectures never
die. One on my 8051 projects will soon have it's 20th and no slow-down
in production in sight. On the contrary.


>                                   ... Your other post seemed to be
> talking about bitbanging the I2S port to the CODEC.  How does that work
> into the 100 MHz need?  Bitbanging a serial port of any kind can be CPU
> cycle intensive.
> 

Yes, it is a major concern. We might need to hang an FPGA in there at
least for TX, as a buffer, because essentially we are writing sine
waves. Doesn't work on RX though, that's time-varying stuff. I hope I2S
works for us, somehow. Got to find out.

-- 
Regards, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#33932

On 10/15/2014 7:12 PM, Joerg wrote:
> rickman wrote:
>> On 10/15/2014 8:36 AM, Joerg wrote:
>>> Problem is, there is no Forth community out here. The last die-hard
>>> Forth aficionado I personally met was about 30 years ago in Europe.
>>
>> I think you may be surprised.  I've already heard from three programmers
>> from the few posts I've made in just three groups.  Unless you want me
>> to send then directly to you, I am referring them to this thread.
>>
>
> One of them contacted me already. They are sort of local but not really
> local-local, like in the same village, down the road from here. We will
> have lots of situations such as "Hey, I got stuck with the test rig, can
> you come over real quick?" or "The relief valve over yonder blew a
> gasket, can you replace it?".

So why aren't you working in the same lab?  Then it can be like, 
"Watson, come here.  I want you".

BTW, if you heard from Charley Shattuck, he is a prominent Forth 
programmer.  He is working with a startup that developed a Forth like 
CPU with 144 processors with a peak rate of 700 MIPS each.  This chip 
includes 5 ADC and 5 DAC on chip with variable resolution (trade off 
between speed and resolution, about 15 bits at 48 ksps).  You might talk 
to him about the GA144, it might suit your needs.  It's main limitation 
is each processor has little memory and the I/O is limited.  But I don't 
think you will run out of MIPS.  lol


>>                                    ... Your other post seemed to be
>> talking about bitbanging the I2S port to the CODEC.  How does that work
>> into the 100 MHz need?  Bitbanging a serial port of any kind can be CPU
>> cycle intensive.
>>
>
> Yes, it is a major concern. We might need to hang an FPGA in there at
> least for TX, as a buffer, because essentially we are writing sine
> waves. Doesn't work on RX though, that's time-varying stuff. I hope I2S
> works for us, somehow. Got to find out.

???

What are the specs you need from the ADC?  Do you have numbers and such? 
  I think you mentioned a low drift with temperature.  The GA144 would 
need to be compensated for temperature, but has lots of processing to do 
that.  :)

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#33947

rickman wrote:
> On 10/15/2014 7:12 PM, Joerg wrote:
>> rickman wrote:
>>> On 10/15/2014 8:36 AM, Joerg wrote:
>>>> Problem is, there is no Forth community out here. The last die-hard
>>>> Forth aficionado I personally met was about 30 years ago in Europe.
>>>
>>> I think you may be surprised.  I've already heard from three programmers
>>> from the few posts I've made in just three groups.  Unless you want me
>>> to send then directly to you, I am referring them to this thread.
>>>
>>
>> One of them contacted me already. They are sort of local but not really
>> local-local, like in the same village, down the road from here. We will
>> have lots of situations such as "Hey, I got stuck with the test rig, can
>> you come over real quick?" or "The relief valve over yonder blew a
>> gasket, can you replace it?".
> 
> So why aren't you working in the same lab?  Then it can be like,
> "Watson, come here.  I want you".
> 

Because as mentioned before if both are consultants it creates
confidentiality issues. I have only one room (office plus lab) and
another one mostly used for library and parts storage but not
acoustically shielded. I often have to hop on GoTo or some other service
to discuss another client's issue and then I must be alone. Sometimes
for 1-2h. In contrast to contractors who work one longer assignment at a
time I always have half a dozen or more active clients.


> BTW, if you heard from Charley Shattuck, he is a prominent Forth
> programmer.  He is working with a startup that developed a Forth like
> CPU with 144 processors with a peak rate of 700 MIPS each.  This chip
> includes 5 ADC and 5 DAC on chip with variable resolution (trade off
> between speed and resolution, about 15 bits at 48 ksps).  You might talk
> to him about the GA144, it might suit your needs.  It's main limitation
> is each processor has little memory and the I/O is limited.  But I don't
> think you will run out of MIPS.  lol
> 

Yes, had an email exchange with Charley.

144 processors with 700MIPS each would probably require us to also build
a nuclear power station :-) ... just kidding, I know it's green.

> 
>>>                                    ... Your other post seemed to be
>>> talking about bitbanging the I2S port to the CODEC.  How does that work
>>> into the 100 MHz need?  Bitbanging a serial port of any kind can be CPU
>>> cycle intensive.
>>>
>>
>> Yes, it is a major concern. We might need to hang an FPGA in there at
>> least for TX, as a buffer, because essentially we are writing sine
>> waves. Doesn't work on RX though, that's time-varying stuff. I hope I2S
>> works for us, somehow. Got to find out.
> 
> ???
> 

Well, to send out sine waves. No need to necessarily bother a processor
with that. Or I use a DDS but that can cost in clock synchronicity.


> What are the specs you need from the ADC?  Do you have numbers and such?
>  I think you mentioned a low drift with temperature.  The GA144 would
> need to be compensated for temperature, but has lots of processing to do
> that.  :)
> 

Five needed in total, 18bits or more, 48ksps, differential inputs, BW
from DC to 15kHz, without phase jitter issues. DC-Offset can be handled
via mux and SW-clamping as long as it won't jitter or drift around much.

-- 
Regards, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#33950

On 10/16/2014 2:21 PM, Joerg wrote:
> rickman wrote:
>> On 10/15/2014 7:12 PM, Joerg wrote:
>>> rickman wrote:
>>>> On 10/15/2014 8:36 AM, Joerg wrote:
>>>>> Problem is, there is no Forth community out here. The last die-hard
>>>>> Forth aficionado I personally met was about 30 years ago in Europe.
>>>>
>>>> I think you may be surprised.  I've already heard from three programmers
>>>> from the few posts I've made in just three groups.  Unless you want me
>>>> to send then directly to you, I am referring them to this thread.
>>>>
>>>
>>> One of them contacted me already. They are sort of local but not really
>>> local-local, like in the same village, down the road from here. We will
>>> have lots of situations such as "Hey, I got stuck with the test rig, can
>>> you come over real quick?" or "The relief valve over yonder blew a
>>> gasket, can you replace it?".
>>
>> So why aren't you working in the same lab?  Then it can be like,
>> "Watson, come here.  I want you".
>>
>
> Because as mentioned before if both are consultants it creates
> confidentiality issues. I have only one room (office plus lab) and
> another one mostly used for library and parts storage but not
> acoustically shielded. I often have to hop on GoTo or some other service
> to discuss another client's issue and then I must be alone. Sometimes
> for 1-2h. In contrast to contractors who work one longer assignment at a
> time I always have half a dozen or more active clients.
>
>
>> BTW, if you heard from Charley Shattuck, he is a prominent Forth
>> programmer.  He is working with a startup that developed a Forth like
>> CPU with 144 processors with a peak rate of 700 MIPS each.  This chip
>> includes 5 ADC and 5 DAC on chip with variable resolution (trade off
>> between speed and resolution, about 15 bits at 48 ksps).  You might talk
>> to him about the GA144, it might suit your needs.  It's main limitation
>> is each processor has little memory and the I/O is limited.  But I don't
>> think you will run out of MIPS.  lol
>>
>
> Yes, had an email exchange with Charley.
>
> 144 processors with 700MIPS each would probably require us to also build
> a nuclear power station :-) ... just kidding, I know it's green.

Each processor is very low power when running flat out, just 5 mW.  But 
they almost never run flat out.  Because they are asynchronous they 
spend most of their time stopped when they draw 0.0875 uW, yes, that's 
less than a tenth of a uW for each processor or just 12 uW for the whole 
chip.  The processors respond to stimuli in just nanoseconds, not 100's 
or even 10' but single digit nanoseconds.

Trust me, power will not be a problem with this part.  It is a very 
different beast to program however.


>>>>                                     ... Your other post seemed to be
>>>> talking about bitbanging the I2S port to the CODEC.  How does that work
>>>> into the 100 MHz need?  Bitbanging a serial port of any kind can be CPU
>>>> cycle intensive.
>>>>
>>>
>>> Yes, it is a major concern. We might need to hang an FPGA in there at
>>> least for TX, as a buffer, because essentially we are writing sine
>>> waves. Doesn't work on RX though, that's time-varying stuff. I hope I2S
>>> works for us, somehow. Got to find out.
>>
>> ???
>>
>
> Well, to send out sine waves. No need to necessarily bother a processor
> with that. Or I use a DDS but that can cost in clock synchronicity.

Every problem in your design is asking for an FPGA.


>> What are the specs you need from the ADC?  Do you have numbers and such?
>>   I think you mentioned a low drift with temperature.  The GA144 would
>> need to be compensated for temperature, but has lots of processing to do
>> that.  :)
>>
>
> Five needed in total, 18bits or more, 48ksps, differential inputs, BW
> from DC to 15kHz, without phase jitter issues. DC-Offset can be handled
> via mux and SW-clamping as long as it won't jitter or drift around much.

"phase jitter issues" and "won't jitter or drift around much" aren't 
specs.  18 bits of what exactly?  I have seen lots of devices with 24 
bits but only 96 dB SNR.  Do you need 108 dB SNR?  You won't get that 
from the GA144 ADCs at 48 kHz.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#33955

rickman wrote:
> On 10/16/2014 2:21 PM, Joerg wrote:
>> rickman wrote:
>>> On 10/15/2014 7:12 PM, Joerg wrote:
>>>> rickman wrote:
>>>>> On 10/15/2014 8:36 AM, Joerg wrote:
>>>>>> Problem is, there is no Forth community out here. The last die-hard
>>>>>> Forth aficionado I personally met was about 30 years ago in Europe.
>>>>>
>>>>> I think you may be surprised.  I've already heard from three
>>>>> programmers
>>>>> from the few posts I've made in just three groups.  Unless you want me
>>>>> to send then directly to you, I am referring them to this thread.
>>>>>
>>>>
>>>> One of them contacted me already. They are sort of local but not really
>>>> local-local, like in the same village, down the road from here. We will
>>>> have lots of situations such as "Hey, I got stuck with the test rig,
>>>> can
>>>> you come over real quick?" or "The relief valve over yonder blew a
>>>> gasket, can you replace it?".
>>>
>>> So why aren't you working in the same lab?  Then it can be like,
>>> "Watson, come here.  I want you".
>>>
>>
>> Because as mentioned before if both are consultants it creates
>> confidentiality issues. I have only one room (office plus lab) and
>> another one mostly used for library and parts storage but not
>> acoustically shielded. I often have to hop on GoTo or some other service
>> to discuss another client's issue and then I must be alone. Sometimes
>> for 1-2h. In contrast to contractors who work one longer assignment at a
>> time I always have half a dozen or more active clients.
>>
>>
>>> BTW, if you heard from Charley Shattuck, he is a prominent Forth
>>> programmer.  He is working with a startup that developed a Forth like
>>> CPU with 144 processors with a peak rate of 700 MIPS each.  This chip
>>> includes 5 ADC and 5 DAC on chip with variable resolution (trade off
>>> between speed and resolution, about 15 bits at 48 ksps).  You might talk
>>> to him about the GA144, it might suit your needs.  It's main limitation
>>> is each processor has little memory and the I/O is limited.  But I don't
>>> think you will run out of MIPS.  lol
>>>
>>
>> Yes, had an email exchange with Charley.
>>
>> 144 processors with 700MIPS each would probably require us to also build
>> a nuclear power station :-) ... just kidding, I know it's green.
> 
> Each processor is very low power when running flat out, just 5 mW.  But
> they almost never run flat out.  Because they are asynchronous they
> spend most of their time stopped when they draw 0.0875 uW, yes, that's
> less than a tenth of a uW for each processor or just 12 uW for the whole
> chip.  The processors respond to stimuli in just nanoseconds, not 100's
> or even 10' but single digit nanoseconds.
> 
> Trust me, power will not be a problem with this part.  It is a very
> different beast to program however.
> 

I wonder how that company is doing. I read about their products years
ago but never seen any in schematics and I get to see a lot of new stuff
because some of my daily bread is EMC remedy.

> 
>>>>>                                     ... Your other post seemed to be
>>>>> talking about bitbanging the I2S port to the CODEC.  How does that
>>>>> work
>>>>> into the 100 MHz need?  Bitbanging a serial port of any kind can be
>>>>> CPU
>>>>> cycle intensive.
>>>>>
>>>>
>>>> Yes, it is a major concern. We might need to hang an FPGA in there at
>>>> least for TX, as a buffer, because essentially we are writing sine
>>>> waves. Doesn't work on RX though, that's time-varying stuff. I hope I2S
>>>> works for us, somehow. Got to find out.
>>>
>>> ???
>>>
>>
>> Well, to send out sine waves. No need to necessarily bother a processor
>> with that. Or I use a DDS but that can cost in clock synchronicity.
> 
> Every problem in your design is asking for an FPGA.
> 

Possible, but not sure yet. Maybe there is a bigger processor out there
with real I2S/TDM and enough support by the manufacturer.


> 
>>> What are the specs you need from the ADC?  Do you have numbers and such?
>>>   I think you mentioned a low drift with temperature.  The GA144 would
>>> need to be compensated for temperature, but has lots of processing to do
>>> that.  :)
>>>
>>
>> Five needed in total, 18bits or more, 48ksps, differential inputs, BW
>> from DC to 15kHz, without phase jitter issues. DC-Offset can be handled
>> via mux and SW-clamping as long as it won't jitter or drift around much.
> 
> "phase jitter issues" and "won't jitter or drift around much" aren't
> specs. 


What I mean is that ADCs on processors generally cannot hold jitter low
enough to truly deliver a 96dB SNR. I found that even 12 bits on-chip is
already a serious challenge.


 18 bits of what exactly?  I have seen lots of devices with 24
> bits but only 96 dB SNR.  Do you need 108 dB SNR?  You won't get that
> from the GA144 ADCs at 48 kHz.
> 

True 96dB across DC-15kHz would be enough.

-- 
Regards, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#33958

On 10/16/2014 4:37 PM, Joerg wrote:
> rickman wrote:
>>
>> Each processor is very low power when running flat out, just 5 mW.  But
>> they almost never run flat out.  Because they are asynchronous they
>> spend most of their time stopped when they draw 0.0875 uW, yes, that's
>> less than a tenth of a uW for each processor or just 12 uW for the whole
>> chip.  The processors respond to stimuli in just nanoseconds, not 100's
>> or even 10' but single digit nanoseconds.
>>
>> Trust me, power will not be a problem with this part.  It is a very
>> different beast to program however.
>>
>
> I wonder how that company is doing. I read about their products years
> ago but never seen any in schematics and I get to see a lot of new stuff
> because some of my daily bread is EMC remedy.

I think they are doing ok, but mainly because they have nearly zero 
overhead.  They don't pay any salaries so no need for layoffs.


>> Every problem in your design is asking for an FPGA.
>>
>
> Possible, but not sure yet. Maybe there is a bigger processor out there
> with real I2S/TDM and enough support by the manufacturer.

Yeah, maybe.  You can go with one of the Cortex A processors like they 
use in the Beagle board or Raspberry Pi.  Without the Linux OS they 
should so a decent job.  They have floating point for your FFTs as well. 
  That will help prevent too much rounding noise in the FFTs.


>>>> What are the specs you need from the ADC?  Do you have numbers and such?
>>>>    I think you mentioned a low drift with temperature.  The GA144 would
>>>> need to be compensated for temperature, but has lots of processing to do
>>>> that.  :)
>>>>
>>>
>>> Five needed in total, 18bits or more, 48ksps, differential inputs, BW
>>> from DC to 15kHz, without phase jitter issues. DC-Offset can be handled
>>> via mux and SW-clamping as long as it won't jitter or drift around much.
>>
>> "phase jitter issues" and "won't jitter or drift around much" aren't
>> specs.
>
>
> What I mean is that ADCs on processors generally cannot hold jitter low
> enough to truly deliver a 96dB SNR. I found that even 12 bits on-chip is
> already a serious challenge.
>
>
>   18 bits of what exactly?  I have seen lots of devices with 24
>> bits but only 96 dB SNR.  Do you need 108 dB SNR?  You won't get that
>> from the GA144 ADCs at 48 kHz.
>>
>
> True 96dB across DC-15kHz would be enough.

So a 16 bit part with DC coupling would be good enough?  The market is 
*littered* with those.  I've seen a bazillion 18 bit SAR parts out 
there.  Even LT has them, your favorite company.  Why not use one of 
those?  They often have fantastic SNR and THD specs.

How about an 8 channel, 16 bit ADC in one package?

http://www.linear.com/product/LTC1867L

Well, maybe not.  The SINAD is not so good.  What is the frequency of 
the signal you are looking at?  The ADC specs also depend on your input 
frequency.

The point is that if you can drop the I2S interface you have a lot more 
potential MCUs to choose from.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#33977

rickman wrote:
> On 10/16/2014 4:37 PM, Joerg wrote:
>> rickman wrote:
>>>
>>> Each processor is very low power when running flat out, just 5 mW.  But
>>> they almost never run flat out.  Because they are asynchronous they
>>> spend most of their time stopped when they draw 0.0875 uW, yes, that's
>>> less than a tenth of a uW for each processor or just 12 uW for the whole
>>> chip.  The processors respond to stimuli in just nanoseconds, not 100's
>>> or even 10' but single digit nanoseconds.
>>>
>>> Trust me, power will not be a problem with this part.  It is a very
>>> different beast to program however.
>>>
>>
>> I wonder how that company is doing. I read about their products years
>> ago but never seen any in schematics and I get to see a lot of new stuff
>> because some of my daily bread is EMC remedy.
> 
> I think they are doing ok, but mainly because they have nearly zero
> overhead.  They don't pay any salaries so no need for layoffs.
> 

Wow. So they all work for free? How do they make a living?

> 
>>> Every problem in your design is asking for an FPGA.
>>>
>>
>> Possible, but not sure yet. Maybe there is a bigger processor out there
>> with real I2S/TDM and enough support by the manufacturer.
> 
> Yeah, maybe.  You can go with one of the Cortex A processors like they
> use in the Beagle board or Raspberry Pi.  Without the Linux OS they
> should so a decent job.  They have floating point for your FFTs as well.
>  That will help prevent too much rounding noise in the FFTs.
> 

Except the Sitaras in QFP have been obsoleted. But I'll find something.

> 
>>>>> What are the specs you need from the ADC?  Do you have numbers and
>>>>> such?
>>>>>    I think you mentioned a low drift with temperature.  The GA144
>>>>> would
>>>>> need to be compensated for temperature, but has lots of processing
>>>>> to do
>>>>> that.  :)
>>>>>
>>>>
>>>> Five needed in total, 18bits or more, 48ksps, differential inputs, BW
>>>> from DC to 15kHz, without phase jitter issues. DC-Offset can be handled
>>>> via mux and SW-clamping as long as it won't jitter or drift around
>>>> much.
>>>
>>> "phase jitter issues" and "won't jitter or drift around much" aren't
>>> specs.
>>
>>
>> What I mean is that ADCs on processors generally cannot hold jitter low
>> enough to truly deliver a 96dB SNR. I found that even 12 bits on-chip is
>> already a serious challenge.
>>
>>
>>   18 bits of what exactly?  I have seen lots of devices with 24
>>> bits but only 96 dB SNR.  Do you need 108 dB SNR?  You won't get that
>>> from the GA144 ADCs at 48 kHz.
>>>
>>
>> True 96dB across DC-15kHz would be enough.
> 
> So a 16 bit part with DC coupling would be good enough?  


No, because ENOB counts and there you need around 18 bits.


>                                               ... The market is
> *littered* with those.  I've seen a bazillion 18 bit SAR parts out
> there.  Even LT has them, your favorite company.  Why not use one of
> those?  They often have fantastic SNR and THD specs.
> 
> How about an 8 channel, 16 bit ADC in one package?
> 
> http://www.linear.com/product/LTC1867L
> 
> Well, maybe not.  The SINAD is not so good.  What is the frequency of
> the signal you are looking at?  The ADC specs also depend on your input
> frequency.
> 

DC to 20kHz but that requirement can be dropped to 10kHz. Also, if I
really, really had to, I could replace one of the two DACs with a DDS
chip because that just generates a sine wave. But it complicates the SW
because such chips need their own SPI sermons in Swahili.


> The point is that if you can drop the I2S interface you have a lot more
> potential MCUs to choose from.
> 

Sure, if the CPU can manage to keep seven balls in the air and serve all
those SPI device at 48ksps.

-- 
Regards, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#33985

On 10/17/2014 10:14 AM, Joerg wrote:
> rickman wrote:
>> On 10/16/2014 4:37 PM, Joerg wrote:
>>> rickman wrote:
>>>>
>>>> Each processor is very low power when running flat out, just 5 mW.  But
>>>> they almost never run flat out.  Because they are asynchronous they
>>>> spend most of their time stopped when they draw 0.0875 uW, yes, that's
>>>> less than a tenth of a uW for each processor or just 12 uW for the whole
>>>> chip.  The processors respond to stimuli in just nanoseconds, not 100's
>>>> or even 10' but single digit nanoseconds.
>>>>
>>>> Trust me, power will not be a problem with this part.  It is a very
>>>> different beast to program however.
>>>>
>>>
>>> I wonder how that company is doing. I read about their products years
>>> ago but never seen any in schematics and I get to see a lot of new stuff
>>> because some of my daily bread is EMC remedy.
>>
>> I think they are doing ok, but mainly because they have nearly zero
>> overhead.  They don't pay any salaries so no need for layoffs.
>>
>
> Wow. So they all work for free? How do they make a living?

I believe many of them are functionally retired and don't need to work. 
  Others work part time and do consulting.


>>>> Every problem in your design is asking for an FPGA.
>>>>
>>>
>>> Possible, but not sure yet. Maybe there is a bigger processor out there
>>> with real I2S/TDM and enough support by the manufacturer.
>>
>> Yeah, maybe.  You can go with one of the Cortex A processors like they
>> use in the Beagle board or Raspberry Pi.  Without the Linux OS they
>> should so a decent job.  They have floating point for your FFTs as well.
>>   That will help prevent too much rounding noise in the FFTs.
>>
>
> Except the Sitaras in QFP have been obsoleted. But I'll find something.

Yeah, it will be hard to find anything more powerful in QFP.  Normally 
they need a high pin count which requires BGA.  All of the higher end 
devices I have seen use external memory which pushes the pin count over 
the top for QFP unless you can find one in a 208 pin QFP.


>>>>>> What are the specs you need from the ADC?  Do you have numbers and
>>>>>> such?
>>>>>>     I think you mentioned a low drift with temperature.  The GA144
>>>>>> would
>>>>>> need to be compensated for temperature, but has lots of processing
>>>>>> to do
>>>>>> that.  :)
>>>>>>
>>>>>
>>>>> Five needed in total, 18bits or more, 48ksps, differential inputs, BW
>>>>> from DC to 15kHz, without phase jitter issues. DC-Offset can be handled
>>>>> via mux and SW-clamping as long as it won't jitter or drift around
>>>>> much.
>>>>
>>>> "phase jitter issues" and "won't jitter or drift around much" aren't
>>>> specs.
>>>
>>>
>>> What I mean is that ADCs on processors generally cannot hold jitter low
>>> enough to truly deliver a 96dB SNR. I found that even 12 bits on-chip is
>>> already a serious challenge.
>>>
>>>
>>>    18 bits of what exactly?  I have seen lots of devices with 24
>>>> bits but only 96 dB SNR.  Do you need 108 dB SNR?  You won't get that
>>>> from the GA144 ADCs at 48 kHz.
>>>>
>>>
>>> True 96dB across DC-15kHz would be enough.
>>
>> So a 16 bit part with DC coupling would be good enough?
>
>
> No, because ENOB counts and there you need around 18 bits.
>
>
>>                                                ... The market is
>> *littered* with those.  I've seen a bazillion 18 bit SAR parts out
>> there.  Even LT has them, your favorite company.  Why not use one of
>> those?  They often have fantastic SNR and THD specs.
>>
>> How about an 8 channel, 16 bit ADC in one package?
>>
>> http://www.linear.com/product/LTC1867L
>>
>> Well, maybe not.  The SINAD is not so good.  What is the frequency of
>> the signal you are looking at?  The ADC specs also depend on your input
>> frequency.
>>
>
> DC to 20kHz but that requirement can be dropped to 10kHz. Also, if I
> really, really had to, I could replace one of the two DACs with a DDS
> chip because that just generates a sine wave. But it complicates the SW
> because such chips need their own SPI sermons in Swahili.

I don't see a DDS as being much more simple than a DAC with a lookup 
table.  What varies on the sine wave?  Does it have a slight frequency 
variation or amplitude?


>> The point is that if you can drop the I2S interface you have a lot more
>> potential MCUs to choose from.
>>
>
> Sure, if the CPU can manage to keep seven balls in the air and serve all
> those SPI device at 48ksps.

I have no idea why you think that is a problem.  This isn't juggling. 
This is electronics design and driving data over a few SPI ports that 
can all be managed though one port is not at all hard.  I think you are 
missing the "CONVERT" signal.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#33986

rickman wrote:
> On 10/17/2014 10:14 AM, Joerg wrote:
>> rickman wrote:
>>> On 10/16/2014 4:37 PM, Joerg wrote:
>>>> rickman wrote:
>>>>>
>>>>> Each processor is very low power when running flat out, just 5 mW. 
>>>>> But
>>>>> they almost never run flat out.  Because they are asynchronous they
>>>>> spend most of their time stopped when they draw 0.0875 uW, yes, that's
>>>>> less than a tenth of a uW for each processor or just 12 uW for the
>>>>> whole
>>>>> chip.  The processors respond to stimuli in just nanoseconds, not
>>>>> 100's
>>>>> or even 10' but single digit nanoseconds.
>>>>>
>>>>> Trust me, power will not be a problem with this part.  It is a very
>>>>> different beast to program however.
>>>>>
>>>>
>>>> I wonder how that company is doing. I read about their products years
>>>> ago but never seen any in schematics and I get to see a lot of new
>>>> stuff
>>>> because some of my daily bread is EMC remedy.
>>>
>>> I think they are doing ok, but mainly because they have nearly zero
>>> overhead.  They don't pay any salaries so no need for layoffs.
>>>
>>
>> Wow. So they all work for free? How do they make a living?
> 
> I believe many of them are functionally retired and don't need to work.
>  Others work part time and do consulting.
> 

So I guess they are hoping the company some day lands it big, their
equity stake turns into pure gold and then they can buy a Cessna
Citation with a matching tropical island :-)

> 
>>>>> Every problem in your design is asking for an FPGA.
>>>>>
>>>>
>>>> Possible, but not sure yet. Maybe there is a bigger processor out there
>>>> with real I2S/TDM and enough support by the manufacturer.
>>>
>>> Yeah, maybe.  You can go with one of the Cortex A processors like they
>>> use in the Beagle board or Raspberry Pi.  Without the Linux OS they
>>> should so a decent job.  They have floating point for your FFTs as well.
>>>   That will help prevent too much rounding noise in the FFTs.
>>>
>>
>> Except the Sitaras in QFP have been obsoleted. But I'll find something.
> 
> Yeah, it will be hard to find anything more powerful in QFP.  Normally
> they need a high pin count which requires BGA.  All of the higher end
> devices I have seen use external memory which pushes the pin count over
> the top for QFP unless you can find one in a 208 pin QFP.
> 

It would be nice not to need external memory. Don't want this to turn
into a monster with an RTOS, its own government and all that.

[...]

                                      ... The market is
>>> *littered* with those.  I've seen a bazillion 18 bit SAR parts out
>>> there.  Even LT has them, your favorite company.  Why not use one of
>>> those?  They often have fantastic SNR and THD specs.
>>>
>>> How about an 8 channel, 16 bit ADC in one package?
>>>
>>> http://www.linear.com/product/LTC1867L
>>>
>>> Well, maybe not.  The SINAD is not so good.  What is the frequency of
>>> the signal you are looking at?  The ADC specs also depend on your input
>>> frequency.
>>>
>>
>> DC to 20kHz but that requirement can be dropped to 10kHz. Also, if I
>> really, really had to, I could replace one of the two DACs with a DDS
>> chip because that just generates a sine wave. But it complicates the SW
>> because such chips need their own SPI sermons in Swahili.
> 
> I don't see a DDS as being much more simple than a DAC with a lookup
> table.  What varies on the sine wave?  Does it have a slight frequency
> variation or amplitude?
> 

The sine wave is constant in normal operation, except during a sweep
phase at the start. So a DDS would greatly cut down on data volume.
During operation it would not require any data sent over the SPI.

> 
>>> The point is that if you can drop the I2S interface you have a lot more
>>> potential MCUs to choose from.
>>>
>>
>> Sure, if the CPU can manage to keep seven balls in the air and serve all
>> those SPI device at 48ksps.
> 
> I have no idea why you think that is a problem.  This isn't juggling.
> This is electronics design and driving data over a few SPI ports that
> can all be managed though one port is not at all hard.  I think you are
> missing the "CONVERT" signal.
> 

I know how the hardware goes, done a ton of SPI designs with
synchronicity requirements and they all work. What I am concerned about
is the barrage of data inside the CPU that wants in and out. Something
in there has to slosh that around. AFAIU in a TDM scenario it would
simply flow nicely in a serial fashion. But that's where I'd have to
hand it over to SW experts because I am not a programmer.

-- 
Regards, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#33987

On 10/17/2014 3:03 PM, Joerg wrote:
> rickman wrote:
>> On 10/17/2014 10:14 AM, Joerg wrote:
>>> rickman wrote:
>>>>
>>>> I think they are doing ok, but mainly because they have nearly zero
>>>> overhead.  They don't pay any salaries so no need for layoffs.
>>>>
>>>
>>> Wow. So they all work for free? How do they make a living?
>>
>> I believe many of them are functionally retired and don't need to work.
>>   Others work part time and do consulting.
>>
>
> So I guess they are hoping the company some day lands it big, their
> equity stake turns into pure gold and then they can buy a Cessna
> Citation with a matching tropical island :-)

I think they are just along for the ride and trying to have fun.


>>>> Yeah, maybe.  You can go with one of the Cortex A processors like they
>>>> use in the Beagle board or Raspberry Pi.  Without the Linux OS they
>>>> should so a decent job.  They have floating point for your FFTs as well.
>>>>    That will help prevent too much rounding noise in the FFTs.
>>>>
>>>
>>> Except the Sitaras in QFP have been obsoleted. But I'll find something.
>>
>> Yeah, it will be hard to find anything more powerful in QFP.  Normally
>> they need a high pin count which requires BGA.  All of the higher end
>> devices I have seen use external memory which pushes the pin count over
>> the top for QFP unless you can find one in a 208 pin QFP.
>>
>
> It would be nice not to need external memory. Don't want this to turn
> into a monster with an RTOS, its own government and all that.

There is nothing about a processor that requires an OS.  It is the 
system requirements that determine if an OS is needed.


>                                        ... The market is
>>>> *littered* with those.  I've seen a bazillion 18 bit SAR parts out
>>>> there.  Even LT has them, your favorite company.  Why not use one of
>>>> those?  They often have fantastic SNR and THD specs.
>>>>
>>>> How about an 8 channel, 16 bit ADC in one package?
>>>>
>>>> http://www.linear.com/product/LTC1867L
>>>>
>>>> Well, maybe not.  The SINAD is not so good.  What is the frequency of
>>>> the signal you are looking at?  The ADC specs also depend on your input
>>>> frequency.
>>>>
>>>
>>> DC to 20kHz but that requirement can be dropped to 10kHz. Also, if I
>>> really, really had to, I could replace one of the two DACs with a DDS
>>> chip because that just generates a sine wave. But it complicates the SW
>>> because such chips need their own SPI sermons in Swahili.
>>
>> I don't see a DDS as being much more simple than a DAC with a lookup
>> table.  What varies on the sine wave?  Does it have a slight frequency
>> variation or amplitude?
>>
>
> The sine wave is constant in normal operation, except during a sweep
> phase at the start. So a DDS would greatly cut down on data volume.
> During operation it would not require any data sent over the SPI.
>
>>
>>>> The point is that if you can drop the I2S interface you have a lot more
>>>> potential MCUs to choose from.
>>>>
>>>
>>> Sure, if the CPU can manage to keep seven balls in the air and serve all
>>> those SPI device at 48ksps.
>>
>> I have no idea why you think that is a problem.  This isn't juggling.
>> This is electronics design and driving data over a few SPI ports that
>> can all be managed though one port is not at all hard.  I think you are
>> missing the "CONVERT" signal.
>>
>
> I know how the hardware goes, done a ton of SPI designs with
> synchronicity requirements and they all work. What I am concerned about
> is the barrage of data inside the CPU that wants in and out. Something
> in there has to slosh that around. AFAIU in a TDM scenario it would
> simply flow nicely in a serial fashion. But that's where I'd have to
> hand it over to SW experts because I am not a programmer.

I can assure you that what you are calling a barrage of data is nothing 
to even give a second thought to.  Remember, you are performing a 
multiple 1024 point FFTs every 256 samples.  I expect the processor 
impact to be at least a 10:1 ratio not even counting the other 
processing you need.  Handling the interface will be in the noise as 
long as you aren't bit banging.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#33988

rickman wrote:
> On 10/17/2014 3:03 PM, Joerg wrote:
>> rickman wrote:
>>> On 10/17/2014 10:14 AM, Joerg wrote:
>>>> rickman wrote:
>>>>>
>>>>> I think they are doing ok, but mainly because they have nearly zero
>>>>> overhead.  They don't pay any salaries so no need for layoffs.
>>>>>
>>>>
>>>> Wow. So they all work for free? How do they make a living?
>>>
>>> I believe many of them are functionally retired and don't need to work.
>>>   Others work part time and do consulting.
>>>
>>
>> So I guess they are hoping the company some day lands it big, their
>> equity stake turns into pure gold and then they can buy a Cessna
>> Citation with a matching tropical island :-)
> 
> I think they are just along for the ride and trying to have fun.
> 

Why not? I can't imagine this being much fun but I am not a processor
guy so I can't judge that.


> 
>>>>> Yeah, maybe.  You can go with one of the Cortex A processors like they
>>>>> use in the Beagle board or Raspberry Pi.  Without the Linux OS they
>>>>> should so a decent job.  They have floating point for your FFTs as
>>>>> well.
>>>>>    That will help prevent too much rounding noise in the FFTs.
>>>>>
>>>>
>>>> Except the Sitaras in QFP have been obsoleted. But I'll find something.
>>>
>>> Yeah, it will be hard to find anything more powerful in QFP.  Normally
>>> they need a high pin count which requires BGA.  All of the higher end
>>> devices I have seen use external memory which pushes the pin count over
>>> the top for QFP unless you can find one in a 208 pin QFP.
>>>
>>
>> It would be nice not to need external memory. Don't want this to turn
>> into a monster with an RTOS, its own government and all that.
> 
> There is nothing about a processor that requires an OS.  It is the
> system requirements that determine if an OS is needed.
> 

I know. Should have placed a smiley. I just meant that I don't want this
to turn into a major science project.

[...]

>>>>> The point is that if you can drop the I2S interface you have a lot
>>>>> more
>>>>> potential MCUs to choose from.
>>>>>
>>>>
>>>> Sure, if the CPU can manage to keep seven balls in the air and serve
>>>> all
>>>> those SPI device at 48ksps.
>>>
>>> I have no idea why you think that is a problem.  This isn't juggling.
>>> This is electronics design and driving data over a few SPI ports that
>>> can all be managed though one port is not at all hard.  I think you are
>>> missing the "CONVERT" signal.
>>>
>>
>> I know how the hardware goes, done a ton of SPI designs with
>> synchronicity requirements and they all work. What I am concerned about
>> is the barrage of data inside the CPU that wants in and out. Something
>> in there has to slosh that around. AFAIU in a TDM scenario it would
>> simply flow nicely in a serial fashion. But that's where I'd have to
>> hand it over to SW experts because I am not a programmer.
> 
> I can assure you that what you are calling a barrage of data is nothing
> to even give a second thought to.  Remember, you are performing a
> multiple 1024 point FFTs every 256 samples.  I expect the processor
> impact to be at least a 10:1 ratio not even counting the other
> processing you need.  


A 100MHz ARM would be loaded to 50% with all the FFTs and other calcs
running. So if the SPI takes up another 20% we'd still have sufficient
reserves. I don't like to go past 70% on CPU load becasue there will
always be some sort of feature creep.


Handling the interface will be in the noise as
> long as you aren't bit banging.
> 

Well, let's hope so. In that case we could use any SPI ADC/DAC. But most
are audio so they come in I2S fashion. There isn't much out there in
generic converters once you need 18 bits or more.

-- 
Regards, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#33989

On 10/17/2014 3:44 PM, Joerg wrote:
>
> A 100MHz ARM would be loaded to 50% with all the FFTs and other calcs
> running. So if the SPI takes up another 20% we'd still have sufficient
> reserves. I don't like to go past 70% on CPU load becasue there will
> always be some sort of feature creep.

If I were doing this I would just go with the Blackfin and forget the 
ARM.  The Blackfin is a DSP device with lots of support for doing DSP. 
It has much more performance and the only down side I can see is that it 
needs an external flash for program store.


> rickman wrote:
> > Handling the interface will be in the noise as
>> long as you aren't bit banging.
>>
>
> Well, let's hope so. In that case we could use any SPI ADC/DAC. But most
> are audio so they come in I2S fashion. There isn't much out there in
> generic converters once you need 18 bits or more.

Are you kidding?  Did you look at the ADI link I posted?  ADI makes 
dozens and I believe TI makes just as many up to 20 bits and more. 
There is a market segment that matches the technology in SAR devices 
called "control".  Sound familiar?  They don't need to be as fast as 
flash converters and so can be made much lower power while still 
achieving MSPS rates.  The market for audio is a lot bigger, so the 
audio portfolios are larger.

The big disadvantage for control of most audio devices are the large 
delay times of the digital filters required to make sigma-delta 
conversion work.  It seems your application doesn't have that concern.

I think the AD1939 has around 0.5 ms delay, that is each way both ADC 
and DAC.  Also many of them are AC coupled.  I use an AKM part on the 
board I produce and they work just fine, but no DC path.  This is an 
audio app so it's fine.

Here is a link for TI showing 24 potential ADCs.  Some of them are up to 
8 channel.

http://www.ti.com/lsds/ti/data-converters/precision-adc-less-10msps-products.page#p1089=48000;12500000&p84=18;24&p989typ=0.21;135&p89=

Here is the link for ADI parts of 18 bits at 48 kSPS

http://www.linear.com/parametric/html/Analog-to-Digital_Converters_%28ADC%29?undefined&c[1049][]=18||*&c[1097][]=48000||*&inputs=&resmin=18&resmax=&spmin=48&spmax=&interface=&qs=1


-- 

Rick

[toc] | [prev] | [next] | [standalone]

#33969

On 10/16/2014 4:37 PM, Joerg wrote:
> rickman wrote:
>> Each processor is very low power when running flat out, just 5 mW.  But
>> they almost never run flat out.  Because they are asynchronous they
>> spend most of their time stopped when they draw 0.0875 uW, yes, that's
>> less than a tenth of a uW for each processor or just 12 uW for the whole
>> chip.  The processors respond to stimuli in just nanoseconds, not 100's
>> or even 10' but single digit nanoseconds.
>>
>> Trust me, power will not be a problem with this part.  It is a very
>> different beast to program however.
>>
>
> I wonder how that company is doing. I read about their products years
> ago but never seen any in schematics and I get to see a lot of new stuff
> because some of my daily bread is EMC remedy.

All kidding aside, your application may be one that is well suited to 
the GA144.  With your data rates the GA144 can certainly keep up 
processing wise.  The CODEC I/O would be no problem at all.  The I2S 
interface can be bit banged by 700 MHz processors.

The only issues would be designing the algorithms to perform the signal 
processing.  There is no math library that I know of.  So you would need 
to design your own.

I think the chip would be running at a small fraction of a watt.  With 
every node running flat out the power consumption is under a watt.


> What I mean is that ADCs on processors generally cannot hold jitter low
> enough to truly deliver a 96dB SNR. I found that even 12 bits on-chip is
> already a serious challenge.

Not that it is a serious contender, but ADI makes an old ARM7 chip with 
16 bit ADCs on board, not sure how many, I don't think it was five, it 
may have been four.  It was only 33 MHz and doesn't have any of the DSP 
like instructions.  But they designed it with the analog in mind.  I 
seem to recall they marketed it with their ADC families rather than with 
their processors.


>   18 bits of what exactly?  I have seen lots of devices with 24
>> bits but only 96 dB SNR.  Do you need 108 dB SNR?  You won't get that
>> from the GA144 ADCs at 48 kHz.
>>
>
> True 96dB across DC-15kHz would be enough.

The GA144 ADCs are just not quite there.  Like I said, they get 15 bits 
at 48 kHz sample rate.  I don't recall how slow the sampling needs to be 
to get 16 bits (96 dB nominally).  Likely it is about 12 kHz.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#33971

In article <m1ppm6$jvr$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
<SNIP>
>
>The GA144 ADCs are just not quite there.  Like I said, they get 15 bits
>at 48 kHz sample rate.  I don't recall how slow the sampling needs to be
>to get 16 bits (96 dB nominally).  Likely it is about 12 kHz.

The important point here is that on the GA144 you can get better
resolution by slowing down, and higher speed by scarificing
resolution. Or so they say.

>
>--
>
>Rick

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#33984

On 10/17/2014 4:43 AM, Albert van der Horst wrote:
> In article <m1ppm6$jvr$1@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
> <SNIP>
>>
>> The GA144 ADCs are just not quite there.  Like I said, they get 15 bits
>> at 48 kHz sample rate.  I don't recall how slow the sampling needs to be
>> to get 16 bits (96 dB nominally).  Likely it is about 12 kHz.
>
> The important point here is that on the GA144 you can get better
> resolution by slowing down, and higher speed by scarificing
> resolution. Or so they say.

Yes, it is an integrator in the true sense.  It has a VFO which is 
controlled by the analog input and increments a counter.  The period is 
set by reading the counter at defined intervals and taking the 
difference.  The VFO curve is not exactly linear, so it needs to be 
corrected in software as well.

The interesting part is that you can add adjacent readings and get the 
same result as if you were reading the counter at a slower rate.  So the 
added resolution can be done in software without changing the actual 
read rate.  If that is set by a stable clock like a crystal it doesn't 
need to be slowed down to have variable rate and resolution.

I think I was confusing two things.  When you are looking at improving 
SNR, adding samples gains SNR by the square root of the number of 
samples.  Gains in resolution are logarithmic with the number of 
samples, so halving the sample rate gets you 1 extra bit meaning the 
GA144 ADCs will get 16 bit resolution around 24 kHz sample rate.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web