BTW, I hardly use internal oscillator when quality results are expected but I guess this project is less and less for the users who are not Jallib developers.
On Wed, Mar 12, 2014 at 4:48 PM, vasi vasi <[email protected]> wrote: > > In my view the main purposes of the blink-a-led samples ... > > In that respect, do a single sample with compiler conditionals (pseudocode > follows): > > #define USE_EXTERNAL_CRYSTAL -- comment this if you use internal oscilator > > #if defined(USE_EXTERNAL_CRYSTAL) > -- config bits for external crystal > #else > -- config bits for internal oscillator > #endif > > Both cases are covered with a single bush, oops, example. And the > educational purpose is achieved more efficiently (user will learn about > three subjects: compiler conditionals, external crystal config bits and > internal oscillator config bits ) . > > > On Wed, Mar 12, 2014 at 4:25 PM, mattschinkel <[email protected]>wrote: > >> I agree with Kiste... I usually only use _intosc to reduce parts. On the >> other hand, external OSC is important to get a certain speed. To be honest, >> I'd rather have both sample types. There are other solutions, like having a >> folder for each sample type. >> >> I would have suggested that all blink samples go in it's own folder, but >> it's not fair to Rob to have only his samples in a folder. >> >> Maybe there's another solution... Can all blink samples that don't have >> other samples go in a folder? Again, maybe this isn't fair to Rob either. >> >> >> On Wednesday, March 12, 2014 4:04:32 AM UTC-4, Kiste wrote: >> >>> Well, I can't be more specific than this: I hardly ever use anything >>> else than the internal oscillator. I could do without all of the _hs >>> samples, replacing them by _intosc. >>> >>> I think it might be unwise to follow this suggestion, but it is how I do >>> things. If there's no good reason to use additional parts, I don't. In most >>> cases, the internal oscillator is very suitable. >>> >>> Greets, >>> Kiste >>> >>> ------------------------------ >>> *Von:* Rob Hamerling <[email protected]> >>> >>> Hi guys, >>> >>> Currently the generated blink samples are of type <pic>_blink_hs, >>> unless the pic doesn't support a HS oscillator, then there will be a >>> <pic>_blink_intosc. There are also a few 'loose' blink_intosc sample. >>> I'm considering to generate more samples of type <pic>_blink_intosc, >>> but seems overdone for every pic. For which PICs would it be useful to >>> have a <pic>_blink_intosc type alongside a <pic>_blink_hs type? Be >>> specific please. >>> Regards, Rob. >>> -- >>> R. Hamerling, Netherlands --- http://www.robh.nl >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "jallib" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> >>> Visit this group at http://groups.google.com/group/jallib. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "jallib" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/jallib. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Vasi > -- Vasi -- You received this message because you are subscribed to the Google Groups "jallib" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/jallib. For more options, visit https://groups.google.com/d/optout.
