I am using MPC 7555 controller. It has a 16 bit sigma delta ADC.
A signal called mic input is fed to this ADC pin. based upon the voltage , a PWM signal of same frequency of ADC signal sampling should be generated.
For e.g.
0.1 V = 2 percent
0.2 V = 4 percent
0.3 V = 6 percent....and so on
So, i thought the following logic -
5V - 0xFFFF in digital
0.1V - 1310
0.2V - 2620 and so on
So, dividing the digital value by 655 will give exact duty cycle value
1310/655 = 2
2620/655 = 4........
But digital pin could also show value of 1309 for 0.1 V which when divided by 655 would yield 1 and not 2.
Anyway i can avoid this or does any have a better solution, please share.
The task is to output PWM at the same rate as the ADC conversion rate.
Suppose the ADC conversion time is T (you can establish this by reading a free-run timer counter). And suppose the ADC conversion value is V. Then the PWM output time H spent "high" must be
H = T * V / 0xFFFF
Every time an ADC conversion is available, you (cancel any pending one-shot timer interrupt and) set the PWM output to 1 and trigger a one-shot timer at time H. When it interrupts, you set the PWM output to 0 (or the other way round if you have inverse logic).
If the input is 0x0000 or 0xFFFF you can employ an alternative strategy - set the output to 0 or 1, but don't deploy the one-shot timer.
To get the best fidelity in teh PWM signal, you would do better to work directly at the resolution of the PWM rather then calculate a percentage only to then convert that to a PWM count. Using integer percentage, you are effectively limiting your resolution to 6.64 bits per sample (i.e. log10(100)/log10(2)).
So let's say your PWM count per cycle is PWM_MAX, and your ADC maximum ADC_MAX, then the PWM high period would be:
pwm_high = adc_val * PWM_MAX / ADC_MAX ;
It is important to perform the multiplication first to avoid loss of information. If PWM_MAX is suficiently high, there is probably no need to worry about integer division rounding toward zero rather then to teh nearest integer, but if that is a concern (for low PWM_MAX ) then:
pwm_high = ((adc_val * PWM_MAX) + (ADC_MAX / 2)) / ADC_MAX ;
For example, soy your PWM_MAX is only 100 (i.e. the resolution truely is in integer percent), then in the first case:
pwm_high = 1310 * 100 / 0xFFFF = 1
and in the second:
pwm_high = ((1310 * 100) + 0x7FFF) / 0xFFFF = 2
However if PWM_MAX is a more suitable 4096 perhaps, then:
pwm_high = 1310 * 4096 / 0xFFFF = 81
or
pwm_high = ((1310 * 4096) + 0x7fff) / 0xFFFF = 82
With PWM_MAX at 4096 you have effectively 12 bits of resolution and will maintain much higher fidelity as well as directly calculating the correct PWM value.
I installed portaudio on Ubuntu 14.04 and compiled a test program as follows:
gcc -o Test3c Test3c.c ../libportaudio.a -lrt -lasound -ljack -lpthread -lm
which had no errors. (Test3c.c is the same as the included pa_devs.c, which can be found here.) But when I run it,
./Test3c
I get this:
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
bt_audio_service_open: connect() failed: Connection refused (111)
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
PortAudio version number = 1899
PortAudio version text = 'PortAudio V19-devel (built Feb 14 2015 11:51:22)'
Number of devices = 20
--------------------------------------- device #0
Name = HDA Intel PCH: ALC892 Analog (hw:0,0)
Host API = ALSA
Max inputs = 2, Max outputs = 6
Default low input latency = 0.0058
Default low output latency = 0.0087
Default high input latency = 0.0348
Default high output latency = 0.0348
Default sample rate = 44100.00
Supported standard sample rates
for half-duplex 16 bit 2 channel input =
44100.00, 48000.00, 96000.00, 192000.00
Supported standard sample rates
for half-duplex 16 bit 6 channel output =
None
Supported standard sample rates
for full-duplex 16 bit 2 channel input, 6 channel output =
None
--------------------------------------- device #1
Name = HDA Intel PCH: ALC892 Digital (hw:0,1)
Host API = ALSA
Max inputs = 0, Max outputs = 2
Default low input latency = -1.0000
Default low output latency = 0.0058
Default high input latency = -1.0000
Default high output latency = 0.0348
Default sample rate = 44100.00
Supported standard sample rates
for half-duplex 16 bit 2 channel output =
32000.00, 44100.00, 48000.00, 88200.00,
96000.00, 192000.00
--------------------------------------- device #2
Name = HDA Intel PCH: ALC892 Alt Analog (hw:0,2)
Host API = ALSA
Max inputs = 2, Max outputs = 0
Default low input latency = 0.0058
Default low output latency = -1.0000
Default high input latency = 0.0348
Default high output latency = -1.0000
Default sample rate = 44100.00
Supported standard sample rates
for half-duplex 16 bit 2 channel input =
44100.00, 48000.00, 96000.00, 192000.00
--------------------------------------- device #3
Name = HDA NVidia: HDMI 0 (hw:1,3)
Host API = ALSA
Max inputs = 0, Max outputs = 8
Default low input latency = -1.0000
Default low output latency = 0.0058
Default high input latency = -1.0000
Default high output latency = 0.0348
Default sample rate = 44100.00
Supported standard sample rates
for half-duplex 16 bit 8 channel output =
32000.00, 44100.00, 48000.00, 88200.00,
96000.00, 192000.00
--------------------------------------- device #4
Name = HDA NVidia: HDMI 0 (hw:1,7)
Host API = ALSA
Max inputs = 0, Max outputs = 8
Default low input latency = -1.0000
Default low output latency = 0.0058
Default high input latency = -1.0000
Default high output latency = 0.0348
Default sample rate = 44100.00
Supported standard sample rates
for half-duplex 16 bit 8 channel output =
32000.00, 44100.00, 48000.00, 88200.00,
96000.00, 192000.00
--------------------------------------- device #5
Name = HDA NVidia: HDMI 0 (hw:1,8)
Host API = ALSA
Max inputs = 0, Max outputs = 8
Default low input latency = -1.0000
Default low output latency = 0.0058
Default high input latency = -1.0000
Default high output latency = 0.0348
Default sample rate = 44100.00
Supported standard sample rates
for half-duplex 16 bit 8 channel output =
32000.00, 44100.00, 48000.00, 88200.00,
96000.00, 192000.00
--------------------------------------- device #6
Name = HDA NVidia: HDMI 0 (hw:1,9)
Host API = ALSA
Max inputs = 0, Max outputs = 8
Default low input latency = -1.0000
Default low output latency = 0.0058
Default high input latency = -1.0000
Default high output latency = 0.0348
Default sample rate = 44100.00
Supported standard sample rates
for half-duplex 16 bit 8 channel output =
32000.00, 44100.00, 48000.00, 88200.00,
96000.00, 192000.00
--------------------------------------- device #7
Name = sysdefault
Host API = ALSA
Max inputs = 128, Max outputs = 128
Default low input latency = 0.0213
Default low output latency = 0.0213
Default high input latency = 0.0213
Default high output latency = 0.0213
Default sample rate = 48000.00
Supported standard sample rates
for half-duplex 16 bit 128 channel input =
8000.00, 9600.00, 11025.00, 16000.00,
22050.00, 32000.00, 44100.00, 48000.00,
88200.00
Supported standard sample rates
for half-duplex 16 bit 128 channel output =
8000.00, 9600.00, 11025.00, 16000.00,
22050.00, 32000.00, 44100.00, 48000.00,
88200.00
Supported standard sample rates
for full-duplex 16 bit 128 channel input, 128 channel output =
8000.00, 9600.00, 11025.00, 16000.00,
22050.00, 32000.00, 44100.00, 48000.00,
88200.00
--------------------------------------- device #8
Name = front
Host API = ALSA
Max inputs = 0, Max outputs = 6
Default low input latency = -1.0000
Default low output latency = 0.0058
Default high input latency = -1.0000
Default high output latency = 0.0348
Default sample rate = 44100.00
Supported standard sample rates
for half-duplex 16 bit 6 channel output =
Test3c: pcm_params.c:2249: snd1_pcm_hw_params_slave: Assertion `err >= 0' failed.
Aborted (core dumped)
It crashes midway through listing the devices, when Pa_IsFormatSupported() is called. Google tells me that "pcm_params.c" refers to the ALSA library. Has anyone found a solution to this type of problem?
So I think I've found a solution. After the most recent error, I noticed the recommendation for a different audio issue here to restart the audio drivers in the following way:
pulseaudio -k && sudo alsa force-reload
I did it, and then tried running the compiled program, and got errors again (I think I was being impatient). I then did this command a second time, and now it works.
update: After a while, I do get the error again, and have to restart the drivers again.
Currently I am the maintainer of the Portaudio-linux host, and have just come across this question here. The same issue has been reported on the Portaudio mailing list, and investigated. The assert is in Alsa-lib, and has now been removed by the Alsa-developers in favour of an error return. See
http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=67f73b0fab466e780dcc0442e19894a1cbedc43b
Certain devices seem to cause a problem with 6-channels on 'front' (and some other) PCMs. This is not a fault of Portaudio, but as it probes the capabilities of the devices and PCMs it exposes issues within the Alsa system. With the assert removed, it now just fails these capabilities.
I encountered the same problem and resolved it by fixing some faulty pcm definitions in /usr/share/alsa/pcm. In the route section towards the bottom of the file the card driver was referencing a different pcm then the one defined in the file.
I'm working with the TDA19988 HDMI framer and having troubles understanding how to translate the EDID info to configure the framer output.
For example, from the EDID I can see the following parsed info:
1280x720 0x41 74.2MHZ
H : 1280 start 1390 end 1430 total 1650 clock 45.0KHZ
V : 720 start 725 end 730 total 750 clock 60.0HZ
Now, the HDMI framer allows the following to be configured:
refpix (preset pixel) = ?
refline (preset line) = ?
npix (number of input pixels) = ?
nline (number of input lines) = ?
vs_line_start_1 (vertical synchronization line start) = ?
vs_pix_start_1 (vertical synchronization pixel start) = ?
vs_line_end_1 (vertical synchronization line end) = ?
vs_pix_end_1 (vertical synchronization pixel end) = ?
hs_pix_start (horizontal synchronization pixel number) = ?
vwin_start_1 (vertical window start) = ?
vwin_end_1 (vertical window end) = ?
de_start (data enable start) = ?
de_end (data enable end) = ?
I haven't been able to understand how the EDID info is translated to configure the HDMI framer output. Can someone give me some help?
Thanks in advance!
I don't know too much about EDID, but since there is no answer yet, I'll explain what I know.
The TV signal comes one pixel at a time from left to right and from top to bottom. The pixel frequency is 74.2MHZ, that is there are 74.2 million pixels in a second.
Each line is composed of 1650 pixels, that makes 74.2M / 1650 = 45K lines in a second. That's the 45.0KHz.
Then, each frame is made of 750 lines. That is 45K / 750 = 60 frames per second. That's the 60.0Hz.
From each line of 1650 pixels, only the first 1280 pixels are used for actual pixels in the image. From pixel 1390 to 1430 there is the horizontal synchronizaton signal. From 1280 to 1390 and from 1430 to 1650 there are unused pixels (HBlank).
And from each frame of 750 lines, only the first 720 are used for actual pixels. From 725 to 730 there is the vertical synchronization signal. Ranges 720-725 and 730-750 are also unused (VBlank).
About your parameters, the *start* and *end* parameters should be quite obvious. The other ones... well, I don't know.
From Microchip sample code
PR2 = 2083u; /* Timer2 Period, 19.2 kHz */
How does 2083u correspond to 19.2 kHz, which is
1 / 19.2E03 = 52.083u
They don't correspond at all. Mistake by Microchip?
PR2 = 2083U
makes TIMER2 trigger every 2083 CPU cycles. Calculating
52.083 us / 2083 = 25 ns
1 / 25 ns = 40 MHz
we can conclude that the processor is probably running at FCY = 40 MHz in the example.
The letter u in PR2 = 2038u; does not mean microseconds; it is a C language syntax that makes the integer literal unsigned. See Signedness (Wikipedia).
Setting PR2 to 2083 means that the timer triggers every 2084 (not 2083) clock cycles. When you calculate a timer period, you always have to subtract 1 because the timer value is zero-based.
I am developing a simple parallel application using MPI that involves the loading of a file to memory. That file is exported via NFS to the nodes of the computer cluster. I've noticed that in some cases the performance of NFS drops significantly with thousands of additional TCP packets being trasmitted from the server to the clients and i've pinpointed the problem to the use of fseek() in the code:
//Seek to data and load them to array
fseek ( fp, ( unsigned int ) dec_number + start, SEEK_SET );
for ( i = 0; i < n * mpi_n; i++ ) {
if ( ! feof ( fp ) )
text[i] = fgetc ( fp );
if ( i > 0 && n > mpi_n && i % mpi_n == 0 )
fseek ( fp, n - mpi_n, SEEK_CUR );
}
fclose ( fp );
Since the same code without the fseek() works without problems, is it possible that the server actually resends parts of the file after each fseek() ? How can this performance be improved?
Time with cold NFS cache, without fseek(): ~4 sec
Time with hot NFS cache, without fseek(): ~3 sec
Time with cold NFS cache, with fseek(): ~12 sec
Time with hot NFS cache, with fseek(): ~3 sec
Snapshot of nfswatch with a cluster of 10 nodes, a 300MB file with cold NFS cache and with fseek():
Total packets:
1903459 (network) 544803 (to host) 0 (dropped)
Packet counters:
NFS3 Read: 116290 21%
NFS3 Write: 10 0%
NFS Read: 0 0%
NFS Write: 0 0%
NFS Mount: 0 0%
Port Mapper: 0 0%
RPC Authorization: 29 0%
Other RPC Packets: 0 0%
TCP Packets: 544386 100%
UDP Packets: 17 0%
ICMP Packets: 0 0%
Routing Control: 0 0%
Address Resolution: 0 0%
Reverse Addr Resol: 0 0%
Ethernet Broadcast: 0 0%
Other Packets: 49 0%
Snapshot of nfswatch with a cluster of 10 nodes, a 2GB file with cold NFS cache and without fseek():
Total packets:
251804 (network) 102650 (to host) 0 (dropped)
Packet counters:
NFS3 Read: 37039 36%
NFS3 Write: 1 0%
NFS Read: 0 0%
NFS Write: 0 0%
NFS Mount: 0 0%
Port Mapper: 0 0%
RPC Authorization: 2 0%
Other RPC Packets: 0 0%
TCP Packets: 102543 100%
UDP Packets: 30 0%
ICMP Packets: 1 0%
Routing Control: 0 0%
Address Resolution: 0 0%
Reverse Addr Resol: 0 0%
Ethernet Broadcast: 0 0%
Other Packets: 41 0%
The clients are mounted using the following mount command:
/nfs on /nfs type nfs (rw,rsize=8192,wsize=8192,timeo=14,intr)