new STM32 !

[Alex Babkin]

following luminary, ST comes through and unveils their new stuff: STM32f105/f107

http://www.st.com/stonline/products/literature/ds/15274.pdf

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Mike Panetta]

Yeah, and I am kinda disappointed.  The flash still sucks (2ws at 72MHz, where as the Luminary parts are 0ws at 100) and no built in PHY.  Otherwise they are pretty much the same as the other parts in the line, where the high end with EBI is my fav for now.

For price I think the STM32 series is still better (if you don't care about ethernet), but I am not sure about power usage anymore.  The STM32's used to be at the top there (maybe due to the slower flash??) but the new Luminary parts apparently use a new Cortex-M3 core that's on a smaller process which should use less power.

Mike

On Tue, Mar 3, 2009 at 8:39 PM, Alex Babkin <[hidden email]> wrote:

following luminary, ST comes through and unveils their new stuff: STM32f105/f107

http://www.st.com/stonline/products/literature/ds/15274.pdf

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

I would guess it would depend on usage, but one can't even compare at the moment because the Luminary datasheets indicate that the power usage data are "pending."

I'm glad to see that they're all growing these bus interfaces though.  I wonder when we'll see some reference/eval/dev boards based on them.  I'd love to be able to use the Luminary platform even with some small amount of SDRAM attached.

-jsnyder

----- "Mike Panetta" <[hidden email]> wrote:

> Yeah, and I am kinda disappointed.  The flash still sucks (2ws at 72MHz, where as the Luminary parts are 0ws at 100) and no built in PHY.  Otherwise they are pretty much the same as the other parts in the line, where the high end with EBI is my fav for now.
>
> For price I think the STM32 series is still better (if you don't care about ethernet), but I am not sure about power usage anymore.  The STM32's used to be at the top there (maybe due to the slower flash??) but the new Luminary parts apparently use a new Cortex-M3 core that's on a smaller process which should use less power.
>
> Mike
>
>

> On Tue, Mar 3, 2009 at 8:39 PM, Alex Babkin <[hidden email]> wrote:
>

following luminary, ST comes through and unveils their new stuff: STM32f105/f107
>
> http://www.st.com/stonline/products/literature/ds/15274.pdf
>
> _______________________________________________
> Elua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

>
> _______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

Something else interesting about the LM3S parts is that the driver library comes built-in in ROM (along with their bootloader, AES tables, and some CRC software).

That should save a bit on usage of that 256k of flash.

-jsnyder

On Mar 3, 2009, at 9:32 PM, James Snyder wrote:

I would guess it would depend on usage, but one can't even compare at the moment because the Luminary datasheets indicate that the power usage data are "pending."

I'm glad to see that they're all growing these bus interfaces though.  I wonder when we'll see some reference/eval/dev boards based on them.  I'd love to be able to use the Luminary platform even with some small amount of SDRAM attached.

-jsnyder

----- "Mike Panetta" <[hidden email]> wrote: 

> Yeah, and I am kinda disappointed.  The flash still sucks (2ws at 72MHz, where as the Luminary parts are 0ws at 100) and no built in PHY.  Otherwise they are pretty much the same as the other parts in the line, where the high end with EBI is my fav for now.
> 
> For price I think the STM32 series is still better (if you don't care about ethernet), but I am not sure about power usage anymore.  The STM32's used to be at the top there (maybe due to the slower flash??) but the new Luminary parts apparently use a new Cortex-M3 core that's on a smaller process which should use less power.
> 
> Mike
> 
>

> On Tue, Mar 3, 2009 at 8:39 PM, Alex Babkin <[hidden email]> wrote:
>

following luminary, ST comes through and unveils their new stuff: STM32f105/f107
> 
> http://www.st.com/stonline/products/literature/ds/15274.pdf
> 
> _______________________________________________
> Elua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
> 
>

> 
> _______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________

Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[BogdanM]

On Wed, Mar 4, 2009 at 5:48 AM, James Snyder <[hidden email]> wrote:

Something else interesting about the LM3S parts is that the driver library comes built-in in ROM (along with their bootloader, AES tables, and some CRC software).

Really?! I completely missed that one. How very strange. Indeed, that should save a bit on the flash usage, but it also makes the driver library completely unupgradable. Definitely not something I would've done.

Best,
Bogdan
 

That should save a bit on usage of that 256k of flash.

-jsnyder

On Mar 3, 2009, at 9:32 PM, James Snyder wrote:

I would guess it would depend on usage, but one can't even compare at the moment because the Luminary datasheets indicate that the power usage data are "pending."

I'm glad to see that they're all growing these bus interfaces though.  I wonder when we'll see some reference/eval/dev boards based on them.  I'd love to be able to use the Luminary platform even with some small amount of SDRAM attached.

-jsnyder

----- "Mike Panetta" <[hidden email]> wrote: 
> Yeah, and I am kinda disappointed.  The flash still sucks (2ws at 72MHz, where as the Luminary parts are 0ws at 100) and no built in PHY.  Otherwise they are pretty much the same as the other parts in the line, where the high end with EBI is my fav for now.
> 
> For price I think the STM32 series is still better (if you don't care about ethernet), but I am not sure about power usage anymore.  The STM32's used to be at the top there (maybe due to the slower flash??) but the new Luminary parts apparently use a new Cortex-M3 core that's on a smaller process which should use less power.
> 
> Mike
> 
>

> On Tue, Mar 3, 2009 at 8:39 PM, Alex Babkin <[hidden email]> wrote:
>

following luminary, ST comes through and unveils their new stuff: STM32f105/f107
> 
> http://www.st.com/stonline/products/literature/ds/15274.pdf
> 
> _______________________________________________
> Elua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
> 
>

> 
> _______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

I can't seem to find the datasheet for the ROM version of the driver lib, but it looks like all the function names are prepended with ROM_, and I'm not sure if the whole driverlib is in there or not.

I'm guessing they're thinking the driver lib is fairly stable at this point?  You could certainly selectively replace functions where you wanted to, but I'd rather have the same number of bytes of ROM available as flash instead.

All that said, I could imagine if they did find a bug and fixed it that it could be irritating to check which ROM version you've got and selectively work around bugs when/where needed.  I'll be curious to see if they have any creative ways of dealing with these issues.

Maybe we could talk them into sending one of us a devel board to play with?

-jsnyder

----- "Bogdan Marinescu" <[hidden email]> wrote:

>
>
>

> On Wed, Mar 4, 2009 at 5:48 AM, James Snyder <[hidden email]> wrote:
>

>

Something else interesting about the LM3S parts is that the driver library comes built-in in ROM (along with their bootloader, AES tables, and some CRC software).

>
> Really?! I completely missed that one. How very strange. Indeed, that should save a bit on the flash usage, but it also makes the driver library completely unupgradable. Definitely not something I would've done.
>
> Best,
> Bogdan
>  
>

>

>

That should save a bit on usage of that 256k of flash.

>

-jsnyder

>
>

On Mar 3, 2009, at 9:32 PM, James Snyder wrote:

>

> I would guess it would depend on usage, but one can't even compare at the moment because the Luminary datasheets indicate that the power usage data are "pending."
>
> I'm glad to see that they're all growing these bus interfaces though.  I wonder when we'll see some reference/eval/dev boards based on them.  I'd love to be able to use the Luminary platform even with some small amount of SDRAM attached.
>
> -jsnyder
>
> ----- "Mike Panetta" <[hidden email]> wrote: 
> > Yeah, and I am kinda disappointed.  The flash still sucks (2ws at 72MHz, where as the Luminary parts are 0ws at 100) and no built in PHY.  Otherwise they are pretty much the same as the other parts in the line, where the high end with EBI is my fav for now.
> > 
> > For price I think the STM32 series is still better (if you don't care about ethernet), but I am not sure about power usage anymore.  The STM32's used to be at the top there (maybe due to the slower flash??) but the new Luminary parts apparently use a new Cortex-M3 core that's on a smaller process which should use less power.
> > 
> > Mike
> > 
> >

> > On Tue, Mar 3, 2009 at 8:39 PM, Alex Babkin <[hidden email]> wrote:
> >

following luminary, ST comes through and unveils their new stuff: STM32f105/f107
> > 
> > http://www.st.com/stonline/products/literature/ds/15274.pdf
> > 
> > _______________________________________________
> > Elua-dev mailing list
> > [hidden email]
> > https://lists.berlios.de/mailman/listinfo/elua-dev
> > 
> >

> > 
> > _______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
> Elua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
>

>

>

>

>

> _______________________________________________
> Elua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

>
> _______________________________________________ Elua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Tony-12]

One big plus for me: you can finally use the CAN ports and USB ports at the same time.  (Previous STM32 parts had a shared buffer for CAN and USB).  I also like the LQFP-64 package, and IEEE-1588 support.  No PHY is fine with me; there's a good chance if I design a STM32 board, it will have a 2-port Ethernet switch.  And ST doesn't require registration to see the datasheet (and yes, this can be a big deal - my brother, who has a number of ARM-based designs in production, won't consider Luminary because of their registration.  It discourages just checking chips out).  OTOH, the Stellaris 9B95 is a better eLua MCU.

As far as flash memory goes, remember that:
1.  No one really has zero wait state flash at 100MHz -- that implies a 10nsec flash cycle time, and that simply does not exist.  Instead, companies do things like use a wider bus (e.g. 128-bits) and pre-fetch from the flash.  Now the flash runs at 25nsec, but the bandwidth is the same (400MB/sec).
2. Mixed technology chips are harder to do.  Flash-only chips use a highly optimized process (just for flash) and are typically in a much more advanced process (probably <65nm) than MCUs (mostly >90nm, often 130nm or 180nm).  It's also a tough business; Spansion (#1 in NOR) just went into Chapter 11 bankruptcy.
3. MCUs >= 2MB flash either use a stacked die approach (STR9xx) or are prohibitively expensive (Freescale MPC5xxx)\

It's even hard to do a lot of fast SRAM.  I was looking at the TI C28346 datasheet, and noticed only some of the SRAM is 0 wait state; the majority is 1 ws.  Another example - L1 caches are always very small (typically 16-64KB); the huge caches are always L2 or L3. 

--Tony

Alex Babkin wrote:

following luminary, ST comes through and unveils their new stuff: STM32f105/f107

http://www.st.com/stonline/products/literature/ds/15274.pdf

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
  

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Joern Kaipf]

Tony wrote:

> As far as flash memory goes, remember that:
> 1.  No one really has zero wait state flash at 100MHz -- that implies a
> 10nsec flash cycle time, and that simply does not exist.  Instead,
> companies do things like use a wider bus (e.g. 128-bits) and pre-fetch

They have 1ws on the flash, if I remember right what was told at the
embedded world at the LM booth today. But they have the mentioned
pre-fetch buffer.

A device with more flash (512k) is planned but will not released this
year. The mass production for the announced devices is planned for Q4/09.

Joern



_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Mike Panetta]

On Wed, Mar 4, 2009 at 12:01 PM, Tony <[hidden email]> wrote:

One big plus for me: you can finally use the CAN ports and USB ports at the same time.  (Previous STM32 parts had a shared buffer for CAN and USB).  I also like the LQFP-64 package, and IEEE-1588 support.  No PHY is fine with me; there's a good chance if I design a STM32 board, it will have a 2-port Ethernet switch.  And ST doesn't require registration to see the datasheet (and yes, this can be a big deal - my brother, who has a number of ARM-based designs in production, won't consider Luminary because of their registration.  It discourages just checking chips out).  OTOH, the Stellaris 9B95 is a better eLua MCU.

Hmm, thats a good point.  I wonder if it would be possible to use one of the new STM32 parts as an IEEE-1588 grand master clock by attaching a multi-port switch to it instead of a simple PHY?

I don't quite see how requiring registration discourages anything really.  Its easy to do, and they do not spam you.  Its a hell of a lot better then what Marvell requires, which is a full NDA before you can see anything more then a simple 2 page glossy...
 

As far as flash memory goes, remember that:
1.  No one really has zero wait state flash at 100MHz -- that implies a 10nsec flash cycle time, and that simply does not exist.  Instead, companies do things like use a wider bus (e.g. 128-bits) and pre-fetch from the flash.  Now the flash runs at 25nsec, but the bandwidth is the same (400MB/sec).
2. Mixed technology chips are harder to do.  Flash-only chips use a highly optimized process (just for flash) and are typically in a much more advanced process (probably <65nm) than MCUs (mostly >90nm, often 130nm or 180nm).  It's also a tough business; Spansion (#1 in NOR) just went into Chapter 11 bankruptcy.
3. MCUs >= 2MB flash either use a stacked die approach (STR9xx) or are prohibitively expensive (Freescale MPC5xxx)

While I agree that the thought of 10ns Flash is a bit preposterous, I can't find anywhere in the datasheet for the LM3S9B95 the mention of a prefetch buffer, nor a way to configure one as some other ARM chips have.  It also consistantly mentions that the flash is single cycle (0ws) everywhere the flash is mentioned.

This is in stark contrast to the datasheets for the STM32 chips, which do mention wait states and prefetch buffer registers...

If someone could explain this conflict to me I would love it!

It's even hard to do a lot of fast SRAM.  I was looking at the TI C28346 datasheet, and noticed only some of the SRAM is 0 wait state; the majority is 1 ws.  Another example - L1 caches are always very small (typically 16-64KB); the huge caches are always L2 or L3. 

Not to mention that SRAM cells are quite a bit larger then either Flash or SDRAM cells, so take up more die realistate. 

--Tony

Alex Babkin wrote:

following luminary, ST comes through and unveils their new stuff: STM32f105/f107

http://www.st.com/stonline/products/literature/ds/15274.pdf

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev
  

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

On Mar 4, 2009, at 4:00 PM, Mike Panetta wrote:

On Wed, Mar 4, 2009 at 12:01 PM, Tony <[hidden email]> wrote:

One big plus for me: you can finally use the CAN ports and USB ports at the same time.  (Previous STM32 parts had a shared buffer for CAN and USB).  I also like the LQFP-64 package, and IEEE-1588 support.  No PHY is fine with me; there's a good chance if I design a STM32 board, it will have a 2-port Ethernet switch.  And ST doesn't require registration to see the datasheet (and yes, this can be a big deal - my brother, who has a number of ARM-based designs in production, won't consider Luminary because of their registration.  It discourages just checking chips out).  OTOH, the Stellaris 9B95 is a better eLua MCU.

Hmm, thats a good point.  I wonder if it would be possible to use one of the new STM32 parts as an IEEE-1588 grand master clock by attaching a multi-port switch to it instead of a simple PHY?

I don't quite see how requiring registration discourages anything really.  Its easy to do, and they do not spam you.  Its a hell of a lot better then what Marvell requires, which is a full NDA before you can see anything more then a simple 2 page glossy...
 

As far as flash memory goes, remember that:
1.  No one really has zero wait state flash at 100MHz -- that implies a 10nsec flash cycle time, and that simply does not exist.  Instead, companies do things like use a wider bus (e.g. 128-bits) and pre-fetch from the flash.  Now the flash runs at 25nsec, but the bandwidth is the same (400MB/sec).
2. Mixed technology chips are harder to do.  Flash-only chips use a highly optimized process (just for flash) and are typically in a much more advanced process (probably <65nm) than MCUs (mostly >90nm, often 130nm or 180nm).  It's also a tough business; Spansion (#1 in NOR) just went into Chapter 11 bankruptcy.
3. MCUs >= 2MB flash either use a stacked die approach (STR9xx) or are prohibitively expensive (Freescale MPC5xxx)

While I agree that the thought of 10ns Flash is a bit preposterous, I can't find anywhere in the datasheet for the LM3S9B95 the mention of a prefetch buffer, nor a way to configure one as some other ARM chips have.  It also consistantly mentions that the flash is single cycle (0ws) everywhere the flash is mentioned.

This is in stark contrast to the datasheets for the STM32 chips, which do mention wait states and prefetch buffer registers...

If someone could explain this conflict to me I would love it!

Page 197 of the 9B95 datasheet, section 7.2.3:

"The Flash memory controller has a prefetch buffer that is automatically used when the CPU frequency 

is greater than 50 MHz. The prefetch buffer fetches two 32-bit words per clock allowing Flash memory 

to be read with no wait states while code is executing linearly. Branches incur a single wait state."

So, it sounds like what Tony was describing :-)

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

ph: [phone]

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Mike Panetta]

On Wed, Mar 4, 2009 at 5:34 PM, James Snyder <[hidden email]> wrote:

On Mar 4, 2009, at 4:00 PM, Mike Panetta wrote:

As far as flash memory goes, remember that:
1.  No one really has zero wait state flash at 100MHz -- that implies a 10nsec flash cycle time, and that simply does not exist.  Instead, companies do things like use a wider bus (e.g. 128-bits) and pre-fetch from the flash.  Now the flash runs at 25nsec, but the bandwidth is the same (400MB/sec).
2. Mixed technology chips are harder to do.  Flash-only chips use a highly optimized process (just for flash) and are typically in a much more advanced process (probably <65nm) than MCUs (mostly >90nm, often 130nm or 180nm).  It's also a tough business; Spansion (#1 in NOR) just went into Chapter 11 bankruptcy.
3. MCUs >= 2MB flash either use a stacked die approach (STR9xx) or are prohibitively expensive (Freescale MPC5xxx)

While I agree that the thought of 10ns Flash is a bit preposterous, I can't find anywhere in the datasheet for the LM3S9B95 the mention of a prefetch buffer, nor a way to configure one as some other ARM chips have.  It also consistantly mentions that the flash is single cycle (0ws) everywhere the flash is mentioned.

This is in stark contrast to the datasheets for the STM32 chips, which do mention wait states and prefetch buffer registers...

If someone could explain this conflict to me I would love it!

Page 197 of the 9B95 datasheet, section 7.2.3:

"The Flash memory controller has a prefetch buffer that is automatically used when the CPU frequency 

is greater than 50 MHz. The prefetch buffer fetches two 32-bit words per clock allowing Flash memory 

to be read with no wait states while code is executing linearly. Branches incur a single wait state."

So, it sounds like what Tony was describing :-)

Well crap, I completely missed that.  I don't know how as I read that section!  Musta read it too fast. :P

Mike
 

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

ph: [phone]

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Tony-12]

Many of the Stellaris MCUs also support IEEE-1588.

I'm not likely to use any Marvell parts -- their attitude basically tells me "we don't want you", and there are fine alternatives to their parts.

Requiring registration shows the company's attitude.  It's not friendly, and there is no reason for it, except for marketing.  I won't do it unless Luminary has some truly compelling chips, and unlike Bogdan, I have not found any Stellaris parts particularly compelling for my possible applications.

They should remember the history of Microchip, which has become one of the top MCU vendors in large part by being very friendly to small users (including hobbyists and students); enough of these users went on to use PICs in production to handsomely payback Microchip.

BTW, I've got my C6701 board installed, and am working on getting its development tools setup correctly.

--Tony

On Wed, Mar 4, 2009 at 2:00 PM, Mike Panetta <[hidden email]> wrote:

On Wed, Mar 4, 2009 at 12:01 PM, Tony <[hidden email]> wrote:

One big plus for me: you can finally use the CAN ports and USB ports at the same time.  (Previous STM32 parts had a shared buffer for CAN and USB).  I also like the LQFP-64 package, and IEEE-1588 support.  No PHY is fine with me; there's a good chance if I design a STM32 board, it will have a 2-port Ethernet switch.  And ST doesn't require registration to see the datasheet (and yes, this can be a big deal - my brother, who has a number of ARM-based designs in production, won't consider Luminary because of their registration.  It discourages just checking chips out).  OTOH, the Stellaris 9B95 is a better eLua MCU.

Hmm, thats a good point.  I wonder if it would be possible to use one of the new STM32 parts as an IEEE-1588 grand master clock by attaching a multi-port switch to it instead of a simple PHY?

I don't quite see how requiring registration discourages anything really.  Its easy to do, and they do not spam you.  Its a hell of a lot better then what Marvell requires, which is a full NDA before you can see anything more then a simple 2 page glossy...
 

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[jbsnyder]

On Mar 6, 2009, at 3:05 PM, Tony wrote:

Many of the Stellaris MCUs also support IEEE-1588.

I'm not likely to use any Marvell parts -- their attitude basically tells me "we don't want you", and there are fine alternatives to their parts.

Requiring registration shows the company's attitude.  It's not friendly, and there is no reason for it, except for marketing.  I won't do it unless Luminary has some truly compelling chips, and unlike Bogdan, I have not found any Stellaris parts particularly compelling for my possible applications.

Actually, I don't think they require registration, even though it looks like it.  I just tried grabbing one of the datasheets for the latest crop of MCUs and clicked on "OPTIONS" instead of LOGIN or REGISTER, and it let me just download the datasheet from the following page.

They also state:

"NO SALES PERSON WILL CONTACT YOU unless you explicitly request it."

I would, however, agree that it is more irritating to download this way, which would encourage people to register with them.

They should remember the history of Microchip, which has become one of the top MCU vendors in large part by being very friendly to small users (including hobbyists and students); enough of these users went on to use PICs in production to handsomely payback Microchip.

This is true.  I think ATMEL also gets a lot of similar milage for AVR because development tools are free and easy to set up. And, of course, all app notes and datasheets are freely available.

I somewhat remember hearing, though, that Luminary gave a board to Dado for eLua development? Is this true?

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

ph: [phone]

_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev