Hi,
Maybe you Need a short delay after Setting the pin high (portc.2 = 1 ) before reading the pin, and in your case the print Statement delays the code Long enough.
Try replacing the print statement with a waitms 1
Regards
Ian Dobson
↧
BASCOM-AVR : why print is neccessary? : REPLY
↧
BASCOM-AVR Old versions : ATmega328P code looping : REPLY
hi,
[quote:a9ec20d335] I use atmel studio to download the Hex to the MCU [/quote:a9ec20d335]
Bascom with the use of the Arduino UNO and M2560 modules is very simple, using the arduino bootloader.
Try it is to adopt it!
See how to configure Bascom in the Bascom-Arduino forum to do this.
[url]http://www.mcselec.com/index2.php?option=com_forum&Itemid=59&page=viewtopic&t=12472[/url]
JP
↧
↧
Share your working BASCOM-AVR code here : A wav player using kokkekat fat and a atmega8 and pwm : REPLY
EDC,
Do you hear the "click" sound after each file if you replay them in Audacity or any other player? Is the click caused by the Bascom code perhaps?
Cheers,
Ross
↧
BASCOM-AVR : why print is neccessary? : REPLY
[quote:b1c8369a8a]Are there other statements executed between If-Endif?
Is Debug on or off? [/quote:b1c8369a8a]
The whole code between If and And-If is not executed. It's the same, if I turn off Debug or not. Nessesary is that ther is an output on the serial port.
[quote:b1c8369a8a]Try replacing the print statement with a waitms 1 [/quote:b1c8369a8a]
That's a good idea. I try it this evening.
↧
BASCOM-AVR : why print is neccessary? : REPLY
you can best post a more complete piece of your code that will demonstrate the problem.
i can not imagine print has anything to do with it since tx/rx is at different pins. or it must make a short circuit on your board.
↧
↧
BASCOM-AVR : EEPROM being erased when programming : REPLY
Thanks for the suggestions.
I changed Fusebit "H" to [0: Preserve EEPOM trough Chip Erase] . That was excatly what I needed.
Thanks again,
gertc
↧
BASCOM-AVR : Xmega: What are Config DMA and Config ADC are doing? : NEWTOPIC
In my project (Xmega)
[url]http://www.mcselec.com/index2.php?option=com_forum&Itemid=59&page=viewtopic&t=12965[/url]
I am doing DMA transfers from the freerunning ADC repeatedly.
However, to keep this running - and not just once as in the Mak3's examples - I have to reconfigure the DMA and the ADC each time after the Do.... within the Loop.
[code:1:7bf0548d05] Do
Config Dmach0 = Enabled , Burstlen = 2 , Chanrpt = Disabled , Tci = Lo , Eil = Lo , Singleshot = Disabled , _
Sar = Burst , Sam = Inc , Dar = None , Dam = Inc , Trigger = &H10 , Btc = 4000 , Repeat = 1 , Sadr = Varptr(adca_ch0_res) , Dadr = Varptr(samples(1))
Config Adca = Free , Convmode = Signed , Resolution = 12bit , Dma = Ch01 , _
Reference = Int1v , Prescaler = 8 , Sweep = Ch0 , Event_mode = None , Event_channel = Ch0123 , _
Ch0_gain = 1 , Ch0_inp = Single_ended , Mux0 = &B00000000
....
Loop[/code:1:7bf0548d05]
I assume using register settings would be slightly faster than using Configs repeatedly.
I tried to find out with help of ICE which registers are being set, but I must have missed some settings.
Could somebody (Mark? :D) tell which registers are being set by those Configs?
I am asking this here rather mailing to support since it might be of more general interest.
Regards, Meister
[b:7bf0548d05][color=red:7bf0548d05](BASCOM-AVR version : 2079 , Latest : 2.0.7.8 )[/b:7bf0548d05][/color:7bf0548d05]
↧
BASCOM-ARDUINO : AVR Bascom v/s Arduino Programming Software : REPLY
The Arduino platform appears to rely on set hardware whereas Bascom being just a programming language for AVR processors allows greater flexibility. For instance when very low power is needed and speed is not an important consideration a low frequency clock such as a watch xtal at 32kHz can be used. This allows a much reduced micro power to be obtained. Other components can also be selected for low current consumption. I know a sleep cycle can be used to reduce power but some applications don't allow this.
Whether you use Bascom or Arduino depends greatly on the project requirements and both have their place.
↧
BASCOM-AVR : Xmega: What are Config DMA and Config ADC are doing? : REPLY
[quote:06c0db9761="Meister"]I tried to find out with help of ICE which registers are being set, but I must have missed some settings.[/quote:06c0db9761]
Why do you use JTagICE, even AVR-Studio 4 can do it via software, load the Bascom obj-file, open up a disassembler window on the config-line and look up the register values which are stored via STS, sure you have to translate the absolute addresses into the appropriate register names, but even there AVR-Studio will help you.
[quote:06c0db9761]I am asking this here rather mailing to support since it might be of more general interest.[/quote:06c0db9761]
I thought support is for bugs and updates and not for sparing users to read the data sheet.
[quote:06c0db9761]I assume using register settings would be slightly faster than using Configs repeatedly.[/quote:06c0db9761]
The config is a few LDI/OR/AND/STS opcodes and I doubt if will be faster, if you do the same.
However, there's no need to configure everything from new, the DMA does not clear all of it's configuration data.
I noticed from the linked thread, that you've complained about the array not being written at following runs, you seem not to have fixed that issue, as you still have Dar = None in your code, which, for a proper reload of the destination address has to be BLOCK or TRANSACTION, either of them works, as long block repeat is 1.
The reason, why your manual configuration does not work, is because you forget to set TRFCNT and REPCNT, which are decremented by the DMA-controller.
If setting these registers is done, together with Dar = BLOCK, then it should suffice to enable the DMA-transfer by setting CtrlA.CHEN, it is started then by the still active ADC trigger source.
↧
↧
BASCOM-AVR : Xmega: What are Config DMA and Config ADC are doing? : REPLY
Hi MWS,
thanks for your comments.
[quote:bd3406e30f]The config is a few LDI/OR/AND/STS opcodes and I doubt if will be faster, if you do the same. [/quote:bd3406e30f]
So for the time being I will keep it like that for the sake of having less trouble...
Meanwhile I am having a nice triggered oscilloscope on the Xplained LCD.
Considering the linked code:
[quote:bd3406e30f]you've complained about the array not being written at following runs, you seem not to have fixed that issue,[/quote:bd3406e30f]
No, that was fixed by using the reoccuring Config statements. The code works flawlessly repeatedly. That was the reason why I had posted it, after long time of experimenting.
What is a little bit unexpected: I don't need to wait for Bitwait Dma_ch0_ctrlb.4 , Set
Maybe the DMA transfer is that fast that the following Max(...) in the linked code never encounters an incompletly filled array.
↧
BASCOM-AVR : Xmega: What are Config DMA and Config ADC are doing? : REPLY
[quote:added79791="Meister"]So for the time being I will keep it like that for the sake of having less trouble...[/quote:added79791]
Hmm, if you don't want to learn, I wonder why you ask then and create a topic?
[quote:added79791]No, that was fixed by using the reoccuring Config statements. The code works flawlessly repeatedly.[/quote:added79791]
Again, if you're happy with what you got by trial and error, I miss the knack why you ask here, or why I (or anyone else) should take the efforts to think about your problems.
[quote:added79791]What is a little bit unexpected: I don't need to wait for Bitwait Dma_ch0_ctrlb.4 , Set
Maybe the DMA transfer is that fast that the following Max(...) in the linked code never encounters an incompletly filled array.[/quote:added79791]
DMA needs to wait for the ADC, so it won't fill up faster than the ADC can sample.
Your code is flawed, the first time it may work ok, the following samples are random, as you never clear this TRNIF-flag, so [b:added79791]Bitwait Dma_ch0_ctrlb.4 , Set[/b:added79791] subsequently don't work, as it's always true.
You may get results, but you don't get results the way you think :D
And yes, you would be far better off, if you'd read the XMega's data sheet and appnotes, instead of wasting time by this kind of random programming.
↧
BASCOM-AVR : Xmega: What are Config DMA and Config ADC are doing? : REPLY
Hi,
[quote:9fa820e7bf]the first time it may work ok, the following samples are random[/quote:9fa820e7bf]
Not true. If I change the incoming waveform when the program is running, the output on the GLCD "instantly" reflects the input after having summed up 256 DMA transfers.
If just the first one were right, its signature should vanish in the result.
There are two Transaction Complete Interrupt Flags, one for the DMA, one for the channel, but I can't see which one would be relevant (anyway it looks like none is needed to be interrogated).
Bitwaiting for either of these after the Config statements like this (there is nothing more dealing with the DMA or ADC settings between Do and Loop)
[code:1:9fa820e7bf]Do
Config Dmach0 = Enabled , Burstlen = 2 , Chanrpt = Disabled , Tci = Lo , Eil = Lo , Singleshot = Disabled , _
Sar = Burst , Sam = Inc , Dar = None , Dam = Inc , Trigger = &H10 , Btc = 4000 , Repeat = 1 , Sadr = Varptr(adca_ch0_res) , Dadr = Varptr(samples(1))
Config Adca = Free , Convmode = Signed , Resolution = 12bit , Dma = Ch01 , _
Reference = Int1v , Prescaler = 8 , Sweep = Ch0 , Event_mode = None , Event_channel = Ch0123 , _
Ch0_gain = 1 , Ch0_inp = Single_ended , Mux0 = &B00000000
Bitwait Dma_ch0_ctrlb.4 , Set ' alternatively Bitwait Dma_intflags.0 , Set
Set Dma_ch0_ctrlb.4 ' Set Dma_intflags.0
...
Loop [/code:1:9fa820e7bf]
does not have any visible effect on the sampled waveform.
Since the samples are well defined rather than random, is there some explanation?
↧
BASCOM-AVR : Xmega: What are Config DMA and Config ADC are doing? : REPLY
[quote:35f5097832="Meister"]Since the samples are well defined rather than random, is there some explanation?[/quote:35f5097832]
I wrote:
[quote:35f5097832]You may get results, but you don't get results the way you think[/quote:35f5097832]
"Randomly" describes that you actually get data, but not the one you expect.
Assume 4 clocks per conversion, prescaler 8 and 4000 samples = 128000 clocks. That's nothing for an uC running 32Mcycles, but far too much for the max, as your code runs straight over the bitwait.
This way the max-function has no chance to get valid data from the current sample run. But - you waste some more time, print, waitms, a.s.o. That's time for the DMA to fill up the sample-array, means the next call for max will work on previously fetched data. This way it collects data, only not the way and in the exact period the guy in front of the machine has intended it :D
↧
↧
BASCOM-AVR : Xmega: What are Config DMA and Config ADC are doing? : REPLY
Maybe the Bitwait misses the Transaction complete flag.
Maybe that was the reason for Mak3 in his DMA examples to introduce a variable [i:558f58242d]Dma_ready[/i:558f58242d] that was set by interrupt and interrogated in Do ... Loop until Dma_ready=1.
I was not able to get this running repeatedly, despite spending a lot of time, so I came up with that what you are criticising.
(This applies to all Mak3's DMA examples -including DMA-UART (it prints just once) which otherwise are nice).
I think a better way compared to using the interrupt would be to have kind of [i:558f58242d]StART DMA[/i:558f58242d] modified that it starts the DMA transfer and waits for the transaction to be complete.
Would you mind to help with this?
↧
BASCOM-AVR : why print is neccessary? : REPLY
The Idea of Ian Dobson was the right one. The Pin needs a little bit of time to pullup.
Thanks!
↧
BASCOM-AVR : Xmega: What are Config DMA and Config ADC are doing? : REPLY
[quote:05bce0c0f2="Meister"]Maybe the Bitwait misses the Transaction complete flag. [/quote:05bce0c0f2]
I do not think it gets missed, but as you have a repeating signal, you won't notice the difference about the previous or the actual sample of the signal.
And that's all the difference bitwait makes.
And btw., if you wait in a loop for completing the DMA, you miss the benefit of DMA.
DMA is useful to do things in the background, without wasting otherwise valuable processor time, if you do a bitwait this is your clock-wasting loop.
If you do sampling and filling the ADC instead of DMA with a loop, and assumed each loop-run does not take more time than the period between ADC-samples, you have the same result in regards of efficiency.
What I was pointing out is, that a) your code works, only not as intended, and b) you have to make sure, that your data is consistent.
I do not believe you want to have data, that is mixed up out of two not connected periods, and use the max-function thereon.
Assumed you don't use bitwait, here how's your code working:
- ADC is constantly sampling, each sample takes in your case 40 processor cycles, 5 (not the 4 previously assumed) for 8bit and prescaler 8.
- DMA is started
- Depending on the progress of the ADC the trigger occurs in 0 to 40 cycles
- assuming the ADC triggers DMA instantly, the first result is pushed within a few cycles into the sample array
- max-function is started, it takes a few cycles to prepare and then, let's say 10 cycles for each iteration through the array
- if preparation for max takes more than 40 cycles, the second cell of the sample array is filled
- max iteration happens and now max runs ahead of the sampling, as it is iterating faster than the DMA can fill up the array
- max does this way calculation based to a tiny amount on actual and in a bigger amount on previous data
If max would take more than 40 cycles for each iteration, then the ADC would run ahead.
I can not imagine, that you want to build code and don't know what you're actually calculating.
[quote:05bce0c0f2]Maybe that was the reason for Mak3 in his DMA examples to introduce a variable [i:05bce0c0f2]Dma_ready[/i:05bce0c0f2] that was set by interrupt and interrogated in Do ... Loop until Dma_ready=1.[/quote:05bce0c0f2]
Set a link to his code.
[quote:05bce0c0f2]I was not able to get this running repeatedly, despite spending a lot of time, so I came up with that what you are criticising.[/quote:05bce0c0f2]
As said I've pointed out what you think in contrary to what the code actually does.
[quote:05bce0c0f2]I think a better way compared to using the interrupt would be to have kind of [i:05bce0c0f2]StART DMA[/i:05bce0c0f2] modified that it starts the DMA transfer and waits for the transaction to be complete.[/quote:05bce0c0f2]
I would start the transfer, while the processor does useful other things, like pushing out data to a display.
If a delay between calculation and sampling is acceptable, I'd do it this way:
- loop start
- max calculation
- start DMA
- print ... or/and wait some
- loop end
The first max is void this way, the subsequent max's are always calculations of previous data, but as long as print and wait uses up more than 160000 cycles, there won't be inconsistent data.
Otherwise one could think on sampling continuously and copy chunks, or all of the data to work with into a second buffer. Needs an ISR to reload TRFCNT and extra SRam.
↧
BASCOM-AVR : Xmega: What are Config DMA and Config ADC are doing? : REPLY
[quote:6ebe603e4f]Set a link to his code. [/quote:6ebe603e4f]
[url]http://bascom-forum.de/showthread.php?2198-ATXMEGA-kleines-einmaleins-Erste-Schritte-mit-ATxmega/page14&highlight=a3bu[/url]
At present I need a 600us Wait between the trigger pulse and the start od the DMA to catch the right part of the signal. Of course, this slows down the whole thing (256x0.6ms=0.15s, the whole repetition rate is ~<1s). I tried as you suggested to reorder the code, but even when putting all the GLCD stuff on top I need this delay (even somewhat more). I am now preparing to replace that by a hardware delay using an Tiny85 between the trigger signal and the Xmega, so I hope to get rid of the 600us Wait, but I am not sure if there won't be a surprise... I think the Cmemwcpy code was provided by some MWS....
[quote:6ebe603e4f]or all of the data to work with into a second buffer.[/quote:6ebe603e4f]
Yes, I was considering this. If the Config DMA would have an option on that, I would have tried it already. So one has to work with the registers.
This is how it looks so far:
[code:1:6ebe603e4f]Do
Cmemwcpy Samples(1) , Summ(1) , Sample_count
Bitwait Pinb.0 , Set 'Wait for Triggerpulse
Toggle Portr.0
Waitus 600 'Sampling Delay
Config Dmach0 = Enabled , Burstlen = 2 , Chanrpt = Disabled , Tci = Lo , Eil = Lo , Singleshot = Disabled , _
Sar = Burst , Sam = Inc , Dar = None , Dam = Inc , Trigger = &H10 , Btc = 4000 , Repeat = 1 , Sadr = Varptr(adca_ch0_res) , Dadr = Varptr(samples(1))
Config Adca = Free , Convmode = Signed , Resolution = 12bit , Dma = Ch01 , _
Reference = Int1v , Prescaler = 8 , Sweep = Ch0 , Event_mode = None , Event_channel = Ch0123 , _
Ch0_gain = 1 , Ch0_inp = Single_ended , Mux0 = &B00000000
'Bitwait Dma_ch0_ctrlb.4 , Set 'No change when enabling
'Set Dma_ch0_ctrlb.4
'Bitwait Dma_intflags.0 , Set '
Stp = 1
K = K + 1
L = K Mod 256
If L = 0 Then
Idxmin = 1990 : Idxmax = Idxmin
Minn = Get_min_sint_16(summ(2) , Idxmin )
Maxx = Get_max_sint_16(summ(2) , Idxmax )
Idxmin1 = Idxmin + 2 : Idxmax1 = Idxmax + 2
For I = 16 To 2000 Step 16 'Compress data
Idx = I
Shift Idx , Right , 4
Temp = 0
Temp = Sum(summ(i) , 16)
Shift Temp , Right , 4 , Signed
Summ(idx) = Temp
Next
Idxmin = 124 : Idxmax = Idxmin
Minn = Get_min_sint_16(summ(2) , Idxmin )
Maxx = Get_max_sint_16(summ(2) , Idxmax )
Idxmin = Idxmin + 2 : Idxmax = Idxmax + 2
Print #1 , Idxmin ; "Minn=" ; Minn ; " ;" ; Idxmax ; " " ; Maxx
C3 = Maxx - Minn 'Normalizing for GLCD
C1 = C11 / C3
C2 = Servomin * Maxx
C21 = Servomax * Minn
C2 = C2 - C21
C2 = C2 / C3
Call Lcd_clear(white)
For I = 10 To 125
Temp4 = Summ(i)
Temp4 = Temp4 * C1
Y = Temp4 + C2
I2 = I
Call Lcd_set_pixel(i2 , Y , Black)
Next
I2 = Memcopy(null , Summ(1) , 4000 , 2) 'Clear array to avoid to be fooled if the array were not updated.
Text11 = Str(maxx)
Text11 = Format(text11 , "0000")
Call Lcd_text(text11 , 0 , 1 , 1) 'Draw Text to Buffer
Text11 = Str(minn)
Text11 = Format(text11 , "0000")
Call Lcd_text(text11 , 0 , 25 , 1) 'Draw Text to Buffer
Text11 = Str(idxmin1)
Text11 = Format(text11 , "0000")
Call Lcd_text(text11 , 90 , 25 , 1) 'Draw Text to Buffer
Text11 = Str(idxmax1)
Text11 = Format(text11 , "0000")
Call Lcd_text(text11 , 90 , 1 , 1) 'Draw Text to Buffer
Call Lcd_show()
End If
Loop[/code:1:6ebe603e4f]
↧
↧
BASCOM-AVR : Xmega: What are Config DMA and Config ADC are doing? : REPLY
[quote:8ae1c25e04="Meister"](256x0.6ms=0.15s, the whole repetition rate is ~<1s)[/quote:8ae1c25e04]
Where does the 256 come from? Calculation and display is done for only one of it, the other 255 samples are processed in different code then?
I would feel it helpful, if the purpose is described, together with signal form and timing.
Thought about steadily sampling and picking out the right data, but it depends on given requirements.
An external interrupt and timer can be used for the 600µs delay, start and end of sample, as then end of the block does not equal the sample end.
But you mentioned somewhere not to use interrupts. This approach, which would be non-blocking, needs to make use of them.
You can try out, this config should continuously sample into the array:
[code:1:8ae1c25e04]Config Dmach0 = Enabled , Burstlen = 2 , Chanrpt = Enabled , Tci = Off , Eil = Off , Singleshot = Enabled , _
Sar = Burst , Sam = Inc , Dar = BLOCK , Dam = Inc , Trigger = &H10 , Btc = 4000 , Repeat = 0 , Sadr = Varptr(adca_ch0_res) , Dadr = Varptr(samples(1))[/code:1:8ae1c25e04]
↧
BASCOM-AVR : FM PLL Transmitter 88Mhz - 108Mhz, Using TSA5511 & Atmeg : NEWTOPIC
Hi Anyone,
I am a newbie in this forum, I am looking for the schematic of FM PLL Transmitter 88Mhz-108Mhz using TSA5511 and Atmega16 .
Thanks for any help.
Regards,
Eban.
[b][color=red](BASCOM-AVR version : 2.0.7.5. , Latest : 2.0.7.8 )[/b][/color]
↧
BASCOM-AVR : Xmega: What are Config DMA and Config ADC are doing? : REPLY
Hello MWS,
I was experimenting a lot with that code but everything else came out worse than that what I had posted.
Of course, it is less than satisfying not knowing exactly what is going on (the timings) but as long as it shows the expected results it might be ok.
To analyse the timings would be tedious.
I remember that a wise person time ago told me "If there is an uncured problem it will hit you at some occasion". Let's wait for that...
Why I did it? I was motivated by the recent DIY-Osci thread in the Bascom forum. It is easy to record nice signals, but to discover very noisy signals there are not so many solutions (except in some TEK oscilloscopes as far as I know). Of course, the signals have to be periodic like an echo on recurring event (light or sound pulse).
Meanwhile I got the Attiny85 delay-generator working - easy with Bascom - and I nicely can shift the accumulated signal on the time scale - back and forth.
As always, thanks for your help.
Regards, Meister
↧