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 2 of 2 — ← Prev page 1 [2]

#33978

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.
> 
> 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.
> 

That is something we really want to avoid. Funding for this project is
not unlimited but most of all there isn't an infinite amount of time. So
we'd like to rely of pre-canned packages for complex FFT, phase
calculations, IIR/FIR filtering, Goertzel and so on.


> 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.
> 

That would of course be nice but 5W would be fine as well. Meaning we'll
need a QFP with a heat sink pad underneath.

> 
>> 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.
> 

That's too slow and also ADCs on board of CPUs usually have subpar noise
behavior, IME. I don't know that processor but don't want to take the
chance because you won't discover until at the very end of the project.

> 
>>   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.
> 

In order to reach 96dB the ENOB has to be 16 bits at max speed, meaning
in reality most ADC would have to provide 18 bits.

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

#33933

> >                                   ... 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.
> 
Probably I'm plain wrong because I don't know anything about your application, but there are plenty ARM Corthex-M chips with I2S ports. For example, my LPC4088 has I2S with internal FIFO, separate PLL, etc. I can generate 48kHz 16bit audio stereo only with interrupts, no even need for DMA. My system runs at 120MHz.

Raimond

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

#33936

On 10/15/2014 11:42 PM, Raimond Dragomir wrote:
>>>                                    ... 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.
>>
> Probably I'm plain wrong because I don't know anything about your application, but there are plenty ARM Corthex-M chips with I2S ports. For example, my LPC4088 has I2S with internal FIFO, separate PLL, etc. I can generate 48kHz 16bit audio stereo only with interrupts, no even need for DMA. My system runs at 120MHz.

You only replied in the c.l.f group so he won't likely see your 
response.  I'm sure he is reading this in the s.e.d group.

Some other devices have been mentioned to him already.  Joerg is an 
engineer with a lot of "preference".  He won't use MCU parts from a 
company he feels doesn't give good support so many of them are not in 
the running.  I know he has mentioned STM as a no-go.   I don't know 
about NXP.  I do know that NXP ARMs have a huge and very active 
community which can give good support.

I find it interesting that he wants to use a CODEC with an I2S port 
which requires 8 channels (not always supported even if there is an I2S 
port), but hasn't considered that in his selection criteria until now.

-- 

Rick

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

#33937

> Some other devices have been mentioned to him already.  Joerg is an 
> 
> engineer with a lot of "preference".  He won't use MCU parts from a 
> 
> company he feels doesn't give good support so many of them are not in 
> 
> the running.  I know he has mentioned STM as a no-go.   I don't know 
> 
> about NXP.  I do know that NXP ARMs have a huge and very active 
> 
> community which can give good support.

This quite common behaviour, at least among hardware engineers :)

> 
> 
> 
> I find it interesting that he wants to use a CODEC with an I2S port 
> 
> which requires 8 channels (not always supported even if there is an I2S 
> 
> port), but hasn't considered that in his selection criteria until now.
> 
He may be out of luck in this case, unless he finds something that will support TDM over the I2S port. AFAIK, there aren't microcontrollers with that kind of I2S ports, in fact I'm not aware of any such I2S controller.

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

#33939

On 10/16/2014 3:49 AM, Raimond Dragomir wrote:
>> Some other devices have been mentioned to him already.  Joerg is an
>>
>> engineer with a lot of "preference".  He won't use MCU parts from a
>>
>> company he feels doesn't give good support so many of them are not in
>>
>> the running.  I know he has mentioned STM as a no-go.   I don't know
>>
>> about NXP.  I do know that NXP ARMs have a huge and very active
>>
>> community which can give good support.
>
> This quite common behaviour, at least among hardware engineers :)
>
>>
>>
>>
>> I find it interesting that he wants to use a CODEC with an I2S port
>>
>> which requires 8 channels (not always supported even if there is an I2S
>>
>> port), but hasn't considered that in his selection criteria until now.
>>
> He may be out of luck in this case, unless he finds something that will support TDM over the I2S port. AFAIK, there aren't microcontrollers with that kind of I2S ports, in fact I'm not aware of any such I2S controller.

There must be some or ADI wouldn't make a part with this sort of 
interface.  I did suggest that he might find SPI to be more amenable to 
a multi-ADC chip but someone else kept saying SPI was absurd to use for 
this and Joerg said something about the data line "glowing" from the 
large number of bits SPI would require.  I have no idea what he is 
thinking as the number of bits is the same SPI or I2S... no, that's not 
right.  He might be able to use fewer bits with SPI depending on the 
part selected.  What I found on I2S was that the channels had to be 
multiples of 2 while he only needs five ADC.

Whatever.  We all make wrong turns from time to time.  I'm sure he will 
get this figured out and start moving ahead.

-- 

Rick

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

#33949

rickman wrote:
> On 10/15/2014 11:42 PM, Raimond Dragomir wrote:
>>>>                                    ... 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.
>>>
>> Probably I'm plain wrong because I don't know anything about your
>> application, but there are plenty ARM Corthex-M chips with I2S ports.
>> For example, my LPC4088 has I2S with internal FIFO, separate PLL, etc.
>> I can generate 48kHz 16bit audio stereo only with interrupts, no even
>> need for DMA. My system runs at 120MHz.
> 

Thanks. It doesn't mention TDM but could be a candidate if the
arbitration in the I2S section is efficient.

http://www.nxp.com/documents/data_sheet/LPC408X_7X.pdf


> You only replied in the c.l.f group so he won't likely see your
> response.  I'm sure he is reading this in the s.e.d group.
> 
> Some other devices have been mentioned to him already.  Joerg is an
> engineer with a lot of "preference".  He won't use MCU parts from a
> company he feels doesn't give good support so many of them are not in
> the running.  I know he has mentioned STM as a no-go.   I don't know
> about NXP.  I do know that NXP ARMs have a huge and very active
> community which can give good support.
> 

A community is great and very useful. However for a product in a
regulated market (on this one the FDA will have a say) sometimes it is
necessary to obtain a written statement from the manufacturer. End of
last year I had a case where NXP omitted something in the datasheet. It
took major rattling of the cage to obtain an answer. That left a sour
aftertaste.


> I find it interesting that he wants to use a CODEC with an I2S port
> which requires 8 channels (not always supported even if there is an I2S
> port), but hasn't considered that in his selection criteria until now.
> 

Well, I didn't start the search before yesterday and assumed that modern
ARM processors would have no problem with that. Now I know that some do.

-- 
Regards, Joerg

http://www.analogconsultants.com/

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

#33948

On 10/15/14 1:12 PM, Joerg wrote:
> rickman 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?".

That sounds more like a need for a local technician than a programmer!

Virtually none of FORTH, Inc.'s customers for whom we do application 
work are local to us; our most recent major projects were in Vancouver 
BC and Texas. The model we use is to go on site for one or more visits 
(typically a couple of weeks) to get the system part (drivers, 
application design, main body of code) working and the customer's local 
programmer(s) trained. If there is custom hardware and it's portable, we 
ask for one unit to take home. Thereafter, we consult remotely on both 
hardware and software issues. This takes advantage of the fact that the 
customer has far more detailed understanding of the application domain 
than we do, but we have the experience to help get the system design off 
on the right track and provide continuing support (including more visits 
if necessary).

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#33951

On 10/16/2014 2:32 PM, Elizabeth D. Rather wrote:
> On 10/15/14 1:12 PM, Joerg wrote:
>> rickman 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?".
>
> That sounds more like a need for a local technician than a programmer!
>
> Virtually none of FORTH, Inc.'s customers for whom we do application
> work are local to us; our most recent major projects were in Vancouver
> BC and Texas. The model we use is to go on site for one or more visits
> (typically a couple of weeks) to get the system part (drivers,
> application design, main body of code) working and the customer's local
> programmer(s) trained. If there is custom hardware and it's portable, we
> ask for one unit to take home. Thereafter, we consult remotely on both
> hardware and software issues. This takes advantage of the fact that the
> customer has far more detailed understanding of the application domain
> than we do, but we have the experience to help get the system design off
> on the right track and provide continuing support (including more visits
> if necessary).

Joerg is describing what might happen that means he needs to have the 
consultant minutes away.  The consultant won't be fixing the gasket, 
Joerg will.  I didn't realize Joerg has a small lab without room for two 
people to work separately.

-- 

Rick

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

#33956

Elizabeth D. Rather wrote:
> On 10/15/14 1:12 PM, Joerg wrote:
>> rickman 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?".
> 
> That sounds more like a need for a local technician than a programmer!
> 

This is a one-of-a-kind tester that I designed and built myself, with
the help of an aerospace engineer. Only one such tester exists in the
world and I am currently the only person who can fix it if something
breaks. The tester is only useful for this particular project. Both the
programmer and I must use it a lot towards the later phases of the projects.


> Virtually none of FORTH, Inc.'s customers for whom we do application
> work are local to us; our most recent major projects were in Vancouver
> BC and Texas. The model we use is to go on site for one or more visits
> (typically a couple of weeks) to get the system part (drivers,
> application design, main body of code) working and the customer's local
> programmer(s) trained. If there is custom hardware and it's portable, we
> ask for one unit to take home. Thereafter, we consult remotely on both
> hardware and software issues. This takes advantage of the fact that the
> customer has far more detailed understanding of the application domain
> than we do, but we have the experience to help get the system design off
> on the right track and provide continuing support (including more visits
> if necessary).


That is how I also normally work, most times I actually never see my
clients face to face except in online meetings. But this project is
different. The software cannot be optimized without working right at the
test apparatus. Since it involves a compressor, pressurized buffer
tanks, valves and such it is also something where I must be present for
safety reasons. I would never let anyone using it by themselves.

-- 
Regards, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web