Hi,
I think I found some minor issues with the ATMega 1284P and Timer1-Capture-Mode as well as Timer3:
1.) For TIMER3 the variable "TIFR3" (and possible the associated bit-names like "ICF3" etc.) is not defined and thus cannot be set or read with its name.
I had to use the register-adress (0x18/0x38)
2.) When an ICP1-interrupt is generated mannually in the simulator, the content of the TIMER1/COUNTER1 (TCNT1) is [u:7ecfa4ab3e]not [/u:7ecfa4ab3e]copied to the CAPTURE1 register ICR1.
3.) When Bit6 in register TCCR1B (ICES1=Input Capture Edge Select) is toggled, the ICF1 (Input Capture Flag 1) is set in reality, but not in the simulator!
This information is well hidden in the last 2 sentences of section 14.6.3. "Using the Input Capture Unit" in the datasheet of the ATMega1284P.
4.) To [u:7ecfa4ab3e]clear [/u:7ecfa4ab3e]the ICF1-bit in TIFR1, a "[u:7ecfa4ab3e]1[/u:7ecfa4ab3e]" has to be written to the bit. But writing a "1" in the simulator does not clear the ICF1-flag, but sets it!
This behaviour might also be present with some or all of the other Interrupt-Flags.
5.) When using the Variables COUNTER0, COUNTER1, COUNTER2 and COUNTER3 all get different colors in the editor (Blue, red, black).
This is of course only a cosmetical issue, but (especially for COUNTER3 written as black) is a bit disturbing.
The identical variables TIMER0, TIMER1,TIMER2 and TIMER3 in contrast are all consistently coloured red.
I might have overlooked or misinterpreted something.
So please could someone confirm my issues.
[b:7ecfa4ab3e][color=red:7ecfa4ab3e](BASCOM-AVR version : 2.0.7.6 )[/b:7ecfa4ab3e][/color:7ecfa4ab3e]
↧
BASCOM-AVR : Some bugs with TIMER3 variables and simulation with ICP1 (Ti : NEWTOPIC
↧
BASCOM-AVR : Using a non-available/non-allowed channel with GETADC : NEWTOPIC
Hi there,
the ATMEGA1284P has 31 ADC-channels.
In a program I accidentially used a channel number above 31:
A=GETADC(32)
What happened, was that I got totally strange results in the Variable A.
The reason is that BASCOM doesn't counter-check the used channel-number with the maximum that are available in the used chip but simply computes the bit pattern corresponding to the channel number.
In this case the bit-pattern is x100000.
If this bit battern is transferred to the LSBs of the ADMUX register it becomes clear what happened.
Bit5 is set and this bit (ADLAR) does [u:5f8806a7da]left-adjust[/u:5f8806a7da] the 10bit-result in the 16bit ADCL and ADCH result register.
Perhaps there could be a check for the maximum available channels in a future BASCOM version to spare the users what happened to me :-)
Well this check might not be possible if you use a variable for the channel because BASCOM cannot know the content of the variable.
But then it could limit the bits set in ADMUX to the allowed ones and give a hint in the Help-file.
Kind regards
[b:5f8806a7da][color=red:5f8806a7da](BASCOM-AVR version : 2.0.7.6 )[/b:5f8806a7da][/color:5f8806a7da]
↧
↧
BASCOM-AVR : Some issues with the graphic converter and EADOGM 128x64 : NEWTOPIC
Hi there,
When using the graphic converter tool to prepare some graphics for the EADOGM128x64 graphic lcd, I had some minor issues.
When you load the attached "_Triangle_24x8.BMP" file with the graphic converter tool, at first everything looks fine.
But as soon as you save it, you will find some extra pixels set (!) which are visible already on the preview-screen of the graphic converter tool and of course later also on the LCD.
This happened with all my 24x8 pixel graphics!
I looked at the generated bgf.file with a hex-editor and corrected the additionally set pixels manually.
By the way: Perhaps it should be noted in the BASCOM help-file, that for EADOGM128x64 LCDs the option "[b:c4ada69410]SED-series[/b:c4ada69410]" has to be checked.
Otherwise the created bgf-files won't show.
Some other things I found out with the EADOGM128x64 graphic LCDs and the used lib"glcdeadogm128x6.lbx":
- the GLCDCMD and GLCDDATA commands [u:c4ada69410]do [/u:c4ada69410]work.
By using these commands it is e.g. possibly to set the EADOGM to a sleep-modes to save power in battery operated applications.
And of course to write your own graphics routines in BASCOM
The datasheet for the used chip ST7565R can be found at the homepage of Electronic Assembly at [url]http://www.lcd-module.de/eng/pdf/zubehoer/st7565r.pdf[/url]
- using SPC() or FUSING with LCDAT does [u:c4ada69410]not [/u:c4ada69410]work
- the origin of the x,y coordinates with the SHOWPIC command is on the [u:c4ada69410]upper left[/u:c4ada69410] corner. This could perhaps be remarked in the BASCOM help-file because "normally" the origin of an x-y coordinate-system is the l[u:c4ada69410]ower left[/u:c4ada69410] corner.
Kind regards
Roger
[b:c4ada69410][color=red:c4ada69410](BASCOM-AVR version : 2.0.7.6 )[/b:c4ada69410][/color:c4ada69410]
↧
BASCOM-AVR : Some issues with the graphic converter and EADOGM 128x64 : REPLY
you should not use color pictures. if you open the picture in MS paint, and change the properties to B&W you will see how it is converted.
And i guess that these are the pixels you mean. A b&w display can only display : black (a pixel) or white(nothing). So the bitmap you have must have the same state : either there is something, or nothing.
All pixels which are not white are considered 'something' and will be set.
The origin depends on which system you use, but for lcd it is like reading a book : we start at the left at the top. so i found it would make sense to use that. Just like locate.
I will update the help.
↧
BASCOM-AVR : Some issues with the graphic converter and EADOGM 128x64 : REPLY
[quote:870ae2d424="albertsm"]you should not use color pictures. if you open the picture in MS paint, and change the properties to B&W you will see how it is converted.
And i guess that these are the pixels you mean. A b&w display can only display : black (a pixel) or white(nothing). So the bitmap you have must have the same state : either there is something, or nothing.
All pixels which are not white are considered 'something' and will be set.
[/quote:870ae2d424]
Ah. Thanks Mark.
I originally had created the BMPs with PAINT.NET and didn't recognize that it was automatically saved with 24bit color-depth even though I had only used the "colour" pure black and pure white.
I now have reopened the BMP-Files with Irfan-View and then used "Image" --> "Decrease Color Depth" --> "2 Colors (black/white) (1 BPP)" and stored them back.
Now the conversion to BGF-files it works perfect.
Thanks for the hint.
Kind regards
Roger
↧
↧
BASCOM-AVR : Wish: Make Getadc return signed values : NEWTOPIC
Hi,
in [code:1:4cd6812bbe]Config ADC .... [/code:1:4cd6812bbe] I don't see an option to declare signed differential mode. So, what happens is that one has to do a lot of thinking ([i:4cd6812bbe]I know[/i:4cd6812bbe] that's never a bad idea, but enough is enough...)
on how to convert the result to the signed number.
There is a long discussion meanwhile (see [url]http://bascom-forum.de/showthread.php?5250-Zweierkomplement[/url], "Galahat" giving the most simple conversion method. But it would be nice if conversion won't be necessary at all.
Regards, Meister
[b:4cd6812bbe][color=red:4cd6812bbe](BASCOM-AVR version : 2.0.7.6 )[/b:4cd6812bbe][/color:4cd6812bbe]
↧
BASCOM-AVR : Wish: Make Getadc return signed values : REPLY
Shouldn't 1 additional line of code solve the problem?
DIM ADC_DIF as INTEGER
ADC_DIF = GETADC(differential_channel)
If Adc_dif.9 = 1 Then 'Test for negative Result
Adc_dif = Adc_dif Or &B1111110000000000 'Set 6 MSB, so that a 16bit Integer variable is interpreted correctly
End If
Kind regards
Roger
↧
BASCOM-AVR : Wish: Make Getadc return signed values : REPLY
[quote:7f7010c29e]Shouldn't 1 additional line of code solve the problem?[/quote:7f7010c29e]
Yes, after recognizing the problem ... and trying to understand what Getadc brings out in that case since the mode is not supported by config adc...
Indeed, that solution was suggested by "Galahat" in the other forum.
Why not having Getadc doing that directly? That ADC-Mode is quite common in some ATtinys and some Megas. In the XMegas however, the ADC result is coded differently. So it less straightforward to read the ADC at present.
Regards, Meister
↧
BASCOM-AVR : Wish: Make Getadc return signed values : REPLY
[quote:2b63974ec1="Meister"]I don't see an option to declare signed differential mode.[/quote:2b63974ec1]
Maybe because it's an easy task ? And maybe because there's no Atmel standard.
A look in the datasheet tells it all.
Saw you discussed 3 and some pages about these peanuts LOL
Bascom is still a programming software, where such thingies can be solved in a blink of an eye :D
[quote:2b63974ec1]So, what happens is that one has to do a lot of thinking[/quote:2b63974ec1]
That is simply and only your POV.
↧
↧
EASY TCP/IP : BootLoader with NM7010 : REPLY
in the next release i added $bootvector which will include the vector table. it will require more space. and you need to set the IVSEL bit yourself before using the interrupts. And : your normal program should reset the bit.
↧
BASCOM-AVR : Wish: Make Getadc return signed values : REPLY
In agreement with MWS, the Getadc deliveres what it is asked to do.
It is up to every programmer to do with it whatever they want to.
Is "Thinking" ..."OUT" now???
I think it is time to retire if nobody wants to strain or stress out their poor little peanut brains.
Pay for a scooter but deliver a RR. Or better yet, do not pay anything!
Sorry, but I think this thread deserves to be deleted.
Hubert
↧
BASCOM-AVR : Translating C code to Bascom-AVR : REPLY
Hello Dré,
Thanks a lot :). I have downloaded the examples. This would help me to learn.
Best regards.
↧
BASCOM-AVR : Using a non-available/non-allowed channel with GETADC : REPLY
..and make Getadc consume even more time. That's the way to go...make everything a bit slower.
Don't you think that there should be some sesponsibility with the programmer?
Hubert
↧
↧
BASCOM-AVR : RTTY decode? : REPLY
TTY.. have learned it many decades ago (5-bit code) and it was outdated then!
Hubert
↧
BASCOM-AVR : Wish: Make Getadc return signed values : REPLY
Thanks for those very constructive posts.
My suggestion why not having Config ADC as versatile as Config ADCx with regard to differential signed mode.
Regards, Meister.
↧
BASCOM-AVR : XMEGA and SD card without AVR DOS : NEWTOPIC
Hi,
I am using XMEGA256D3. I need a huge Data storage. For Datalogger application.
An SD card is much cheaper than a bank of EEPROMs.
Can I use SD card without using AVR-DOS ? As I don't need all the DOS features. And it may become slow too.
Can someone please point me to related post ? or explain something ?
Regards,
Devidas
[b:4eafcdf157][color=red:4eafcdf157](BASCOM-AVR version : 2.0.7.6 )[/b:4eafcdf157][/color:4eafcdf157]
↧
BASCOM-AVR : XMEGA and SD card without AVR DOS : REPLY
have a look at this, there is C Code for doing you wanted to do:
http://www.microchip.com/forums/m432748-print.aspx
↧
↧
BASCOM-AVR : Using a non-available/non-allowed channel with GETADC : REPLY
[quote:223df9e707="hgrueneis"] Don't you think that there should be some sesponsibility with the programmer?
Hubert[/quote:223df9e707]
No, I don't. Because it's a totally unexpected behaviour of GETADC.
If You want a fast GETADC-function, why don't You program it in assembler.
THAT is the responsibility of the user :-)
Kind regards
Roger
↧
BASCOM-AVR : XMEGA and SD card without AVR DOS : REPLY
Thank you, but C is too much beyond me.
Regards,
Devidas
↧
BASCOM-AVR : Wish: Make Getadc return signed values : REPLY
[quote:edb25e372e="Meister"]My suggestion why not having Config ADC as versatile as Config ADCx with regard to differential signed mode.[/quote:edb25e372e]
Because it makes a ton of work implementing those, as the config must take care about every available AVR in Bascom - in contrary to the tiny piece of work to read the data sheet and implement it accordingly in your code. Additional set it in relation to the overall demand for differential use of the ADC, and you'll learn it's a complete waste.
I'd rather see Mark being busy developing more interesting things, for example about the new IDE, than keeping him busy in mounting additional support wheels on your tricycle, only because you're to lazy "to do a lot of thinking".
Sometime it helps using the brain, and I'm quite sure, you've learned a bit more about µC's and how they work.
It would be a good idea, if you'd follow this path :D
↧