eLua Development

eLua open hardware

Classic

List

Threaded

72 messages Options

1234

BogdanM

eLua open hardware

Hi all,

There was recently a discussion on the Lua list about Lua on embedded
devices, and thinks got pretty hot (in a good way :) ), so I invited all the
people that wanted to continue that discussion to join this list (since the
profile of the Lua list suggests that it's not the best place to discuss
regular hardware). We had more than 10 people joining the elua-dev list
after this announcement, so I expect things to become pretty hot here too :)
I'll try to resume the discussions by including the last relevent message
from the Lua list (this message is from Mike Panetta):

========================================

On Wed, Feb 11, 2009 at 12:22 PM, Tony Bauer <luatony at gmail.com> wrote:

> More embedded notes (with some Lua content):
>
> Yes, the LPC2478 is pretty nice. My brother was looking at using one
> at work (no Lua, though), but that project is currently on hold.
>
> Somebody will make a Cortex M3 with an external bus. The NXP LPC17xx
> series (Cortex M3) looks pretty nice; the LPC1768 has 64K RAM, 512K
> flash, MAC, USB OTG, 2xCAN, 4xUART, PWM, QEP, etc, but no external
> bus.

I am willing to bet that either Luminary or ST Micro will be the first out
the gate with such a design. In fact ST Micro has a new line of chips on
the back burner to release some time this year I think, but you have to sign
an NDA to see the product map, which I have not done so have no clue as to
whats there. I personally think they may be waiting to pop right on the
market with available product as soon as Luminary announces what it has up
its sleeves. They seem to be in a tight heat with each other as far as
parts competition goes.

I agree its too bad that ST does not have a cortex part with Ethernet
though, as they are the lowest price chip on the market right now with the
STM32F103ZET6 (512K Flash, 64K RAM, CAN, USB, 8 timers, 4 of which are
capable of doing QEI, 2 of which are capable of doing motion PWM, 5
U(S)ARTS, 3 SPI, 2 I2C etc etc..... in an LQFP144) at $10.25 *IN SINGLES* at
AVNET.

I do not think that Luminary can compete with ST on price at the moment
because of process size (smaller process size means more dice per wafer
which means cheaper chips... but you already knew that :) Thats of course
assuming that ST uses a smaller process then Luminary does (Isn't Luminary
Fabless?).

One thing that has made me pro ST (besides the price) is that ST seems to
characterize the power consumption of their chips better then Luminary
does. They also seem to use less power then either Luminary or NXP parts at
the same clock. However, that may be misleading as the Luminary parts have
faster flash in them, so mips/watt may be less in the Luminary parts then in
the ST ones when running from Flash, but I have no data to back that up (or
dispute it).

>
> In reality, all the really cool chips are BGA, but those make QFPs
> look easy to prototype. There are companies selling products that
> claim to make prototyping with SMT parts easier, such as SchmartBoard,
> but I haven't tried them.
>

QFP's (and QFN's) *ARE* easy to prototype with, esp if you designed the part
footprint yourself. QFP's can be soldered in a jiffy with a rake soldering
technique, and when you get good at it you won't even need to use solder
braid to get the shorts out because there won't be any. QFN's take a little
bit longer (the ones with a thermal pad on the bottom are easier IMO because
you can fix them down with it) but are also a no brainer. I designed a
powersupply/LIPo charger with an LTC3556 USB power manager chip and hand
soldered it. First proto worked perfectly, no bridges or anything. It took
me 2-3 hrs to complete the soldering job, all by hand. My next protos will
hopefully be done by toaster method, but I need to build a controller
first. Its kinda hard to get the parts when your unemployed :P

I personally think that most peoples fears to soldering SMT parts is due to
them never having tried it. Before I first started using SMT in my designs
I thought the same thing. One day I just broke down and used some SMT parts
on a small design, one that would be ok to trash if I fudged it up.
Soldering the board was much much easier then I first thought, even the
QFP's! (It was an ATMega128 design). Since then I have never wanted to go
back to through hole parts, except for little pieces of free wired 'art'
that I have made. :)

>
> Still, ARM MCUs are getting down in size; the STM32F103T8 has 20K RAM,
> 64K flash in a 36 pin QFN. But to run Lua decently, you'll need at
> least a QFP80 (e.g. LPC1758 with 64K, ST STR911FAM4x with 96K SRAM).
> BTW, you always have to read the fine print; for example, in both the
> STR9 and LPC238x, the 96K SRAM is also used for the Ethernet buffers,
> so if you use the network, you won't actually have 96K available.

So very true. All of the large ram NXP parts are like that. They have a
64K main RAM area, and 2 16K buffer/DMA areas for the Ethernet and USB
controllers. Supposedly you can execute out of the DMA RAM, but I think
some of the parts have eratta related to that... And I would not hold my
breath on the NXP Cortex-M3 parts, it took over a year between when some of
the LPC24xx parts were 'released' and when they actually became available to
purchase in any real quantities. The LCD parts were the worst I believe,
just becoming available around 2 months or so ago.

>
> Compilers & DSPs: most DSPs need the manufacturer's compilers (I know
> TI's do); however, IIRC, the ADI Blackfin DSPs use gcc. Someday I may
> try compiling Lua for a TI C6701 board, but that's not going to happen
> for a while.
>
> CAN is a 1Mbps network, so there's no way a UART will work. You can
> add them externally, e.g. via a SPI port.

Meh, UARTS in some chips can go up to 4Mbps now. I do agree that using SPI
would be easier though, as Microchip has SPI->CAN bridge chips available.

>
> Finally, because this bugs me, some terminology notes:
> SoC - System on a Chip. So, a chip that integrates almost everything
> a piece of equipment (system) needs. A good example is a highly
> integrated chip for MP3 players.
> SiP - System on a Package.
> MCU - Microcontroller. A CPU that includes all its memory on chip.
> MCUs go back to the very early days, with such chips as the Intel
> 8042, before the term SoC was ever used.
> MPU - Microprocessor. A CPU that needs external memory (e.g. x86,
> Atmel AT91RM9200)
>
> If there really is enough interest, we should start thinking about
> starting a dedicated embedded processor Lua mailing list. Then we can
> go off topic without fear!

I agree 100%! I would love to continue this discussion.

========================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090212/12eea459/attachment.html

Asko Kauppi

eLua open hardware

Thanks, Bogdan, for arranging this and for doing the heavy work on
eLua itself.

I've asked Atmel to spare us some samples of their upcoming AT32UC3A3
chip. Hopefully we get full development kits, but maybe just chips.

Is there anyone else on the list that would have time and interest to
take up such a package? I am asking for two, and my thinking is we
could "shuffle" them among each other as need, interest and available
time varies. So they would be "jointly" owned by the eLua community.
Good or bad?

There does not seem to be much public info on this chip, yet.

Here is what an Atmel friend wrote (guess this is public, he did not
state otherwise):

> Would the AT32UC3A be a good alternative for a stamp.
> This has networking on the chip.
> Code can be developed using the JTAGICE Mk II, which
> I bet is available to many people.
> AVR32 Studio is an Eclipse environment working on both
> Windows & Linux which again is probably appreciated.
>
> We will soon have the AT32UC3A3 with high speed USB
> as well as SD-Card controller.
> Built for MP3. It also has more SRAM (128 kB).
> Mid year will be the UC3C which has CAN bus and
> lots of motor control features.
>
> How much code for a LUA interpreter?
> How many chips are needed?
> Maybe we can throw in some dataflashes as well.

Please say YEAH if you personally are interested. The RAM is arranged
in three partitions, one of which is for USB packages. The amount of
internal RAM should be the main interest for us here, I guess.

I've promised the Atmel guy that we'd craft an Application Note on how
to use Lua on this chip. I don't think that's too much to be asked,
and it would further the cause of eLua, anyhow.

- asko

Bogdan Marinescu kirjoitti 12.2.2009 kello 10:07:

> Hi all,
>
> There was recently a discussion on the Lua list about Lua on
> embedded devices, and thinks got pretty hot (in a good way :) ), so
> I invited all the people that wanted to continue that discussion to
> join this list (since the profile of the Lua list suggests that it's
> not the best place to discuss regular hardware). We had more than 10
> people joining the elua-dev list after this announcement, so I
> expect things to become pretty hot here too :) I'll try to resume
> the discussions by including the last relevent message from the Lua
> list (this message is from Mike Panetta):
>
> ========================================
>
> On Wed, Feb 11, 2009 at 12:22 PM, Tony Bauer <luatony at gmail.com>
> wrote:
> More embedded notes (with some Lua content):
>
> Yes, the LPC2478 is pretty nice. My brother was looking at using one
> at work (no Lua, though), but that project is currently on hold.
>
> Somebody will make a Cortex M3 with an external bus. The NXP LPC17xx
> series (Cortex M3) looks pretty nice; the LPC1768 has 64K RAM, 512K
> flash, MAC, USB OTG, 2xCAN, 4xUART, PWM, QEP, etc, but no external
> bus.
>
> I am willing to bet that either Luminary or ST Micro will be the
> first out the gate with such a design. In fact ST Micro has a new
> line of chips on the back burner to release some time this year I
> think, but you have to sign an NDA to see the product map, which I
> have not done so have no clue as to whats there. I personally think
> they may be waiting to pop right on the market with available
> product as soon as Luminary announces what it has up its sleeves.
> They seem to be in a tight heat with each other as far as parts
> competition goes.
>
> I agree its too bad that ST does not have a cortex part with
> Ethernet though, as they are the lowest price chip on the market
> right now with the STM32F103ZET6 (512K Flash, 64K RAM, CAN, USB, 8
> timers, 4 of which are capable of doing QEI, 2 of which are capable
> of doing motion PWM, 5 U(S)ARTS, 3 SPI, 2 I2C etc etc..... in an
> LQFP144) at $10.25 *IN SINGLES* at AVNET.
>
> I do not think that Luminary can compete with ST on price at the
> moment because of process size (smaller process size means more dice
> per wafer which means cheaper chips... but you already knew that :)
> Thats of course assuming that ST uses a smaller process then
> Luminary does (Isn't Luminary Fabless?).
>
> One thing that has made me pro ST (besides the price) is that ST
> seems to characterize the power consumption of their chips better
> then Luminary does. They also seem to use less power then either
> Luminary or NXP parts at the same clock. However, that may be
> misleading as the Luminary parts have faster flash in them, so mips/
> watt may be less in the Luminary parts then in the ST ones when
> running from Flash, but I have no data to back that up (or dispute
> it).
>
>
>
> In reality, all the really cool chips are BGA, but those make QFPs
> look easy to prototype. There are companies selling products that
> claim to make prototyping with SMT parts easier, such as SchmartBoard,
> but I haven't tried them.
>
> QFP's (and QFN's) *ARE* easy to prototype with, esp if you designed
> the part footprint yourself. QFP's can be soldered in a jiffy with a
> rake soldering technique, and when you get good at it you won't even
> need to use solder braid to get the shorts out because there won't
> be any. QFN's take a little bit longer (the ones with a thermal pad
> on the bottom are easier IMO because you can fix them down with it)
> but are also a no brainer. I designed a powersupply/LIPo charger
> with an LTC3556 USB power manager chip and hand soldered it. First
> proto worked perfectly, no bridges or anything. It took me 2-3 hrs
> to complete the soldering job, all by hand. My next protos will
> hopefully be done by toaster method, but I need to build a
> controller first. Its kinda hard to get the parts when your
> unemployed :P
>
> I personally think that most peoples fears to soldering SMT parts is
> due to them never having tried it. Before I first started using SMT
> in my designs I thought the same thing. One day I just broke down
> and used some SMT parts on a small design, one that would be ok to
> trash if I fudged it up. Soldering the board was much much easier
> then I first thought, even the QFP's! (It was an ATMega128 design).
> Since then I have never wanted to go back to through hole parts,
> except for little pieces of free wired 'art' that I have made. :)
>
>
>
> Still, ARM MCUs are getting down in size; the STM32F103T8 has 20K RAM,
> 64K flash in a 36 pin QFN. But to run Lua decently, you'll need at
> least a QFP80 (e.g. LPC1758 with 64K, ST STR911FAM4x with 96K SRAM).
> BTW, you always have to read the fine print; for example, in both the
> STR9 and LPC238x, the 96K SRAM is also used for the Ethernet buffers,
> so if you use the network, you won't actually have 96K available.
>
> So very true. All of the large ram NXP parts are like that. They
> have a 64K main RAM area, and 2 16K buffer/DMA areas for the
> Ethernet and USB controllers. Supposedly you can execute out of the
> DMA RAM, but I think some of the parts have eratta related to
> that... And I would not hold my breath on the NXP Cortex-M3 parts,
> it took over a year between when some of the LPC24xx parts were
> 'released' and when they actually became available to purchase in
> any real quantities. The LCD parts were the worst I believe, just
> becoming available around 2 months or so ago.
>
>
>
> Compilers & DSPs: most DSPs need the manufacturer's compilers (I know
> TI's do); however, IIRC, the ADI Blackfin DSPs use gcc. Someday I may
> try compiling Lua for a TI C6701 board, but that's not going to happen
> for a while.
>
> CAN is a 1Mbps network, so there's no way a UART will work. You can
> add them externally, e.g. via a SPI port.
>
> Meh, UARTS in some chips can go up to 4Mbps now. I do agree that
> using SPI would be easier though, as Microchip has SPI->CAN bridge
> chips available.
>
>
>
> Finally, because this bugs me, some terminology notes:
> SoC - System on a Chip. So, a chip that integrates almost everything
> a piece of equipment (system) needs. A good example is a highly
> integrated chip for MP3 players.
> SiP - System on a Package.
> MCU - Microcontroller. A CPU that includes all its memory on chip.
> MCUs go back to the very early days, with such chips as the Intel
> 8042, before the term SoC was ever used.
> MPU - Microprocessor. A CPU that needs external memory (e.g. x86,
> Atmel AT91RM9200)
>
> If there really is enough interest, we should start thinking about
> starting a dedicated embedded processor Lua mailing list. Then we can
> go off topic without fear!
>
> I agree 100%! I would love to continue this discussion.
>
> ========================================
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev

BogdanM

eLua open hardware

In reply to this post by BogdanM

> I am willing to bet that either Luminary or ST Micro will be the first out
> the gate with such a design. In fact ST Micro has a new line of chips on
> the back burner to release some time this year I think, but you have to sign
> an NDA to see the product map, which I have not done so have no clue as to
> whats there.
>

The same thing happened to me with Luminary; they acknowledge the plans for
Cortex MCUs with external memory bus, but they want an NDA to be signed if
you want more details. I tried that, but couldn't get my hands on the NDA
for some reason. In any case, the future does indeed look promising with
these Cortex MCUs.

I personally think that most peoples fears to soldering SMT parts is due to
> them never having tried it. Before I first started using SMT in my designs
> I thought the same thing. One day I just broke down and used some SMT parts
> on a small design, one that would be ok to trash if I fudged it up.
> Soldering the board was much much easier then I first thought, even the
> QFP's! (It was an ATMega128 design). Since then I have never wanted to go
> back to through hole parts, except for little pieces of free wired 'art'
> that I have made. :)
>

You're one of the lucky ones, I never seem to get along with QFPs properly.
But I probably just need a bit more training :)

>
>
>>
>> Still, ARM MCUs are getting down in size; the STM32F103T8 has 20K RAM,
>> 64K flash in a 36 pin QFN. But to run Lua decently, you'll need at
>> least a QFP80 (e.g. LPC1758 with 64K, ST STR911FAM4x with 96K SRAM).
>> BTW, you always have to read the fine print; for example, in both the
>> STR9 and LPC238x, the 96K SRAM is also used for the Ethernet buffers,
>> so if you use the network, you won't actually have 96K available.
>
>

Wow. I knew about the Cortex parts from NXP, just didn't expect to see them
on the market so fast (well, not exactly on the market, since nobody seems
to stock them, but I bet they're getting there). LPC17xx operates at 100MHz,
something that can certainly gain my respect :) and I'm sure things will
only get better from this point.

> So very true. All of the large ram NXP parts are like that. They have a
> 64K main RAM area, and 2 16K buffer/DMA areas for the Ethernet and USB
> controllers. Supposedly you can execute out of the DMA RAM, but I think
> some of the parts have eratta related to that... And I would not hold my
> breath on the NXP Cortex-M3 parts, it took over a year between when some of
> the LPC24xx parts were 'released' and when they actually became available to
> purchase in any real quantities. The LCD parts were the worst I believe,
> just becoming available around 2 months or so ago.
>

This is sad, but Atmel (for example) has problems that are even worse IMO,
since some of their products are virtually impossible to find. Try buying
certain models of AVR32 chips; basically there aren't stocked anywhere, and
the factory lead time period is huge. Same thing for AT91SAM parts with 512k
of Flash and 128k of RAM, I found it almost impossible to get them.

I agree 100%! I would love to continue this discussion.

So, people ... what would be your ideal MPU for an open source eLua stamp?
Right now, my money (sort of speaking :) ) is with the STR912FAW44 chip from
ST (http://www.st.com/mcu/devicedocs-STR912FAW44.html). Why is that?

- ARM9 architecture core (the huge majority of ARM-based MCUs out there are
ARM7) that can be clocked at 96MHz (which, needless to say, is Very Good).
- 512k Flash / 96k RAM internal (which is plenty)
- external memory interface ((P)SRAM, not SDRAM, which is good enough).
- Ethernet/USB/CAN besides the "usual" interfaces
- very flexible, software selectable peripheral-to-pin assignment
- very small package (important for a stamp): LQFP128 at 14x14mm (although
this means a pin pitch less than 0.5mm, but someone more skilled than me
could probably solder it instantly :) ).

This preference will probably change if a Cortex core with both external
memory and built-in Ethernet (preferably the built-in Ethernet from
Luminary, cause that includes both MAC AND PHY on-chip) appears on the
market, but until then this is my chip of choice. Ideally the PCB would
include space for an external memory (probably SRAM, since PSRAM comes only
in BGA packages, which adds a lot to the manufacturing complexity) that
would be _optionally_ equipped with an external SRAM (up to 1Mbyte SRAM,
that should be quite enough, although we might stop at 512kbyte or even
256kbyte for most applications).

Allright, let's see what you got now :)

Best,
Bogdan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090212/2a218490/attachment-0001.html

BogdanM

eLua open hardware

In reply to this post by Asko Kauppi

> I've asked Atmel to spare us some samples of their upcoming AT32UC3A3
> chip. Hopefully we get full development kits, but maybe just chips.

They're probably some very "secret" chips yet, I don't even see them on
their AVR32 device list page.

> Is there anyone else on the list that would have time and interest to
> take up such a package? I am asking for two, and my thinking is we
> could "shuffle" them among each other as need, interest and available
> time varies. So they would be "jointly" owned by the eLua community.
> Good or bad?

Good, I think :)

> There does not seem to be much public info on this chip, yet.
>
> Here is what an Atmel friend wrote (guess this is public, he did not
> state otherwise):
>
> > Would the AT32UC3A be a good alternative for a stamp.
> > This has networking on the chip.
> > Code can be developed using the JTAGICE Mk II, which
> > I bet is available to many people.

Well, it turns out that (surprisingly :) ) there aren't that many people
with access to a JTAGICE. The AVR32 I'm working with has a DFU mode for
software uploading, I guess they'll keep it in the new chips too, so this is
fine, cause all you need to program it is an USB cable and the software from
Atmel (which runs equally well on Windows and Linux).

> > We will soon have the AT32UC3A3 with high speed USB
> > as well as SD-Card controller.
> > Built for MP3. It also has more SRAM (128 kB).

128k of intermal SRAM is a Very Very Good Thing for eLua :)

Please say YEAH if you personally are interested.

YEAH !!!! :)

> I've promised the Atmel guy that we'd craft an Application Note on how
> to use Lua on this chip. I don't think that's too much to be asked,
> and it would further the cause of eLua, anyhow.

Sure, this would benefit everybody. I'll write the appnote if we get
somewhere with this.

Best,
Bogdan

>
>
> - asko
>
>
>
> Bogdan Marinescu kirjoitti 12.2.2009 kello 10:07:
>
> > Hi all,
> >
> > There was recently a discussion on the Lua list about Lua on
> > embedded devices, and thinks got pretty hot (in a good way :) ), so
> > I invited all the people that wanted to continue that discussion to
> > join this list (since the profile of the Lua list suggests that it's
> > not the best place to discuss regular hardware). We had more than 10
> > people joining the elua-dev list after this announcement, so I
> > expect things to become pretty hot here too :) I'll try to resume
> > the discussions by including the last relevent message from the Lua
> > list (this message is from Mike Panetta):
> >
> > ========================================
> >
> > On Wed, Feb 11, 2009 at 12:22 PM, Tony Bauer <luatony at gmail.com>
> > wrote:
> > More embedded notes (with some Lua content):
> >
> > Yes, the LPC2478 is pretty nice. My brother was looking at using one
> > at work (no Lua, though), but that project is currently on hold.
> >
> > Somebody will make a Cortex M3 with an external bus. The NXP LPC17xx
> > series (Cortex M3) looks pretty nice; the LPC1768 has 64K RAM, 512K
> > flash, MAC, USB OTG, 2xCAN, 4xUART, PWM, QEP, etc, but no external
> > bus.
> >
> > I am willing to bet that either Luminary or ST Micro will be the
> > first out the gate with such a design. In fact ST Micro has a new
> > line of chips on the back burner to release some time this year I
> > think, but you have to sign an NDA to see the product map, which I
> > have not done so have no clue as to whats there. I personally think
> > they may be waiting to pop right on the market with available
> > product as soon as Luminary announces what it has up its sleeves.
> > They seem to be in a tight heat with each other as far as parts
> > competition goes.
> >
> > I agree its too bad that ST does not have a cortex part with
> > Ethernet though, as they are the lowest price chip on the market
> > right now with the STM32F103ZET6 (512K Flash, 64K RAM, CAN, USB, 8
> > timers, 4 of which are capable of doing QEI, 2 of which are capable
> > of doing motion PWM, 5 U(S)ARTS, 3 SPI, 2 I2C etc etc..... in an
> > LQFP144) at $10.25 *IN SINGLES* at AVNET.
> >
> > I do not think that Luminary can compete with ST on price at the
> > moment because of process size (smaller process size means more dice
> > per wafer which means cheaper chips... but you already knew that :)
> > Thats of course assuming that ST uses a smaller process then
> > Luminary does (Isn't Luminary Fabless?).
> >
> > One thing that has made me pro ST (besides the price) is that ST
> > seems to characterize the power consumption of their chips better
> > then Luminary does. They also seem to use less power then either
> > Luminary or NXP parts at the same clock. However, that may be
> > misleading as the Luminary parts have faster flash in them, so mips/
> > watt may be less in the Luminary parts then in the ST ones when
> > running from Flash, but I have no data to back that up (or dispute
> > it).
> >
> >
> >
> > In reality, all the really cool chips are BGA, but those make QFPs
> > look easy to prototype. There are companies selling products that
> > claim to make prototyping with SMT parts easier, such as SchmartBoard,
> > but I haven't tried them.
> >
> > QFP's (and QFN's) *ARE* easy to prototype with, esp if you designed
> > the part footprint yourself. QFP's can be soldered in a jiffy with a
> > rake soldering technique, and when you get good at it you won't even
> > need to use solder braid to get the shorts out because there won't
> > be any. QFN's take a little bit longer (the ones with a thermal pad
> > on the bottom are easier IMO because you can fix them down with it)
> > but are also a no brainer. I designed a powersupply/LIPo charger
> > with an LTC3556 USB power manager chip and hand soldered it. First
> > proto worked perfectly, no bridges or anything. It took me 2-3 hrs
> > to complete the soldering job, all by hand. My next protos will
> > hopefully be done by toaster method, but I need to build a
> > controller first. Its kinda hard to get the parts when your
> > unemployed :P
> >
> > I personally think that most peoples fears to soldering SMT parts is
> > due to them never having tried it. Before I first started using SMT
> > in my designs I thought the same thing. One day I just broke down
> > and used some SMT parts on a small design, one that would be ok to
> > trash if I fudged it up. Soldering the board was much much easier
> > then I first thought, even the QFP's! (It was an ATMega128 design).
> > Since then I have never wanted to go back to through hole parts,
> > except for little pieces of free wired 'art' that I have made. :)
> >
> >
> >
> > Still, ARM MCUs are getting down in size; the STM32F103T8 has 20K RAM,
> > 64K flash in a 36 pin QFN. But to run Lua decently, you'll need at
> > least a QFP80 (e.g. LPC1758 with 64K, ST STR911FAM4x with 96K SRAM).
> > BTW, you always have to read the fine print; for example, in both the
> > STR9 and LPC238x, the 96K SRAM is also used for the Ethernet buffers,
> > so if you use the network, you won't actually have 96K available.
> >
> > So very true. All of the large ram NXP parts are like that. They
> > have a 64K main RAM area, and 2 16K buffer/DMA areas for the
> > Ethernet and USB controllers. Supposedly you can execute out of the
> > DMA RAM, but I think some of the parts have eratta related to
> > that... And I would not hold my breath on the NXP Cortex-M3 parts,
> > it took over a year between when some of the LPC24xx parts were
> > 'released' and when they actually became available to purchase in
> > any real quantities. The LCD parts were the worst I believe, just
> > becoming available around 2 months or so ago.
> >
> >
> >
> > Compilers & DSPs: most DSPs need the manufacturer's compilers (I know
> > TI's do); however, IIRC, the ADI Blackfin DSPs use gcc. Someday I may
> > try compiling Lua for a TI C6701 board, but that's not going to happen
> > for a while.
> >
> > CAN is a 1Mbps network, so there's no way a UART will work. You can
> > add them externally, e.g. via a SPI port.
> >
> > Meh, UARTS in some chips can go up to 4Mbps now. I do agree that
> > using SPI would be easier though, as Microchip has SPI->CAN bridge
> > chips available.
> >
> >
> >
> > Finally, because this bugs me, some terminology notes:
> > SoC - System on a Chip. So, a chip that integrates almost everything
> > a piece of equipment (system) needs. A good example is a highly
> > integrated chip for MP3 players.
> > SiP - System on a Package.
> > MCU - Microcontroller. A CPU that includes all its memory on chip.
> > MCUs go back to the very early days, with such chips as the Intel
> > 8042, before the term SoC was ever used.
> > MPU - Microprocessor. A CPU that needs external memory (e.g. x86,
> > Atmel AT91RM9200)
> >
> > If there really is enough interest, we should start thinking about
> > starting a dedicated embedded processor Lua mailing list. Then we can
> > go off topic without fear!
> >
> > I agree 100%! I would love to continue this discussion.
> >
> > ========================================
> >
> >
> > _______________________________________________
> > Elua-dev mailing list
> > Elua-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/elua-dev
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090212/8354959f/attachment.html

BogdanM

eLua open hardware

And on a related topic: on the Lua list I've seen some people that want Lua
support on much "lower end" architectures, like 8-bit MCUs. As I see it
right now, the way to go with this is to have a completely rewritten VM
interpreter (probably with lots of restrictions) that would be able to run
on these machines. But I'm curious, how many people would like to have even
a (quite) restricted Lua running on low-to-medium end 8/16-bit MCUs (with
little Flash and RAM resources)?

Best,
Bogdan

On Thu, Feb 12, 2009 at 10:45 AM, Bogdan Marinescu <
bogdan.marinescu at gmail.com> wrote:

>
> I've asked Atmel to spare us some samples of their upcoming AT32UC3A3
>> chip. Hopefully we get full development kits, but maybe just chips.
>
>
> They're probably some very "secret" chips yet, I don't even see them on
> their AVR32 device list page.
>
>
>> Is there anyone else on the list that would have time and interest to
>> take up such a package? I am asking for two, and my thinking is we
>> could "shuffle" them among each other as need, interest and available
>> time varies. So they would be "jointly" owned by the eLua community.
>> Good or bad?
>
>
> Good, I think :)
>
>
>> There does not seem to be much public info on this chip, yet.
>>
>> Here is what an Atmel friend wrote (guess this is public, he did not
>> state otherwise):
>>
>> > Would the AT32UC3A be a good alternative for a stamp.
>> > This has networking on the chip.
>> > Code can be developed using the JTAGICE Mk II, which
>> > I bet is available to many people.
>
>
> Well, it turns out that (surprisingly :) ) there aren't that many people
> with access to a JTAGICE. The AVR32 I'm working with has a DFU mode for
> software uploading, I guess they'll keep it in the new chips too, so this is
> fine, cause all you need to program it is an USB cable and the software from
> Atmel (which runs equally well on Windows and Linux).
>
>
>> > We will soon have the AT32UC3A3 with high speed USB
>> > as well as SD-Card controller.
>> > Built for MP3. It also has more SRAM (128 kB).
>
>
> 128k of intermal SRAM is a Very Very Good Thing for eLua :)
>
> Please say YEAH if you personally are interested.
>
>
> YEAH !!!! :)
>
>
>> I've promised the Atmel guy that we'd craft an Application Note on how
>> to use Lua on this chip. I don't think that's too much to be asked,
>> and it would further the cause of eLua, anyhow.
>
>
> Sure, this would benefit everybody. I'll write the appnote if we get
> somewhere with this.
>
> Best,
> Bogdan
>
>
>>
>>
>> - asko
>>
>>
>>
>> Bogdan Marinescu kirjoitti 12.2.2009 kello 10:07:
>>
>> > Hi all,
>> >
>> > There was recently a discussion on the Lua list about Lua on
>> > embedded devices, and thinks got pretty hot (in a good way :) ), so
>> > I invited all the people that wanted to continue that discussion to
>> > join this list (since the profile of the Lua list suggests that it's
>> > not the best place to discuss regular hardware). We had more than 10
>> > people joining the elua-dev list after this announcement, so I
>> > expect things to become pretty hot here too :) I'll try to resume
>> > the discussions by including the last relevent message from the Lua
>> > list (this message is from Mike Panetta):
>> >
>> > ========================================
>> >
>> > On Wed, Feb 11, 2009 at 12:22 PM, Tony Bauer <luatony at gmail.com>
>> > wrote:
>> > More embedded notes (with some Lua content):
>> >
>> > Yes, the LPC2478 is pretty nice. My brother was looking at using one
>> > at work (no Lua, though), but that project is currently on hold.
>> >
>> > Somebody will make a Cortex M3 with an external bus. The NXP LPC17xx
>> > series (Cortex M3) looks pretty nice; the LPC1768 has 64K RAM, 512K
>> > flash, MAC, USB OTG, 2xCAN, 4xUART, PWM, QEP, etc, but no external
>> > bus.
>> >
>> > I am willing to bet that either Luminary or ST Micro will be the
>> > first out the gate with such a design. In fact ST Micro has a new
>> > line of chips on the back burner to release some time this year I
>> > think, but you have to sign an NDA to see the product map, which I
>> > have not done so have no clue as to whats there. I personally think
>> > they may be waiting to pop right on the market with available
>> > product as soon as Luminary announces what it has up its sleeves.
>> > They seem to be in a tight heat with each other as far as parts
>> > competition goes.
>> >
>> > I agree its too bad that ST does not have a cortex part with
>> > Ethernet though, as they are the lowest price chip on the market
>> > right now with the STM32F103ZET6 (512K Flash, 64K RAM, CAN, USB, 8
>> > timers, 4 of which are capable of doing QEI, 2 of which are capable
>> > of doing motion PWM, 5 U(S)ARTS, 3 SPI, 2 I2C etc etc..... in an
>> > LQFP144) at $10.25 *IN SINGLES* at AVNET.
>> >
>> > I do not think that Luminary can compete with ST on price at the
>> > moment because of process size (smaller process size means more dice
>> > per wafer which means cheaper chips... but you already knew that :)
>> > Thats of course assuming that ST uses a smaller process then
>> > Luminary does (Isn't Luminary Fabless?).
>> >
>> > One thing that has made me pro ST (besides the price) is that ST
>> > seems to characterize the power consumption of their chips better
>> > then Luminary does. They also seem to use less power then either
>> > Luminary or NXP parts at the same clock. However, that may be
>> > misleading as the Luminary parts have faster flash in them, so mips/
>> > watt may be less in the Luminary parts then in the ST ones when
>> > running from Flash, but I have no data to back that up (or dispute
>> > it).
>> >
>> >
>> >
>> > In reality, all the really cool chips are BGA, but those make QFPs
>> > look easy to prototype. There are companies selling products that
>> > claim to make prototyping with SMT parts easier, such as SchmartBoard,
>> > but I haven't tried them.
>> >
>> > QFP's (and QFN's) *ARE* easy to prototype with, esp if you designed
>> > the part footprint yourself. QFP's can be soldered in a jiffy with a
>> > rake soldering technique, and when you get good at it you won't even
>> > need to use solder braid to get the shorts out because there won't
>> > be any. QFN's take a little bit longer (the ones with a thermal pad
>> > on the bottom are easier IMO because you can fix them down with it)
>> > but are also a no brainer. I designed a powersupply/LIPo charger
>> > with an LTC3556 USB power manager chip and hand soldered it. First
>> > proto worked perfectly, no bridges or anything. It took me 2-3 hrs
>> > to complete the soldering job, all by hand. My next protos will
>> > hopefully be done by toaster method, but I need to build a
>> > controller first. Its kinda hard to get the parts when your
>> > unemployed :P
>> >
>> > I personally think that most peoples fears to soldering SMT parts is
>> > due to them never having tried it. Before I first started using SMT
>> > in my designs I thought the same thing. One day I just broke down
>> > and used some SMT parts on a small design, one that would be ok to
>> > trash if I fudged it up. Soldering the board was much much easier
>> > then I first thought, even the QFP's! (It was an ATMega128 design).
>> > Since then I have never wanted to go back to through hole parts,
>> > except for little pieces of free wired 'art' that I have made. :)
>> >
>> >
>> >
>> > Still, ARM MCUs are getting down in size; the STM32F103T8 has 20K RAM,
>> > 64K flash in a 36 pin QFN. But to run Lua decently, you'll need at
>> > least a QFP80 (e.g. LPC1758 with 64K, ST STR911FAM4x with 96K SRAM).
>> > BTW, you always have to read the fine print; for example, in both the
>> > STR9 and LPC238x, the 96K SRAM is also used for the Ethernet buffers,
>> > so if you use the network, you won't actually have 96K available.
>> >
>> > So very true. All of the large ram NXP parts are like that. They
>> > have a 64K main RAM area, and 2 16K buffer/DMA areas for the
>> > Ethernet and USB controllers. Supposedly you can execute out of the
>> > DMA RAM, but I think some of the parts have eratta related to
>> > that... And I would not hold my breath on the NXP Cortex-M3 parts,
>> > it took over a year between when some of the LPC24xx parts were
>> > 'released' and when they actually became available to purchase in
>> > any real quantities. The LCD parts were the worst I believe, just
>> > becoming available around 2 months or so ago.
>> >
>> >
>> >
>> > Compilers & DSPs: most DSPs need the manufacturer's compilers (I know
>> > TI's do); however, IIRC, the ADI Blackfin DSPs use gcc. Someday I may
>> > try compiling Lua for a TI C6701 board, but that's not going to happen
>> > for a while.
>> >
>> > CAN is a 1Mbps network, so there's no way a UART will work. You can
>> > add them externally, e.g. via a SPI port.
>> >
>> > Meh, UARTS in some chips can go up to 4Mbps now. I do agree that
>> > using SPI would be easier though, as Microchip has SPI->CAN bridge
>> > chips available.
>> >
>> >
>> >
>> > Finally, because this bugs me, some terminology notes:
>> > SoC - System on a Chip. So, a chip that integrates almost everything
>> > a piece of equipment (system) needs. A good example is a highly
>> > integrated chip for MP3 players.
>> > SiP - System on a Package.
>> > MCU - Microcontroller. A CPU that includes all its memory on chip.
>> > MCUs go back to the very early days, with such chips as the Intel
>> > 8042, before the term SoC was ever used.
>> > MPU - Microprocessor. A CPU that needs external memory (e.g. x86,
>> > Atmel AT91RM9200)
>> >
>> > If there really is enough interest, we should start thinking about
>> > starting a dedicated embedded processor Lua mailing list. Then we can
>> > go off topic without fear!
>> >
>> > I agree 100%! I would love to continue this discussion.
>> >
>> > ========================================
>> >
>> >
>> > _______________________________________________
>> > Elua-dev mailing list
>> > Elua-dev at lists.berlios.de
>> > https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>> _______________________________________________
>> Elua-dev mailing list
>> Elua-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090212/badbcc2f/attachment.html

Asko Kauppi

eLua open hardware

I would not be interested in a crippled 8/16 bit Lua.

It easily becomes a completely separate (sub)language, and
I would see our efforts be best placed within the
"constraints" of modern, full Lua.

The approach of generating C or assembly language based on
a Lua script is however a decent one. Lua is a
magnificient preprocessing language, imho. I would i.e.
LOVE to design VHDL's using Lua as the description
language (now, that's constraints, isn't it?). :)

-asko

On Thu, 12 Feb 2009 13:11:14 +0200
Bogdan Marinescu <bogdan.marinescu at gmail.com> wrote:

> And on a related topic: on the Lua list I've seen some
>people that want Lua
> support on much "lower end" architectures, like 8-bit
>MCUs. As I see it
> right now, the way to go with this is to have a
>completely rewritten VM
> interpreter (probably with lots of restrictions) that
>would be able to run
> on these machines. But I'm curious, how many people
>would like to have even
> a (quite) restricted Lua running on low-to-medium end
>8/16-bit MCUs (with
> little Flash and RAM resources)?
>
> Best,
> Bogdan
>
> On Thu, Feb 12, 2009 at 10:45 AM, Bogdan Marinescu <
> bogdan.marinescu at gmail.com> wrote:
>
>>
>> I've asked Atmel to spare us some samples of their
>>upcoming AT32UC3A3
>>> chip. Hopefully we get full development kits, but maybe
>>>just chips.
>>
>>
>> They're probably some very "secret" chips yet, I don't
>>even see them on
>> their AVR32 device list page.
>>
>>
>>> Is there anyone else on the list that would have time
>>>and interest to
>>> take up such a package? I am asking for two, and my
>>>thinking is we
>>> could "shuffle" them among each other as need, interest
>>>and available
>>> time varies. So they would be "jointly" owned by the
>>>eLua community.
>>> Good or bad?
>>
>>
>> Good, I think :)
>>
>>
>>> There does not seem to be much public info on this chip,
>>>yet.
>>>
>>> Here is what an Atmel friend wrote (guess this is
>>>public, he did not
>>> state otherwise):
>>>
>>> > Would the AT32UC3A be a good alternative for a stamp.
>>> > This has networking on the chip.
>>> > Code can be developed using the JTAGICE Mk II, which
>>> > I bet is available to many people.
>>
>>
>> Well, it turns out that (surprisingly :) ) there aren't
>>that many people
>> with access to a JTAGICE. The AVR32 I'm working with has
>>a DFU mode for
>> software uploading, I guess they'll keep it in the new
>>chips too, so this is
>> fine, cause all you need to program it is an USB cable
>>and the software from
>> Atmel (which runs equally well on Windows and Linux).
>>
>>
>>> > We will soon have the AT32UC3A3 with high speed USB
>>> > as well as SD-Card controller.
>>> > Built for MP3. It also has more SRAM (128 kB).
>>
>>
>> 128k of intermal SRAM is a Very Very Good Thing for eLua
>>:)
>>
>> Please say YEAH if you personally are interested.
>>
>>
>> YEAH !!!! :)
>>
>>
>>> I've promised the Atmel guy that we'd craft an
>>>Application Note on how
>>> to use Lua on this chip. I don't think that's too much
>>>to be asked,
>>> and it would further the cause of eLua, anyhow.
>>
>>
>> Sure, this would benefit everybody. I'll write the
>>appnote if we get
>> somewhere with this.
>>
>> Best,
>> Bogdan
>>
>>
>>>
>>>
>>> - asko
>>>
>>>
>>>
>>> Bogdan Marinescu kirjoitti 12.2.2009 kello 10:07:
>>>
>>> > Hi all,
>>> >
>>> > There was recently a discussion on the Lua list about
>>>Lua on
>>> > embedded devices, and thinks got pretty hot (in a good
>>>way :) ), so
>>> > I invited all the people that wanted to continue that
>>>discussion to
>>> > join this list (since the profile of the Lua list
>>>suggests that it's
>>> > not the best place to discuss regular hardware). We
>>>had more than 10
>>> > people joining the elua-dev list after this
>>>announcement, so I
>>> > expect things to become pretty hot here too :) I'll
>>>try to resume
>>> > the discussions by including the last relevent message
>>>from the Lua
>>> > list (this message is from Mike Panetta):
>>> >
>>> > ========================================
>>> >
>>> > On Wed, Feb 11, 2009 at 12:22 PM, Tony Bauer
>>><luatony at gmail.com>
>>> > wrote:
>>> > More embedded notes (with some Lua content):
>>> >
>>> > Yes, the LPC2478 is pretty nice. My brother was
>>>looking at using one
>>> > at work (no Lua, though), but that project is
>>>currently on hold.
>>> >
>>> > Somebody will make a Cortex M3 with an external bus.
>>> The NXP LPC17xx
>>> > series (Cortex M3) looks pretty nice; the LPC1768 has
>>>64K RAM, 512K
>>> > flash, MAC, USB OTG, 2xCAN, 4xUART, PWM, QEP, etc, but
>>>no external
>>> > bus.
>>> >
>>> > I am willing to bet that either Luminary or ST Micro
>>>will be the
>>> > first out the gate with such a design. In fact ST
>>>Micro has a new
>>> > line of chips on the back burner to release some time
>>>this year I
>>> > think, but you have to sign an NDA to see the product
>>>map, which I
>>> > have not done so have no clue as to whats there. I
>>>personally think
>>> > they may be waiting to pop right on the market with
>>>available
>>> > product as soon as Luminary announces what it has up
>>>its sleeves.
>>> > They seem to be in a tight heat with each other as far
>>>as parts
>>> > competition goes.
>>> >
>>> > I agree its too bad that ST does not have a cortex
>>>part with
>>> > Ethernet though, as they are the lowest price chip on
>>>the market
>>> > right now with the STM32F103ZET6 (512K Flash, 64K RAM,
>>>CAN, USB, 8
>>> > timers, 4 of which are capable of doing QEI, 2 of
>>>which are capable
>>> > of doing motion PWM, 5 U(S)ARTS, 3 SPI, 2 I2C etc
>>>etc..... in an
>>> > LQFP144) at $10.25 *IN SINGLES* at AVNET.
>>> >
>>> > I do not think that Luminary can compete with ST on
>>>price at the
>>> > moment because of process size (smaller process size
>>>means more dice
>>> > per wafer which means cheaper chips... but you already
>>>knew that :)
>>> > Thats of course assuming that ST uses a smaller
>>>process then
>>> > Luminary does (Isn't Luminary Fabless?).
>>> >
>>> > One thing that has made me pro ST (besides the price)
>>>is that ST
>>> > seems to characterize the power consumption of their
>>>chips better
>>> > then Luminary does. They also seem to use less power
>>>then either
>>> > Luminary or NXP parts at the same clock. However,
>>>that may be
>>> > misleading as the Luminary parts have faster flash in
>>>them, so mips/
>>> > watt may be less in the Luminary parts then in the ST
>>>ones when
>>> > running from Flash, but I have no data to back that up
>>>(or dispute
>>> > it).
>>> >
>>> >
>>> >
>>> > In reality, all the really cool chips are BGA, but
>>>those make QFPs
>>> > look easy to prototype. There are companies selling
>>>products that
>>> > claim to make prototyping with SMT parts easier, such
>>>as SchmartBoard,
>>> > but I haven't tried them.
>>> >
>>> > QFP's (and QFN's) *ARE* easy to prototype with, esp if
>>>you designed
>>> > the part footprint yourself. QFP's can be soldered in
>>>a jiffy with a
>>> > rake soldering technique, and when you get good at it
>>>you won't even
>>> > need to use solder braid to get the shorts out because
>>>there won't
>>> > be any. QFN's take a little bit longer (the ones with
>>>a thermal pad
>>> > on the bottom are easier IMO because you can fix them
>>>down with it)
>>> > but are also a no brainer. I designed a
>>>powersupply/LIPo charger
>>> > with an LTC3556 USB power manager chip and hand
>>>soldered it. First
>>> > proto worked perfectly, no bridges or anything. It
>>>took me 2-3 hrs
>>> > to complete the soldering job, all by hand. My next
>>>protos will
>>> > hopefully be done by toaster method, but I need to
>>>build a
>>> > controller first. Its kinda hard to get the parts
>>>when your
>>> > unemployed :P
>>> >
>>> > I personally think that most peoples fears to
>>>soldering SMT parts is
>>> > due to them never having tried it. Before I first
>>>started using SMT
>>> > in my designs I thought the same thing. One day I
>>>just broke down
>>> > and used some SMT parts on a small design, one that
>>>would be ok to
>>> > trash if I fudged it up. Soldering the board was much
>>>much easier
>>> > then I first thought, even the QFP's! (It was an
>>>ATMega128 design).
>>> > Since then I have never wanted to go back to through
>>>hole parts,
>>> > except for little pieces of free wired 'art' that I
>>>have made. :)
>>> >
>>> >
>>> >
>>> > Still, ARM MCUs are getting down in size; the
>>>STM32F103T8 has 20K RAM,
>>> > 64K flash in a 36 pin QFN. But to run Lua decently,
>>>you'll need at
>>> > least a QFP80 (e.g. LPC1758 with 64K, ST STR911FAM4x
>>>with 96K SRAM).
>>> > BTW, you always have to read the fine print; for
>>>example, in both the
>>> > STR9 and LPC238x, the 96K SRAM is also used for the
>>>Ethernet buffers,
>>> > so if you use the network, you won't actually have 96K
>>>available.
>>> >
>>> > So very true. All of the large ram NXP parts are like
>>>that. They
>>> > have a 64K main RAM area, and 2 16K buffer/DMA areas
>>>for the
>>> > Ethernet and USB controllers. Supposedly you can
>>>execute out of the
>>> > DMA RAM, but I think some of the parts have eratta
>>>related to
>>> > that... And I would not hold my breath on the NXP
>>>Cortex-M3 parts,
>>> > it took over a year between when some of the LPC24xx
>>>parts were
>>> > 'released' and when they actually became available to
>>>purchase in
>>> > any real quantities. The LCD parts were the worst I
>>>believe, just
>>> > becoming available around 2 months or so ago.
>>> >
>>> >
>>> >
>>> > Compilers & DSPs: most DSPs need the manufacturer's
>>>compilers (I know
>>> > TI's do); however, IIRC, the ADI Blackfin DSPs use
>>>gcc. Someday I may
>>> > try compiling Lua for a TI C6701 board, but that's not
>>>going to happen
>>> > for a while.
>>> >
>>> > CAN is a 1Mbps network, so there's no way a UART will
>>>work. You can
>>> > add them externally, e.g. via a SPI port.
>>> >
>>> > Meh, UARTS in some chips can go up to 4Mbps now. I do
>>>agree that
>>> > using SPI would be easier though, as Microchip has
>>>SPI->CAN bridge
>>> > chips available.
>>> >
>>> >
>>> >
>>> > Finally, because this bugs me, some terminology notes:
>>> > SoC - System on a Chip. So, a chip that integrates
>>>almost everything
>>> > a piece of equipment (system) needs. A good example
>>>is a highly
>>> > integrated chip for MP3 players.
>>> > SiP - System on a Package.
>>> > MCU - Microcontroller. A CPU that includes all its
>>>memory on chip.
>>> > MCUs go back to the very early days, with such chips
>>>as the Intel
>>> > 8042, before the term SoC was ever used.
>>> > MPU - Microprocessor. A CPU that needs external
>>>memory (e.g. x86,
>>> > Atmel AT91RM9200)
>>> >
>>> > If there really is enough interest, we should start
>>>thinking about
>>> > starting a dedicated embedded processor Lua mailing
>>>list. Then we can
>>> > go off topic without fear!
>>> >
>>> > I agree 100%! I would love to continue this
>>>discussion.
>>> >
>>> > ========================================
>>> >
>>> >
>>> > _______________________________________________
>>> > Elua-dev mailing list
>>> > Elua-dev at lists.berlios.de
>>> > https://lists.berlios.de/mailman/listinfo/elua-dev
>>>
>>> _______________________________________________
>>> Elua-dev mailing list
>>> Elua-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/elua-dev
>>>
>>
>>

John Hind

eLua open hardware

In reply to this post by BogdanM

Hi everyone! I am one of the aforementioned refugees from the Lua list, in
fact I think it was my posting that got everyone talking about
microcontrollers and LuaChips again. I was about to launch my own LuaChip
project as a search had revealed nothing existing except the pbLua port to
the Lego controller, then Bogdan pointed me to the whole existing world of
eLua - not sure if eLua is especially low key or if my search abilities need
honing!

I'd like to help in any way towards a target of getting something like the
Arduino infrastructure, but based on Lua, 32bit and network capability,
available to purchase. This means that for a few tens of dollars I could buy
a small pre-built card that I can plug into a PC (Windows, Linux and perhaps
OSX) via USB and immediately start programming in Lua. The processor needs
to come with the system pre-loaded, or at least an automatic boot loader
which installs it on first connection (and updates as necessary). The card
needs to have connections at breadboard pitch and/or feasible for hand
soldering. Like the Arduino the whole thing including the hardware designs
should be open-source, but the real key is the availability of pre-built
modules that can be used without a C tool chain, special development
hardware or surface-mount assembly tools. Accepting that we have to supply
(or get partners to supply) a board-level product means we can access the
best chips for the job be they surface-mount or even BGA and it also makes
possible a modest revenue stream to help fund the project. (Self-publish
manuals following the Lua.org pattern are another possibility here).

As for a name, does the Portugese word "apara" work in this context? Can it
mean this kind of chip? It sounds well in English, evoking the word
"apparatus", and it would be nice not to be saddled with an ugly
mixed-language hybrid like "LuaChip". On the other hand, going all English,
"MoonChip" has a nice ring to it also.

Just some initial thoughts to introduce myself!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3200 bytes
Desc: not available
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090212/f38610c9/attachment-0001.bin

BogdanM

eLua open hardware

In reply to this post by BogdanM

> Hi everyone! I am one of the aforementioned refugees from the Lua list, in
> fact I think it was my posting that got everyone talking about
> microcontrollers and LuaChips again.

Indeed it was, thanks for that :)

> I was about to launch my own LuaChip
> project as a search had revealed nothing existing except the pbLua port to
> the Lego controller, then Bogdan pointed me to the whole existing world of
> eLua - not sure if eLua is especially low key or if my search abilities
> need
> honing!

Googling for "lua microcontroller" returns eLua on the first page. "lua
embedded" doesn't, as the traditional semantics of that is to embed the Lua
interpreter in other programs, in order to use it as a scripting engine. Not
sure if this is the fault of eluaproject.net or not, I'm not good at all
when it comes to SEO.

> I'd like to help in any way towards a target of getting something like the
> Arduino infrastructure, but based on Lua, 32bit and network capability,
> available to purchase. This means that for a few tens of dollars I could
> buy
> a small pre-built card that I can plug into a PC (Windows, Linux and
> perhaps
> OSX) via USB and immediately start programming in Lua. The processor needs
> to come with the system pre-loaded, or at least an automatic boot loader
> which installs it on first connection (and updates as necessary). The card
> needs to have connections at breadboard pitch and/or feasible for hand
> soldering. Like the Arduino the whole thing including the hardware designs
> should be open-source, but the real key is the availability of pre-built
> modules that can be used without a C tool chain, special development
> hardware or surface-mount assembly tools. Accepting that we have to supply
> (or get partners to supply) a board-level product means we can access the
> best chips for the job be they surface-mount or even BGA and it also makes
> possible a modest revenue stream to help fund the project. (Self-publish
> manuals following the Lua.org pattern are another possibility here).

Where are you from? I'm from Romania, and here doing BGA is almost
impossible, as there are few PCB design and assembly companies, and none of
them seem to have the capabilities required for a BGA design to work
(micro-vias, even double sided component soldering, things like this). I'm
actually very curious to know how (if?) this is different in other
countries, especially US.
In my view, the best form factor would be a stamp (hence the LuaStamp I've
been picturing in my head for a while now), i.e. a board as small as
possible, with headers that would allow access to as much MCU pins as
possible. Something like
http://www.luminarymicro.com/products/lm3s8962_can_ethernet_evaluation_kit.html,
only (hopefully) smaller, and maybe with few connectors mounted on the stamp
itself, but definitely with the USB to RS232 support circuitry on board and
connected to one of the CPU's UARTs, so it would be perfectly possible to
run eLua using only the stamp board. From here there are different ways to
go:

- a "daughter board" that would expose other interfaces (USB, Ethernet, CAN,
other UARTs...)
- an "expansion board" that would allow other boards to be plugged in and
used by the stamp directly (like uCdimm, Microchip's PICTail boards, and I'm
sure there are other similar ideas out there).
- lots of boards that would allow the stamp itself to be stacked with them
vertically (and of course allowing more than two boards to be stacked with a
stamp at a given time).
- probably other things that I can't think of right now.

I think we gain a lot of flexibility by using this approach.
All of this, of course, should be accompanied by a very good support
package. I have many things in mind for this support package, but this in an
idea for a different topic on this list.

As for a name, does the Portugese word "apara" work in this context? Can it
> mean this kind of chip? It sounds well in English, evoking the word
> "apparatus", and it would be nice not to be saddled with an ugly
> mixed-language hybrid like "LuaChip". On the other hand, going all English,
> "MoonChip" has a nice ring to it also.

I'll stick with my "LuaStamp" for now :)

Best,
Bogdan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090212/5ce4947e/attachment.html

BogdanM

eLua open hardware

In reply to this post by Asko Kauppi

> I would not be interested in a crippled 8/16 bit Lua.

I think it would make an interesting exercise. Not as part of eLua itself,
but as a different project. More of an exercise in running Lua on crippled
hardware :)

> It easily becomes a completely separate (sub)language, and
> I would see our efforts be best placed within the
> "constraints" of modern, full Lua.

This is the idea of eLua, and will remain so.

> The approach of generating C or assembly language based on
> a Lua script is however a decent one. Lua is a
> magnificient preprocessing language, imho. I would i.e.
> LOVE to design VHDL's using Lua as the description
> language (now, that's constraints, isn't it?). :)

Ah, I'd _love_ to use eLua as a hardware description language, but my
knowledge in this area is quite limited unfortunately.

Best,
Bogdan

On Thu, 12 Feb 2009 13:11:14 +0200

> Bogdan Marinescu <bogdan.marinescu at gmail.com> wrote:
> > And on a related topic: on the Lua list I've seen some
> >people that want Lua
> > support on much "lower end" architectures, like 8-bit
> >MCUs. As I see it
> > right now, the way to go with this is to have a
> >completely rewritten VM
> > interpreter (probably with lots of restrictions) that
> >would be able to run
> > on these machines. But I'm curious, how many people
> >would like to have even
> > a (quite) restricted Lua running on low-to-medium end
> >8/16-bit MCUs (with
> > little Flash and RAM resources)?
> >
> > Best,
> > Bogdan
> >
> > On Thu, Feb 12, 2009 at 10:45 AM, Bogdan Marinescu <
> > bogdan.marinescu at gmail.com> wrote:
> >
> >>
> >> I've asked Atmel to spare us some samples of their
> >>upcoming AT32UC3A3
> >>> chip. Hopefully we get full development kits, but maybe
> >>>just chips.
> >>
> >>
> >> They're probably some very "secret" chips yet, I don't
> >>even see them on
> >> their AVR32 device list page.
> >>
> >>
> >>> Is there anyone else on the list that would have time
> >>>and interest to
> >>> take up such a package? I am asking for two, and my
> >>>thinking is we
> >>> could "shuffle" them among each other as need, interest
> >>>and available
> >>> time varies. So they would be "jointly" owned by the
> >>>eLua community.
> >>> Good or bad?
> >>
> >>
> >> Good, I think :)
> >>
> >>
> >>> There does not seem to be much public info on this chip,
> >>>yet.
> >>>
> >>> Here is what an Atmel friend wrote (guess this is
> >>>public, he did not
> >>> state otherwise):
> >>>
> >>> > Would the AT32UC3A be a good alternative for a stamp.
> >>> > This has networking on the chip.
> >>> > Code can be developed using the JTAGICE Mk II, which
> >>> > I bet is available to many people.
> >>
> >>
> >> Well, it turns out that (surprisingly :) ) there aren't
> >>that many people
> >> with access to a JTAGICE. The AVR32 I'm working with has
> >>a DFU mode for
> >> software uploading, I guess they'll keep it in the new
> >>chips too, so this is
> >> fine, cause all you need to program it is an USB cable
> >>and the software from
> >> Atmel (which runs equally well on Windows and Linux).
> >>
> >>
> >>> > We will soon have the AT32UC3A3 with high speed USB
> >>> > as well as SD-Card controller.
> >>> > Built for MP3. It also has more SRAM (128 kB).
> >>
> >>
> >> 128k of intermal SRAM is a Very Very Good Thing for eLua
> >>:)
> >>
> >> Please say YEAH if you personally are interested.
> >>
> >>
> >> YEAH !!!! :)
> >>
> >>
> >>> I've promised the Atmel guy that we'd craft an
> >>>Application Note on how
> >>> to use Lua on this chip. I don't think that's too much
> >>>to be asked,
> >>> and it would further the cause of eLua, anyhow.
> >>
> >>
> >> Sure, this would benefit everybody. I'll write the
> >>appnote if we get
> >> somewhere with this.
> >>
> >> Best,
> >> Bogdan
> >>
> >>
> >>>
> >>>
> >>> - asko
> >>>
> >>>
> >>>
> >>> Bogdan Marinescu kirjoitti 12.2.2009 kello 10:07:
> >>>
> >>> > Hi all,
> >>> >
> >>> > There was recently a discussion on the Lua list about
> >>>Lua on
> >>> > embedded devices, and thinks got pretty hot (in a good
> >>>way :) ), so
> >>> > I invited all the people that wanted to continue that
> >>>discussion to
> >>> > join this list (since the profile of the Lua list
> >>>suggests that it's
> >>> > not the best place to discuss regular hardware). We
> >>>had more than 10
> >>> > people joining the elua-dev list after this
> >>>announcement, so I
> >>> > expect things to become pretty hot here too :) I'll
> >>>try to resume
> >>> > the discussions by including the last relevent message
> >>>from the Lua
> >>> > list (this message is from Mike Panetta):
> >>> >
> >>> > ========================================
> >>> >
> >>> > On Wed, Feb 11, 2009 at 12:22 PM, Tony Bauer
> >>><luatony at gmail.com>
> >>> > wrote:
> >>> > More embedded notes (with some Lua content):
> >>> >
> >>> > Yes, the LPC2478 is pretty nice. My brother was
> >>>looking at using one
> >>> > at work (no Lua, though), but that project is
> >>>currently on hold.
> >>> >
> >>> > Somebody will make a Cortex M3 with an external bus.
> >>> The NXP LPC17xx
> >>> > series (Cortex M3) looks pretty nice; the LPC1768 has
> >>>64K RAM, 512K
> >>> > flash, MAC, USB OTG, 2xCAN, 4xUART, PWM, QEP, etc, but
> >>>no external
> >>> > bus.
> >>> >
> >>> > I am willing to bet that either Luminary or ST Micro
> >>>will be the
> >>> > first out the gate with such a design. In fact ST
> >>>Micro has a new
> >>> > line of chips on the back burner to release some time
> >>>this year I
> >>> > think, but you have to sign an NDA to see the product
> >>>map, which I
> >>> > have not done so have no clue as to whats there. I
> >>>personally think
> >>> > they may be waiting to pop right on the market with
> >>>available
> >>> > product as soon as Luminary announces what it has up
> >>>its sleeves.
> >>> > They seem to be in a tight heat with each other as far
> >>>as parts
> >>> > competition goes.
> >>> >
> >>> > I agree its too bad that ST does not have a cortex
> >>>part with
> >>> > Ethernet though, as they are the lowest price chip on
> >>>the market
> >>> > right now with the STM32F103ZET6 (512K Flash, 64K RAM,
> >>>CAN, USB, 8
> >>> > timers, 4 of which are capable of doing QEI, 2 of
> >>>which are capable
> >>> > of doing motion PWM, 5 U(S)ARTS, 3 SPI, 2 I2C etc
> >>>etc..... in an
> >>> > LQFP144) at $10.25 *IN SINGLES* at AVNET.
> >>> >
> >>> > I do not think that Luminary can compete with ST on
> >>>price at the
> >>> > moment because of process size (smaller process size
> >>>means more dice
> >>> > per wafer which means cheaper chips... but you already
> >>>knew that :)
> >>> > Thats of course assuming that ST uses a smaller
> >>>process then
> >>> > Luminary does (Isn't Luminary Fabless?).
> >>> >
> >>> > One thing that has made me pro ST (besides the price)
> >>>is that ST
> >>> > seems to characterize the power consumption of their
> >>>chips better
> >>> > then Luminary does. They also seem to use less power
> >>>then either
> >>> > Luminary or NXP parts at the same clock. However,
> >>>that may be
> >>> > misleading as the Luminary parts have faster flash in
> >>>them, so mips/
> >>> > watt may be less in the Luminary parts then in the ST
> >>>ones when
> >>> > running from Flash, but I have no data to back that up
> >>>(or dispute
> >>> > it).
> >>> >
> >>> >
> >>> >
> >>> > In reality, all the really cool chips are BGA, but
> >>>those make QFPs
> >>> > look easy to prototype. There are companies selling
> >>>products that
> >>> > claim to make prototyping with SMT parts easier, such
> >>>as SchmartBoard,
> >>> > but I haven't tried them.
> >>> >
> >>> > QFP's (and QFN's) *ARE* easy to prototype with, esp if
> >>>you designed
> >>> > the part footprint yourself. QFP's can be soldered in
> >>>a jiffy with a
> >>> > rake soldering technique, and when you get good at it
> >>>you won't even
> >>> > need to use solder braid to get the shorts out because
> >>>there won't
> >>> > be any. QFN's take a little bit longer (the ones with
> >>>a thermal pad
> >>> > on the bottom are easier IMO because you can fix them
> >>>down with it)
> >>> > but are also a no brainer. I designed a
> >>>powersupply/LIPo charger
> >>> > with an LTC3556 USB power manager chip and hand
> >>>soldered it. First
> >>> > proto worked perfectly, no bridges or anything. It
> >>>took me 2-3 hrs
> >>> > to complete the soldering job, all by hand. My next
> >>>protos will
> >>> > hopefully be done by toaster method, but I need to
> >>>build a
> >>> > controller first. Its kinda hard to get the parts
> >>>when your
> >>> > unemployed :P
> >>> >
> >>> > I personally think that most peoples fears to
> >>>soldering SMT parts is
> >>> > due to them never having tried it. Before I first
> >>>started using SMT
> >>> > in my designs I thought the same thing. One day I
> >>>just broke down
> >>> > and used some SMT parts on a small design, one that
> >>>would be ok to
> >>> > trash if I fudged it up. Soldering the board was much
> >>>much easier
> >>> > then I first thought, even the QFP's! (It was an
> >>>ATMega128 design).
> >>> > Since then I have never wanted to go back to through
> >>>hole parts,
> >>> > except for little pieces of free wired 'art' that I
> >>>have made. :)
> >>> >
> >>> >
> >>> >
> >>> > Still, ARM MCUs are getting down in size; the
> >>>STM32F103T8 has 20K RAM,
> >>> > 64K flash in a 36 pin QFN. But to run Lua decently,
> >>>you'll need at
> >>> > least a QFP80 (e.g. LPC1758 with 64K, ST STR911FAM4x
> >>>with 96K SRAM).
> >>> > BTW, you always have to read the fine print; for
> >>>example, in both the
> >>> > STR9 and LPC238x, the 96K SRAM is also used for the
> >>>Ethernet buffers,
> >>> > so if you use the network, you won't actually have 96K
> >>>available.
> >>> >
> >>> > So very true. All of the large ram NXP parts are like
> >>>that. They
> >>> > have a 64K main RAM area, and 2 16K buffer/DMA areas
> >>>for the
> >>> > Ethernet and USB controllers. Supposedly you can
> >>>execute out of the
> >>> > DMA RAM, but I think some of the parts have eratta
> >>>related to
> >>> > that... And I would not hold my breath on the NXP
> >>>Cortex-M3 parts,
> >>> > it took over a year between when some of the LPC24xx
> >>>parts were
> >>> > 'released' and when they actually became available to
> >>>purchase in
> >>> > any real quantities. The LCD parts were the worst I
> >>>believe, just
> >>> > becoming available around 2 months or so ago.
> >>> >
> >>> >
> >>> >
> >>> > Compilers & DSPs: most DSPs need the manufacturer's
> >>>compilers (I know
> >>> > TI's do); however, IIRC, the ADI Blackfin DSPs use
> >>>gcc. Someday I may
> >>> > try compiling Lua for a TI C6701 board, but that's not
> >>>going to happen
> >>> > for a while.
> >>> >
> >>> > CAN is a 1Mbps network, so there's no way a UART will
> >>>work. You can
> >>> > add them externally, e.g. via a SPI port.
> >>> >
> >>> > Meh, UARTS in some chips can go up to 4Mbps now. I do
> >>>agree that
> >>> > using SPI would be easier though, as Microchip has
> >>>SPI->CAN bridge
> >>> > chips available.
> >>> >
> >>> >
> >>> >
> >>> > Finally, because this bugs me, some terminology notes:
> >>> > SoC - System on a Chip. So, a chip that integrates
> >>>almost everything
> >>> > a piece of equipment (system) needs. A good example
> >>>is a highly
> >>> > integrated chip for MP3 players.
> >>> > SiP - System on a Package.
> >>> > MCU - Microcontroller. A CPU that includes all its
> >>>memory on chip.
> >>> > MCUs go back to the very early days, with such chips
> >>>as the Intel
> >>> > 8042, before the term SoC was ever used.
> >>> > MPU - Microprocessor. A CPU that needs external
> >>>memory (e.g. x86,
> >>> > Atmel AT91RM9200)
> >>> >
> >>> > If there really is enough interest, we should start
> >>>thinking about
> >>> > starting a dedicated embedded processor Lua mailing
> >>>list. Then we can
> >>> > go off topic without fear!
> >>> >
> >>> > I agree 100%! I would love to continue this
> >>>discussion.
> >>> >
> >>> > ========================================
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > Elua-dev mailing list
> >>> > Elua-dev at lists.berlios.de
> >>> > https://lists.berlios.de/mailman/listinfo/elua-dev
> >>>
> >>> _______________________________________________
> >>> Elua-dev mailing list
> >>> Elua-dev at lists.berlios.de
> >>> https://lists.berlios.de/mailman/listinfo/elua-dev
> >>>
> >>
> >>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090212/f09eca79/attachment-0001.html

John Hind

eLua open hardware

In reply to this post by BogdanM

>>
Where are you from? I'm from Romania, and here doing BGA is almost
impossible, as there are few PCB design and assembly companies, and none of
them seem to have the capabilities required for a BGA design to work
(micro-vias, even double sided component soldering, things like this). I'm
actually very curious to know how (if?) this is different in other
countries, especially US.
<<

I'm from London (England). I've not looked into BGA, but you are probably
right that surface mount will be the way to go, but manufacturing could be
done anywhere (China?). Probably the volumes are not high enough for BGA to
be economical. However even surface mount requires special assembly tooling
(and good eyesight!). I agree that the Stamp format is good, i.e. a 0.1"
pitch DIP (or maybe SIP) Pin header. This way, it can be used on a
breadboard or on a low-tech through-hole PCB. Just bring the IO pins
straight out and keep the SM module as simple and generic as possible and
then users can add their own interface circuitry at "human scale".

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3200 bytes
Desc: not available
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090212/01573b48/attachment.bin

Jesus Alvarez

Luminary Driver License

In reply to this post by BogdanM

The eLua platform support for LM3S is based on the Luminary driver library.
Instead of using BSD or another standard license, Luminary imposes a
peculiar restriction that is stated in their source files.

// All rights are reserved. You may not combine
// this software with "viral" open-source software in order to form a larger
// program.

Although they do allow free redistribution, that wording could restrict the
use of their driver library in some open source software. I am also
concerned with the use of the "viral" word to describe some open source
projects.

This has come up with some of my projects but nobody has been concerned
enough to contest it. I have brought this up with Luminary directly but they
don't see a reason for change. According to them, the license was prepared
by their legal staff and is not a restriction as long as you use their
drivers with LMI hardware. Yet that is not what's implied in that statement.

I would like to know the opinion of the eLua developer community on this.
Could that statement impose a restriction in some applications?

Regards,
Jesus Alvarez

John Hind

eLua open hardware

In reply to this post by BogdanM

I agree - I do not see the point of this. If it has not got tables it is not
Lua and surely it is tables that are driving the high RAM requirement? Most
8 bit chips are address space limited even if you can add external RAM
(which quickly loses you any advantage from the low end chip in the first
place!) Even if you cross-compile you have the table basis of the language
to cope with at run-time.

However. Might there be scope for playing with the Lua internals to reduce
RAM requirements (to tens of K rather than individual bytes though!)? I'm
thinking of a facility to put objects like library functions, tables and
strings into Flash memory rather than RAM.

From: elua-dev-bounces at lists.berlios.de
[mailto:elua-dev-bounces at lists.berlios.de] On Behalf Of Bogdan Marinescu
Sent: 12 February 2009 11:55
To: eLua Users and Development List
Subject: Re: [eLua-dev] eLua open hardware

I would not be interested in a crippled 8/16 bit Lua.

I think it would make an interesting exercise. Not as part of eLua itself,
but as a different project. More of an exercise in running Lua on crippled
hardware :)

It easily becomes a completely separate (sub)language, and
I would see our efforts be best placed within the
"constraints" of modern, full Lua.

This is the idea of eLua, and will remain so.

The approach of generating C or assembly language based on
a Lua script is however a decent one. Lua is a
magnificient preprocessing language, imho. I would i.e.
LOVE to design VHDL's using Lua as the description
language (now, that's constraints, isn't it?). :)

Ah, I'd _love_ to use eLua as a hardware description language, but my
knowledge in this area is quite limited unfortunately.

Best,
Bogdan

On Thu, 12 Feb 2009 13:11:14 +0200

Bogdan Marinescu <bogdan.marinescu at gmail.com> wrote:

_______________________________________________
Elua-dev mailing list
Elua-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/elua-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090212/6b5c0df5/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3200 bytes
Desc: not available
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090212/6b5c0df5/attachment-0001.bin

Dado Sutter

Luminary Driver License

In reply to this post by Jesus Alvarez

Hello Alvarez,
Thank you for bringuing this to the list.
We've had the same concern before, as the Luminary's Cortex M3 were one
of our first ports.
Just like you, we went straight to the LM guys and they gave us the same
explanation, that their libs can be freely used, as long as they run on
their hardware.
I totally agree with you that their use of the term "viral" open-source
software, is at least very bad for their image but aparently they like it
for some reason.
I still have their answer message (e-mail), although I'm not sure if it
has any legal value. Now that the community has grown (a lot ! :), I may try
to get something more "official" from them. I don't think we will have any
problems here though, as it would be a pitty for their nice ARMs not to have
eLua on them :) :) and also because they have already added us to their 3rd
Party Products Page (
http://www.luminarymicro.com/products/3rd_party_products.html).
Thanks again !

Best
Dado

On Thu, Feb 12, 2009 at 12:28, Jesus Alvarez <jalvarez at micromint.com> wrote:

> The eLua platform support for LM3S is based on the Luminary driver library.
> Instead of using BSD or another standard license, Luminary imposes a
> peculiar restriction that is stated in their source files.
>
> // All rights are reserved. You may not combine
> // this software with "viral" open-source software in order to form a
> larger
> // program.
>
> Although they do allow free redistribution, that wording could restrict the
> use of their driver library in some open source software. I am also
> concerned with the use of the "viral" word to describe some open source
> projects.
>
> This has come up with some of my projects but nobody has been concerned
> enough to contest it. I have brought this up with Luminary directly but
> they
> don't see a reason for change. According to them, the license was prepared
> by their legal staff and is not a restriction as long as you use their
> drivers with LMI hardware. Yet that is not what's implied in that
> statement.
>
> I would like to know the opinion of the eLua developer community on this.
> Could that statement impose a restriction in some applications?
>
> Regards,
> Jesus Alvarez
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090212/054107a2/attachment.html

Dado Sutter

eLua open hardware

In reply to this post by BogdanM

Hello Guys,
BGA is also a barrier downhere in Brazil, although there are now some
companies that assemble them fast and not that more expensive (= not more
then the usual overhead for non-huge quantities).
My feeling is that, if a board/stamp will be targeted at hobbysts,
independent developers and/or small companies, BGA is not very welcome.
On the format, DIP or SIP can be very hard too, with some fancy chips
full of internal toys and features (228 pins on some NXPs !!!!!).

Best
Dado

On Thu, Feb 12, 2009 at 12:13, John Hind <john.hind at zen.co.uk> wrote:

> >>
> Where are you from? I'm from Romania, and here doing BGA is almost
> impossible, as there are few PCB design and assembly companies, and none of
> them seem to have the capabilities required for a BGA design to work
> (micro-vias, even double sided component soldering, things like this). I'm
> actually very curious to know how (if?) this is different in other
> countries, especially US.
> <<
>
> I'm from London (England). I've not looked into BGA, but you are probably
> right that surface mount will be the way to go, but manufacturing could be
> done anywhere (China?). Probably the volumes are not high enough for BGA to
> be economical. However even surface mount requires special assembly tooling
> (and good eyesight!). I agree that the Stamp format is good, i.e. a 0.1"
> pitch DIP (or maybe SIP) Pin header. This way, it can be used on a
> breadboard or on a low-tech through-hole PCB. Just bring the IO pins
> straight out and keep the SM module as simple and generic as possible and
> then users can add their own interface circuitry at "human scale".
>
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090212/e02c9909/attachment.html

Dean Hall

eLua open hardware

In reply to this post by Asko Kauppi

Regarding 8-bit, I recommend avoiding that option. Yes, I'm
shamelessly protecting PyMite's turf <smiley>. Taking Lua to small
RAM would be a challenging problem, but ultimately frustrating: the
harder you work to make it fit in smaller RAM, the less capabilities
you are allowing! This is a warning that comes from experience.

Regarding hardware, I have a PCB that is currently being fabbed. When
I get this design working, I plan to make it open (schematics and
layout in EAGLE). It is small (51mm x 66mm) (2" x 2.6"), holds the
range of Atmel AT32UC3A1*** (TQFP100) and makes all pins available,
except PC4,5 which are connected to a 12 MHz xtal. The pins are
available through 4 2x10 0.1" standard headers. Other features: a
reset button, JTAG port and USB mini-B. The board is powered by USB
or by a separate supply coming in through one of the 4 main connector
headers. This board is meant to be stacked onto a carrier board of
your own design to provide the features you want.

I chose the AT32UC3A1*** because it is the natural upgrade path of
AVR, it has up to 64 KB ram and MOST IMPORTANTLY it is available in-
stock at Digikey and Mouser (the two most popular US suppliers that
provide small quantity).

!!Dean

Jesus Alvarez

Luminary Driver License

In reply to this post by Dado Sutter

Hello, Dado.

Thanks for your comments.

I believe that if their intention is to restrict usage to LMI hardware, they
should drop the "viral" statement from the license text. That statement is
not consistent with the intentions they state verbally or via email. It
could lead to misunderstandings in the future.

The "viral" reference could even be considered insulting to some open source
enthusiasts. Relating virus to open source software is inappropriate and to
me it does not make much sense.

It would be difficult to justify developing a driver library independent
from Luminary just because of that statement. Their library works well and
can be freely distributed. But they should remove that sentence from the
license and make the license text consistent with their apparent intentions.
Lawyers can find many ways to interpret a license so there should be little
room for interpretation. It would be better if they moved to BSD or another
common open source license that has been well tested. Yet that may be asking
too much.

Regards,
Jesus Alvarez

Dado Sutter

eLua open hardware

In reply to this post by Dean Hall

Great to hear that Dean !
In our very informal "backyard market research", we've found that a stamp
is not completely welcome to hobbyst, educational teams and prototypers if
it does not come with a base board to plug it in.
It usually raises the cost (compared to evaluation/demo kits) but it has
the advantage that the stamp can later be used in a final product.
The thing seems to be: "avoid forcing final users to build PCBs". They
(here) are not too much against of adding hardware to a board (breadboard
areas, prototyping standard boards, ....) but to design and build modern
PCBs has become a barrier for many.

Best
Dado

On Thu, Feb 12, 2009 at 13:01, Dean Hall <dwhall256 at gmail.com> wrote:

> Regarding 8-bit, I recommend avoiding that option. Yes, I'm
> shamelessly protecting PyMite's turf <smiley>. Taking Lua to small
> RAM would be a challenging problem, but ultimately frustrating: the
> harder you work to make it fit in smaller RAM, the less capabilities
> you are allowing! This is a warning that comes from experience.
>
> Regarding hardware, I have a PCB that is currently being fabbed. When
> I get this design working, I plan to make it open (schematics and
> layout in EAGLE). It is small (51mm x 66mm) (2" x 2.6"), holds the
> range of Atmel AT32UC3A1*** (TQFP100) and makes all pins available,
> except PC4,5 which are connected to a 12 MHz xtal. The pins are
> available through 4 2x10 0.1" standard headers. Other features: a
> reset button, JTAG port and USB mini-B. The board is powered by USB
> or by a separate supply coming in through one of the 4 main connector
> headers. This board is meant to be stacked onto a carrier board of
> your own design to provide the features you want.
>
> I chose the AT32UC3A1*** because it is the natural upgrade path of
> AVR, it has up to 64 KB ram and MOST IMPORTANTLY it is available in-
> stock at Digikey and Mouser (the two most popular US suppliers that
> provide small quantity).
>
> !!Dean
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090212/b33ed3a0/attachment.html

Dean Hall

eLua open hardware

Yes, I agree a carrier board is important for the hobbyist; but I'm
not yet convinced there is profit to be made. My first carrier board
is going to be robot-oriented with xbee wireless (I don't need
ethernet for that board and want those pins for gpio). However, a
buddy in my local robot club really wants ethernet, so that's when I
decided to follow the successful two-board model used by the Make
controller (although I think the dichotomy of their layout wasn't very
well thought out).

!!Dean

On Feb 12, 2009, at 09:21 , Dado Sutter wrote:

> Great to hear that Dean !
> In our very informal "backyard market research", we've found that
> a stamp is not completely welcome to hobbyst, educational teams and
> prototypers if it does not come with a base board to plug it in.
> It usually raises the cost (compared to evaluation/demo kits) but
> it has the advantage that the stamp can later be used in a final
> product.
> The thing seems to be: "avoid forcing final users to build PCBs".
> They (here) are not too much against of adding hardware to a board
> (breadboard areas, prototyping standard boards, ....) but to design
> and build modern PCBs has become a barrier for many.
>
> Best
> Dado
>
>
>
> On Thu, Feb 12, 2009 at 13:01, Dean Hall <dwhall256 at gmail.com> wrote:
> Regarding 8-bit, I recommend avoiding that option. Yes, I'm
> shamelessly protecting PyMite's turf <smiley>. Taking Lua to small
> RAM would be a challenging problem, but ultimately frustrating: the
> harder you work to make it fit in smaller RAM, the less capabilities
> you are allowing! This is a warning that comes from experience.
>
> Regarding hardware, I have a PCB that is currently being fabbed. When
> I get this design working, I plan to make it open (schematics and
> layout in EAGLE). It is small (51mm x 66mm) (2" x 2.6"), holds the
> range of Atmel AT32UC3A1*** (TQFP100) and makes all pins available,
> except PC4,5 which are connected to a 12 MHz xtal. The pins are
> available through 4 2x10 0.1" standard headers. Other features: a
> reset button, JTAG port and USB mini-B. The board is powered by USB
> or by a separate supply coming in through one of the 4 main connector
> headers. This board is meant to be stacked onto a carrier board of
> your own design to provide the features you want.
>
> I chose the AT32UC3A1*** because it is the natural upgrade path of
> AVR, it has up to 64 KB ram and MOST IMPORTANTLY it is available in-
> stock at Digikey and Mouser (the two most popular US suppliers that
> provide small quantity).
>
> !!Dean
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev

John Hind

Awsome ST evaluation kit

In reply to this post by Dado Sutter

Anyone spotted this:

http://www.st.com/stonline/stappl/cms/press/news/year2009/p2364.htm

It is available now from Farnell (operates worldwide including Romania and
Brazil), costs $50 and has a 512/64 KB ARM microcontroller, so should run
eLua comfortably!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090212/34c4d4ee/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3200 bytes
Desc: not available
Url : https://lists.berlios.de/pipermail/elua-dev/attachments/20090212/34c4d4ee/attachment-0001.bin

BogdanM

Luminary Driver License

In reply to this post by Jesus Alvarez

Hi,

Actually WE well move to BSD starting with 0.6, so the problem will solve by
itself :) (I already asked on their forums, and BSD is not considered a
viral license).

Best,
Bogdan

On Thu, Feb 12, 2009 at 5:13 PM, Jesus Alvarez <jalvarez at micromint.com>wrote:

> Hello, Dado.
>
> Thanks for your comments.
>
> I believe that if their intention is to restrict usage to LMI hardware,
> they
> should drop the "viral" statement from the license text. That statement is
> not consistent with the intentions they state verbally or via email. It
> could lead to misunderstandings in the future.
>
> The "viral" reference could even be considered insulting to some open
> source
> enthusiasts. Relating virus to open source software is inappropriate and to
> me it does not make much sense.
>
> It would be difficult to justify developing a driver library independent
> from Luminary just because of that statement. Their library works well and
> can be freely distributed. But they should remove that sentence from the
> license and make the license text consistent with their apparent
> intentions.
> Lawyers can find many ways to interpret a license so there should be little
> room for interpretation. It would be better if they moved to BSD or another
> common open source license that has been well tested. Yet that may be
> asking
> too much.
>
> Regards,
> Jesus Alvarez
>
>
> _______________________________________________
> Elua-dev mailing list
> Elua-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/elua-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.berlios.de/pipermail/elua-dev/attachments/20090212/29b3daa8/attachment.html

1234