when there is nothing
between that and .trampolines at 0x20f4? I understand the need for the
trampolines, but my code is currently less than the split point where I
would need them. Is there a way to control this?
Thanks for any help!
Best regards,
Stu Bell
Senior Software Engineer
DPHI
Thanks for the hint! I shall try this first thing this morning.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
-Original Message-
Hi, you could solve your problem by using -Wl,--relax . The linker first starts
with worst-case assumptions that imply that it needs a trampoline for
ill jump to the high-memory
function and happiness occurs. The high-memory function will deal with
things, and when it returns the 3-byte address points back at the
lower-page routine.
I.E. It's a big trampoline. Get it? ;-)
Hope this helps (AND I hope I have the concept right).
the calls are pointing into totally
wrong areas of code.
If I remove the option, the resulting code works properly.
I can generate more information for you as soon as I know what you would need.
Best regards,
Stu Bell
Senior Software Engineer
DPHI, Inc. (DataPlay)
email: [EMAIL
ill in
a 16-bit PC address. *sigh*
More info as I get it.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
-Original Message-
From: Francesco Sacchi [mailto:[EMAIL PROTECTED]
Sent: Friday, March 30, 2007 7:15 AM
To: Eric Weddington
Cc: Stu Bell; avr-gcc-list@nongnu.org
Subject: Re
e, it is possible someone else will come across it.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
-Original Message-
From: Eric Weddington [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 10, 2007 4:52 PM
To: Stu Bell
Cc: avr-gcc-list@nongnu.org
Subject: RE: [avr-gcc-list] Option to
ays pity the poor developer who is forced to release
his/her package on someone else's Revision 1.00.00.
Good luck, Eric, et. al.!
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
AVR-GCC-list@no
Your usage of stack will go up with the 2561, since a subroutine return
address is now 3 bytes instead of 2. Be sure that you properly account
for that in any stack initialization that you do, and in all code that
may use RAM.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
_
From
upts disable until ISR completes.
ISR_NOBLOCK - ISR, interrupts enabled until ISR completes.
ISR_NAKED - ISR, no prologue or epilogue.
I suppose this is incompatible with the ISR macro, since we redefine it.
But it seems to meet this bill.
I've included
As well as Martin's solution, you might also look at the solution I used
for my ATmega2560. It's posted on the AVRfreaks.net site:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=48368&;
start=0
As always, there's moe than one way to do anythin
*(.vectors))
*(.length)
KEEP(*(.length))
/* For data that needs to reside in the lower 64k of progmem. */
*(.progmem.gcc*)
. . .
(where the .length stuff is what I added)
Give it a shot.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
-Original Message-
From: [EMAIL PROTECTE
I forgot to add that you can specify the linker script by using the -T
loader flag. In the make file (generated by Mfile), I added:
LDFLAGS += -T linker_script.x
Where linker_script.x is my modified linker script, which resides in the
source home directory.
Best regards,
Stu Bell
DataPlay
Darn it, the wrap function messed up the C:
/* flash code length -- this is loaded in flash by the linker and other
scripts */
const uint32_t ProgramLength __attribute__ ((section (".length"))) = 0;
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
-Original Message-
Fr
BTW, offset_of(.vectors) is 0 for all AVRs.
For example, for my ATmega2560, I know that the variable is *always* at 0xE4.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/m
nst the bootloader section in high memory. Again, this
would be at a known fixed location, but might need to change for
different processors (another requirement that I do not understand).
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
orage across the asm statement. While R0 is not a
problem, R1 will cause issues because of C's "R1 is always 0"
assumption.
That's my quick answer -- I'm sure that those with far more experience
than I will correct me.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
---
ssed by the 16-bit word, not by the 8-bit byte. So, a 16-bit PC
can address 64 K *words*, or 128 K *bytes*. It's only in the m2560/2561
with 256 K bytes of Flash do you run into trouble.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
From: [EMAIL PROTECTED
Pete Wrote:
> Stu Bell wrote:
> > One final comment about your last paragraph. AVR instructions are
> > addressed by the 16-bit word, not by the 8-bit byte. So, a 16-bit
PC
> > can address 64 K *words*, or 128 K *bytes*. It's only in the
> > m2560/2561 with
Pete wrote:
> My previous projects (work related) used the ImageCraft compiler,
> and they have a host of functions, such a cmemcpy, cstrcpy, etc,
> that are similar to the *_P functions. But they also have cmemcpyx,
> cstrcpyx, etc, that use ELPM instead. Is there similar work
> considered f
t's
weird. The generated epilogue seems to match the old (WinAVR20071221)
version.
Best regards,
Stu Bell
DPHI, Inc. (DataPlay)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Ah! It's a quick way of allocating space for the locals. Gotcha!
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 10, 2008 9:07 AM
To: Stu Bell; avr-gcc-list@nongnu.org
Subject: Re: [av
My thanks to all involved! Very clever!
Only reason I asked was I was comparing code between 20071221 and
20080407 (still trying to get my code running on the latest gcc) and
came across it.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
-Original Message-
From: [EMAIL PROTECTED
e needs to have code as well, so your original
comment may be right!
As far as the attribute goes, it sounds good to me.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Anatoly Sokolov
Sent: Friday, May 0
movw r22,r24
C901movw r24,r18
0E94 call prvCopyDataFromQueue
.LM105:
EA81ldd r30,Y+2
FB81ldd r31,Y+3
82A1ldd r24,Z+34
Am I not understanding something here? C
Preston Wilson wrote:
> "Stu Bell" wrote:
>
> > Hi all,
> >
> > I'm chasing down a problem with WinAVR 20080430 and my ATmega2560
code.
> > In generated code comparisons of an ISR between 20071221 and
20080430,
> > I noticed that r30
f problem 1 above, I cannot get my code
to run long enough to find anything else.
If you can live with 20071221, I would stick with that. From your
problem description, I would definitely suspect problem #1 above.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
__
smaller!
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Thomas D. Dean
Sent: Friday, May 16, 2008 10:06 AM
To: [EMAIL PROTECTED]
Cc: avr-gcc-list@nongnu.org
Subject: Re: [avr-gcc-list] Avr-gcc Produces Incorr
>> The PORTA bits are used for hardware control. I want to use the
>> atan2(), etc. calls as pulse stretching.
>>
>> Then I recommend using the calls in to get exact
delays
>> instead of monkeying around with floating point routine calls.
>> They'll be a lot more exact as well as being a boatl
task creation
mechanism, they fall under the same rules as the function pointers.
Using these techniques I have been able to get my code running under
WinAVR 20080521. Hopefully, you can to.
Best of luck!
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
-Original Message-
From: [E
force EIND to 1 at the beginning
of your code...
asm volatile ( "ldi r24, 0x01 \n\t"
"out 0x3C, r24 \n\t"
);
Worth a shot, eh?
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
-Origin
ill generate one if/when asked. I
can also give my current disassembled code of these three areas, if
anyone is interested.
Best regards,
Stu Bell
Senior Software Engineer
DPHI, Inc. (DataPlay)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
h
Thanks, everyone! I figured it was fixed, just not available yet.
My workaround was to copy the rand source into my own source and rename
it. I'll leave it that way for now.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
-Original Message-
From: Weddington, Eric [mailto:[
HAH! Hey, how about a Univac SolidState-80 (circa 1959)? 5000 bi-quint
words! Can we code for that?
Stu ( :-P )
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Steven Michalske
Sent: Wednesday, July 30, 2008 8:38 PM
To: avr-gcc List
Subject: Re
ion,
passing in the function address, and protecting the registers you
clobber so the processor can return (if you want).
Also, when I wrote this, the inline assembler did not grok the EICALL
instruction so I had to hand-assemble it. You may be able to just use
the
nt16_t)((call_address >> 1UL) & 0xUL);
asm volatile (
"ldi r24, 0x01" "\n\t" // set up EIND
"out 0x3C, r24" "\n\t"
"movw r30,%3" "\n\t" //indirec
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=48535 [TUT]
[C] Modularizing C Code: Managing large projects
This should be enough to get you started. So, I guess we will see you on
avrfreaks.net!
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
I created a modified eeprom.h file with the fix for this. It has been
submitted, but has not been integrated into WinAVR yet.
I can send it to you if you want it. Contact me directly.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
From: [EMAIL
*sigh* Okay, now you're forcing me to work. ;-)
I'll start with EIND. The return value is a bit of a "red herring" as
it doesn't really have much to do with the problem but is instead an
artifact of how you are trying to solve the problem. EIND is used in
only two instructions: EIJMP and EICALL
to me that
you actually *save* the parameter and address pushes on the stack,
saving quite a bit.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Paulo Marques
Sent: Monday, September 08, 2008 5:43 AM
T
Oh, I see. The inlining causes an "almost" static definition for the
locals in the functions. As someone else said, the reuse of the stack
is disabled.
Wow, that's a good reason to avoid use of local variables in inlined
functions. If it's possible. :( Yuck!
Best
ials forum on avrfreaks.net -- there's a thread with a
pile of Oses for AVRs of all flavors.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
help.
If I were to provide a hint, I would look at the definitions of _VECTOR
and ISR. But then, I program my PC in C++ and my AVR in C. What do I
know? ;-)
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
vrFreaks.net, but I
cannot find it at the moment.
Hope this helps!
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
From: avr-gcc-list-bounces+sbell=dataplay@nongnu.org
[mailto:avr-gcc-list-bounces+sbell=dataplay@nongnu.org] On Behalf Of
Schw
here is,
and I can't remember what I did.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
> -Original Message-
> From: avr-gcc-list-bounces+sbell=dataplay@nongnu.org
> [mailto:avr-gcc-list-bounces+sbell=dataplay@nongnu.org]
> On Behalf Of Simon Eatough
> Sent
registers needed falls to you. If the ISR is simple, as you said, a
little assembly might be just the trick.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
> > The subject says it all. I've an ISR that is using too many cycles
> > for something that kicks every 10us.
Sorry all, I missed dlc's later post.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
> -Original Message-
> From: avr-gcc-list-bounces+sbell=dataplay@nongnu.org
> [mailto:avr-gcc-list-bounces+sbell=dataplay@nongnu.org]
> On Behalf Of Stu Bell
> Sent:
?
>
> Don't quite understand the push/popped reference, but if a
> variable is accessed in both interrupt space and "user" space
> it needs to be protected so that its uses "atomically".
Which is why there is the macros. Check out:
ATOMIC_BLOCK( ATOMIC_R
.
Dean Camera (sp?) added them a year or two back. Very useful!
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
n purposes. It nice to
think that some other poor slob maintaining my code will be notified of
the importance of the atomicity of the section I mark. Plus, with the
separate commands it's easy to accidently remove one of the key
statements without any whining from the compiler. ATOMIC_BLOCK
t the SubVersion manual:
http://svnbook.red-bean.com/en/1.5/svn.advanced.props.special.keywords.h
tml
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
alue. At *compile time*, what is the value of TIME[0]? Unknown.
Ergo, the compiler error.
In the functions:
> unsigned char GetCompileHour(void)
> {
> unsigned char hour=COMPILE_HOUR;
> return(hour);
> }
COMPILE_HOUR is run-time computable, and so works.
Best regards,
up with synchronized counts from the two edges. Then
there's not a latency issue (or nearly as bad a one).
I checked, and unfortunately the mega324(P) series has the same timer
configuration as your mega32.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
__
users* that post
regularly on this mail list, AVR Freaks, etc.
I've been waiting for almost 40 years for a compiler/interpreter that
would do what I *meant* instead of what I *programmed*! :D
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
__
uld make a delay function for each clock frequency, but
> that seems less than optimal.
You could set F_CPU to a "normalized" value, say 10 MHZ, and then scale
the calling value to _delay_*() based on the ratio of current speed to
normalized
function pointer and
I'm sure you'll run across it.
BTW, my ATmega2560 code is now over 160 Kbytes long. I am well over the
128K boundary and running with no problems. With a littl ebit of linker
skill. ;-)
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
> -Original Mes
file=viewtopic&t=6891
1
http://www.avrfreaks.net/index.php?module=PNphpBB2&file=viewtopic&t=7038
7
I am using FreeRTOS, so I also place any RTOS functions that may be
called at switch-context time in lower memory. They are placed in the
linker section .task using the same methods as above.
Bes
function table for the bootloader
residing in the BLS. I've never done that, but I think some folks on
AVR Freaks have, so a quick forum search should yield some results.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Check out
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=38003
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
> -Original Message-
> From: avr-gcc-list-bounces+sbell=dataplay@nongnu.org
> [mailto:avr-gcc-list-bounces+sbell=dataplay@
ed to use the pgm_read_*_far() functions to access them. Do a
search on AVRFreaks.net for morepgmspace.h for macros to deal with
program strings beyond 64 Kbytes.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
they are working hard on bugs and fom
what little I can tell it actually seems true.
Here's another idea (which Eric should comment on first): Try loading
CygWin and running avrdude *only* (not the make or anything else) from
the cygwin bash window. That eliminates the Windows DOS shell as
es for
EEPROM. At 15 minutes per record, he starts wearing out memory after
about 104 days. Even with internal EEPROM (which won't work, too small)
that would be about 2.8 years.
On the whole, I think that an external EEPROM (or better, SD card) is
the answer.
Best regards,
Stu
TESTPROC_LCD_2, myarg );
That's my inspiration for the day. It's probably wrong somewhere, but
it's how I would approach the problem.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
> On Mon, May 11, 2009 at 08:21:37AM -0600, Weddington, Eric wrote:
> > > > Sounds to me as if you are making the "bootloader" too big and
> > > > should simply link an entire application for every possible
> > > > target. What you are doing would make more sense if the
> loadable
> > > > mo
em from immediate values directly in the
code.
This can actually be a good thing. For example,
char foo;
. . .
if ( foo == '\n' ) . . .
In the above example, it will be easier to compile the constant '\n'
directly into the code as an immediate value rather than setting up a
constant value somewhere.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
foo[128];
. . .
if ( strncmp_P( foo, PSTR( "abd" ), 3 ) == 0 )
{. . .
I would need to look at the implementation of strncmp_P to decide if
this is as efficient as Jan would like.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
-program
To use the options, you must compile all of your source with one call to
the compiler:
avr-gcc ... -combine -fwhole-program ... main.c foo.c grunge.c
gort.c mylib.c ...
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mai
nt out that there *is* another fix for the problem: I
understand the IAR and CodeVision have compilers capable of handling the
larger ATMega series. Oh wait, those cost *money*. Well, Cheap Fast
Good - choose two.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
_
> Stu Bell wrote:
> > Trampolines work only for statically linked functions, not function
> > pointers.
> Sorry, but I don't understand this.
> I believe that there is no problem with statically linked functions.
And that's what I said. There is not a problem w
> Where is the place to fill the bug report?
Send reports of problems with AVR Studio to avr-at-atmel.com (replace
the -at- with @).
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
h
funky with an Interrupt Service
Routine, but that's just a guess. Perhaps you can post the code you
think is bad.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
> -Original Message-
> On Behalf Of xiaona...@gmail.com
>
> Hi all,
>
> In my code, I found that t
> On Thu, Aug 27, 2009 at 09:55:05AM -0500, David Kelly wrote:
> > On Wed, Aug 26, 2009 at 08:21:00PM -0700, Parthasaradhi
> Nayani wrote:
> >
> > > Details of application - I have data packets each 32 bytes in size
> > > and we have accommodate 2000 of these (predefined).
> >
> > 32 * 2000 = 6
oes not need to be *your* Bad Judgment.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
, unimplemented: called from here
...
The above code compiles fine if the optimizer is turned on (-Os). Of
course, I guess the real question (which I have not investigated) is
whether it compiles *correctly* with -Os. :-/ It functions correctly,
so I presum
er( uint16_t Wait )
> __attribute__((always_inline)); static inline void
> FcsStartUtilTimer( uint16_t Wait )
Ah ha, that's it! I read that description several times and never quite
got it. Thanks for setting me straight, Dave!
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
've read the tutorial on C++ and GCC:
<http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=59453
>
check out the huge list of links for newbies:
<http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopi
oad order to make sure the switch statement is
on one side or other of the boundary.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
> -Original Message-
> From: avr-gcc-list-bounces+sbell=dataplay@nongnu.org
> [mailto:avr-gcc-list-bounces+sbell=dataplay@nongnu.org]
Cool idea, Dale! I may give this a try in my code as it would make some
other problems simpler.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
> -Original Message-
> On Behalf Of Dale Whitfield
> Sent: Wednesday, January 20, 2010 8:54 AM
>
orries.
>
> It should be just as easy as it has been, and in the future,
> it should be even easier. ;-)
Hope springs eternal. :-P ;-)
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
ht
logue/epilogue code, right?
On ISRs, the processor itself takes care of turning off the appropriate
level of interrupts, and the RETI turns them back on.
(And, yes, I know: stop calling you Shirley.)
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GC
a request on the AVR Gcc forum of avrfreaks.net to get
more information.
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
e ;-) ),
don't believe for a minute that I don't wish for them!
Best regards,
Stu Bell
DataPlay (DPHI, Inc.)
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
actually pretty simple to work up a mildly customized linker script
and a macro for the function targets and ISRs to force them into special
memory section in low memory. See my posting in AVRFreaks.net under
Tutorials for FreeRTOS on the ATmega2560 for an example of how to do
this.
Best regards,
.
Stu Bell
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
VR Studio. It is on it's last official
release, at least officially.) AVR Studio is an IDE that requires WINE (at a
minimum) to work properly on Linux. Reports I have seen are that some are able
to get it to work, while others are not. YMMV. Most Linux-ites use Eclipse or
other favori
On 6/18/2011 2:08 AM, j...@lillahusetiskogen.se wrote:
On Sat, 18 Jun 2011 10:02:19 +0300
Oleksandr Redchuk wrote:
2011/6/18, Royce Pereira:
So the menu item for 32A is just for psychological purposes !
The next step will be adding separate menu positions for DIP and TQFP
packages :-)
Use
s is a wart, a
product of the C definition. It is what it is. Accept it and move on.
Stu Bell
PS: Yeah, I still write volumes when a sentence (or silence) will do. :-)
On 2/9/2017 1:20 PM, David Brown wrote:
On 09/02/17 19:49, Bob Paddock wrote:
On Thu, Feb 9, 2017 at 1:13 PM, David Brown wro
86 matches
Mail list logo
