Show Posts
Pages: 1 [2] 3 4 ... 116
16  Using Arduino / Microcontrollers / Re: Why 16 Mhz clock??? on: July 16, 2014, 03:49:00 am
One problem with running at 20MHz is that 20 is not a power of 2 which can make some timings that require divisions complicated.

...R
But then neither is 16MHz, it just has two more 2's as its prime factors (16MHz is divisible by 2^10 vs. 20MHz by 2^8 - they both have lots of 5's in them too).
17  Using Arduino / Microcontrollers / Re: Why 16 Mhz clock??? on: July 16, 2014, 02:41:05 am
All the timers will work in exactly the same way with an external clock vs. a crystal/resonator.

The reason it works without changing the fuse is the way the crystal oscillator work - it is essentially just a NOT gate (1 input, 1 output) which has a crystal connected across it. If you feed a clock signal into the input of the gate it will still feed a clock signal in. Had you connected it to the output of the gate, it wouldn't be happy.
18  Using Arduino / Programming Questions / Re: why do we use int instead of long on: July 15, 2014, 06:18:37 pm
This was my *ugly* solution at the time:
Code:
    #ifdef _LIB_SAM_
        #define DEFAULT_DATA_TYPE unsigned int
        #define DEFAULT_MID_DATA_TYPE unsigned int
        #define DEFAULT_WIDE_DATA_TYPE unsigned int
        #define DEFAULT_SIGNED_DATA_TYPE signed int
        #define DEFAULT_MID_SIGNED_DATA_TYPE signed int
        #define DEFAULT_WIDE_SIGNED_DATA_TYPE signed int
    #else
        #define DEFAULT_DATA_TYPE unsigned char
        #define DEFAULT_MID_DATA_TYPE unsigned int
        #define DEFAULT_WIDE_DATA_TYPE unsigned long
        #define DEFAULT_SIGNED_DATA_TYPE signed char
        #define DEFAULT_MID_SIGNED_DATA_TYPE signed int
        #define DEFAULT_WIDE_SIGNED_DATA_TYPE signed long
    #endif
Then I just used those defines for data types, e.g.:
Code:
gLCD(DEFAULT_DATA_TYPE RS, DEFAULT_DATA_TYPE CS, DEFAULT_DATA_TYPE SCLK, DEFAULT_DATA_TYPE SDATA, SpeedMode speed = NORMAL_SPEED);
As I said, it looks *awful*. But myeh, it works.
19  Using Arduino / Microcontrollers / Re: Why 16 Mhz clock??? on: July 15, 2014, 06:17:04 pm
Because not all parts can run at 20MHz, and I believe way back when, the chosen ATMega was limited to 16MHz.
20  Using Arduino / Programming Questions / Re: why do we use int instead of long on: July 15, 2014, 04:24:08 pm
Looking at the resultant code, the uint24_t's are pretty good.
Which processor? AVR?
Or on a processor like pic32 or ARM that has actual 32 bit registers?
I'd be curious how it does on the processors with the larger registers.

--- bill

I'm talking about AVRs. Generally with 32bit machines the most efficient variable size is 32bits - take my Nokia 6100 LCD library, that was ported to the Due as well and it was stupidly slow until I changed all the bytes and chars to (unsigned) ints [i.e. 32bit] at which point it sped right up.
21  Using Arduino / Programming Questions / Re: why do we use int instead of long on: July 15, 2014, 12:55:10 pm
Looking at the resultant code, the uint24_t's are pretty good. Haven't done any speed tests on multiply/divide and such yet, but for addition/subtraction/general stuff, it comes out great - especially if you want 24bit colour (RGB) and don't want to waste time processing the extra byte.

You do have to add this to your sketch:
typedef __uint24 uint24_t;
typedef __int24 int24_t;
As they have slightly different names than usual. But after that it is fine.
22  Using Arduino / Programming Questions / Re: why do we use int instead of long on: July 15, 2014, 11:46:16 am
I like avr-gcc 4.8, it has a uint24_t and int24_t smiley-grin
23  Using Arduino / Programming Questions / Re: why do we use int instead of long on: July 14, 2014, 05:31:52 pm
Traditionally, the "int" type is the "natural" type for the processor - i.e., it's the size of the processor's registers.  This can be 4, 8, 16, 32... bits, but usually the processor can handle it as fast as possible.

Type "long" is for when you need more precision, even at the expense of slower code.  Type "byte" is good when you need to control the size, regardless of the processor's register size, or if memory space is at a premium.  In classic C, type "char" is usually 8 bits long and hence is used a a form of "byte".

Then there's type "short"....

Logically, many things would actually be well suited to type "bool" --- i.e., only two possible values.  I don't know how type "bool" is implemented, but I expect it takes one byte of storage per variable.

However with avr-gcc, and int isn't the native size for 8bit uCs, its 16bit (presumably because a byte was considered too small, not sure). A short is the same size as an int in this environment.
Also, a long doesn't really give more 'precision' per say, it gives a greater 'range'. All of the integer types have a precision of 1, hence they are integers.
Now if you were doing fixed point maths with them, then yes you could use greater precision, or greater range, or a bit of both.
24  Using Arduino / Programming Questions / Re: why do we use int instead of long on: July 13, 2014, 06:25:34 pm
Thanks for fast reply smiley
Then why dont we use byte ledPin=13; instead of int ledPin=13; ?

Because large parts of the Arduino core and many of the examples supplied are either badly written or hacked together without consideration for efficiency.
25  Using Arduino / Programming Questions / Re: Why arduino "ignore" % on: July 09, 2014, 10:36:16 am
The loop() will happen tens of thousands of times a second in that code, so unless you can see a light blinking that quickly, it will look like the light is always on.
Just to prove a point, add the following line at the end of your loop:
Code:
delay(100);
Is it doing what you expect now?
Try reducing the delay time. Notice what is happening?


As a side note, don't compare the return value of digitalRead() to 1 or 0, compare it to HIGH or LOW. For all you know, one day Arduino might make digitalRead() return 2 and your code won't work anymore, whereas if you use HIGH, it probably would still.
26  Using Arduino / General Electronics / Re: Circuit doesn't power off after disconnecting it's power supply on: July 07, 2014, 06:05:29 pm
The attached diagram might help.
27  Using Arduino / Microcontrollers / Re: Pin Change Interrupt during ISR on: July 07, 2014, 02:16:03 pm
That's fine then. Just wanted to make sure the pin change interrupt wasn't a strange one (or at least no more so than it already is).
28  Using Arduino / Microcontrollers / Pin Change Interrupt during ISR on: July 07, 2014, 07:34:21 am
Something not entirely clear from the ATTiny861 datasheet (and probably similar for most AVRs) is what happens when a pin change occurs during the pin change ISR. An example might help.
Say there are two pins which are enabled for generating a pin change interrupt, and that they are part of the same bank so use the same interrupt vector:
Code:
ISR (PCINT_vect){  //so a pin change has occurred

  //<---- (1) what happens if a pin change occurs *here* (before reading PINA, but after entering the ISR)
 
  byte current = PINA; //lets assume that both belong to Port A
  byte changed = old ^ current; //and that 'old' is a global containing the old value for PINA, then we know which have changed.
  old = current; //back up for next time
  //So at this point we have a 'changed' variable which has ones for each bit which has changed state
 
  //<---- (2) what happens if a pin change occurs *here* (or for that matter any time after reading PINA)

  ... //other code - e.g. if statements to perform specific tasks depending on what changed
}

There are two places there where I am not entirely clear on the behaviour of the ATTiny at these points. Will the ISR be called again after it returns the first time? Or will the changes be lost?

Obviously if the interrupt flag is not set again, then it isn't an issue for (1) as that is already checked, however it causes an issue for (2) as that is not checked yet.
If the interrupt flag is set again, then that is fine for (2) as it needs checking, but it is a bit wasteful for (1) as it has already been checked [won't do any harm as we are backing up the last known value].

I'm hoping that another interrupt is triggered, but want to be sure.
29  Using Arduino / Microcontrollers / Re: ATtiny84 & <avr/fuse.h>, fuses automatically programmed? on: July 07, 2014, 02:45:38 am
The only way to program the fuses is by ISP or HVSP. It is not possible to do it from code running on the microcontroller.

You can however do it in the makefile:
Code:
#How to program the fuses
AVRDUDE_WRITE_FUSES = -U lock:w:0x3f:m -U efuse:w:0x$(EFUSE):m -U hfuse:w:0x$(HFUSE):m -U lfuse:w:0x$(LFUSE):m
#Set up your fuse values:
HFUSE = ...
LFUSE = ...
EFUSE = ...

# Program the device.  
program: $(TARGET).hex $(TARGET).eep
$(AVRDUDE) $(AVRDUDE_FLAGS) $(AVRDUDE_WRITE_FUSES) $(AVRDUDE_WRITE_FLASH) $(AVRDUDE_WRITE_EEPROM)
30  Using Arduino / General Electronics / Re: PNP on: July 06, 2014, 11:11:16 am
You should add a ~100k resistor between the base and emitter of the PNP transistor to make sure that when the switch is open, the transistor is turned off and not floating.

@peter_n The MOSFET in the circuit is correctly drawn as an N-Channel MOSFET.
Pages: 1 [2] 3 4 ... 116