eLua Development

Re: Single Chip Lua Prospects

Classic

List

Threaded

22 messages Options

Tony-12

Re: Single Chip Lua Prospects

Even more single-chip eLua candidates are coming, so the situation is a bit better than last year.

1. ST has expanded the STM32 Performance line with models with 96K SRAM and 768K or 1024K flash; packages include a 64-pin QFP. Not sure on availability, but should be fairly soon.
2. Microchip has PIC32MX MCUs with 128K SRAM and 512K flash in a QFP-64.
3. If you want to go for broke, Renesas has the SH7216 series with 200MHz speed, FPU, 128K SRAM and 1024K flash -- but as usual with Renesas, availability is poor and the price is high (Digikey only lists one model, not in stock, for $42.27 qty 1).
4. Someday Renesas promises they'll have a new RX600 MCU with 256K SRAM and 4M flash. On the good side, Renesas does make a lot of very capable MCUs in QFPs. But, I'm not holding my breath waiting for availability (my guess is it's at least several years away).

--Tony

On Mon, Jun 22, 2009 at 2:42 AM, John Hind <[hidden email]> wrote:

When I subscribed to this list half a year ago I confidently expected to be able to use a single chip Lua device in my projects by now. I wanted to use many such chips in a seriously distributed architecture with the processing kept near to the IO to simplify wiring. To avoid buying an endless succession of development boards I set a simple threshold specification of 512K on-chip flash, 64K on-chip RAM, Ethernet capability (I was prepared to compromise with a second chip for this). With this type of distributed architecture, I need lots of IO versatility (analog, PWM, UART, I2C, SPI, counters etc.) but multiplexed on relatively few pins since if you run out of IO you just add another chip. It should therefore be possible to have a simple 20-40 pin package which could be available in hand-solderable form.

It is very disappointing that after many months still the only chip that comes near is the LPC2888 which seems to be buggy and expensive (the very minimalist LPC-H2888 prototype board is over $150). Looking at the schematics for this board really reinforced my intuition about the importance of on-chip memory – a ridiculous number of pins (and therefore PCB traces) is wasted on the external memory interface. And the economics are terrible - for just $20 more, you can get the new Acer Aspire Revo R3600 nettop (in Linux rather than Vista trim). The latter has both wired and wireless networking, 1GB RAM and an 8GB SSD!

IO is the problem of course with an X86 platform. However in my research I found this incredibly poorly marketed chip:

http://delcomproduct.com/products_USBIO.asp#DemoBrd

A versatile USB to IO pins chip for only $8! This looks like great universal IO problem solver. Unlike most other DIY USB solutions I’ve seen which require a driver and/or serial port emulator, this is HID based and therefore driverless on all major OS’s. I have ordered some of these chips and will report back how it goes.

I am beginning to think it might just be better to cooperate with market forces here since I suspect that X86 computing is going to keep widening the functionality gap and reducing the price gap. Rather than trying to squeeze Lua onto a cramped chip with no operating system, would it maybe be better to produce a custom cut-down Linux distro with Lua built in (and perhaps acting as the shell)?

What do others think? Will there be cheap, single chip ARM devices meeting my spec available in the next few months?

_______________________________________________
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

Re: Single Chip Lua Prospects

Thanks for all the good news, Tony! You made my day.

On Fri, Mar 5, 2010 at 1:07 AM, Tony <[hidden email]> wrote:

Even more single-chip eLua candidates are coming, so the situation is a bit better than last year.

1. ST has expanded the STM32 Performance line with models with 96K SRAM and 768K or 1024K flash; packages include a 64-pin QFP. Not sure on availability, but should be fairly soon.

Excellent. I really like the STM32s. If their next step is to bump the RAM to 128k, I'll probably marry that chip (sorry, wife). 96k is good enough though, I have a board with a STM32F103RE (512kF/32kR) and it can do a lot of nice stuff.

2. Microchip has PIC32MX MCUs with 128K SRAM and 512K flash in a QFP-64.

WOW! Now this is something I really have to try soon. I have an older PIC32 board at home, but accessing its UART requires a connector that is hard to find and even harder to solder, so I didn't touch it yet (although PIC32 has been on eLua's TOPORT list for quite a while now). This is one thing about Microchip's PIC32 boards that annoys me quite a bit: in order to have a proper development environment for eLua (an UART, to be more precise), I'd have to buy the PIC32 board (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en535536) which should be then stuck in a PIC32 I/O expansion board (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en535444) and I still have to use some sort of daugherboard in that one to get a serial connector (if I don't feel like soldering, that is).
That said, I have to check if I can't use one of the on-board USB connections as a CDC, this might simplify things quite a bit. I don't think I have the time to develop a CDC device on PIC32 myself, but maybe they have something like this in their software library. And who knows, maybe they're even willing to sponsor us. Thanks for the hint! I had no idea about this new line (new to me, as least :) ) of PIC32 devices.

3. If you want to go for broke, Renesas has the SH7216 series with 200MHz speed, FPU, 128K SRAM and 1024K flash -- but as usual with Renesas, availability is poor and the price is high (Digikey only lists one model, not in stock, for $42.27 qty 1).

If they're not easily available in the US, chances are they aren't available at all in Europe. I found it quite hard to find Renesas products in Europe. Still, this chip sounds SWEET. Especially the FPU part.

4. Someday Renesas promises they'll have a new RX600 MCU with 256K SRAM and 4M flash. On the good side, Renesas does make a lot of very capable MCUs in QFPs. But, I'm not holding my breath waiting for availability (my guess is it's at least several years away).

You're probably right, but it's very good to see this "more on-board RAM and Flash" trend. Very nice for eLua, as we all know :)

Best,
Bogdan

--Tony

On Mon, Jun 22, 2009 at 2:42 AM, John Hind <[hidden email]> wrote:

When I subscribed to this list half a year ago I confidently expected to be able to use a single chip Lua device in my projects by now. I wanted to use many such chips in a seriously distributed architecture with the processing kept near to the IO to simplify wiring. To avoid buying an endless succession of development boards I set a simple threshold specification of 512K on-chip flash, 64K on-chip RAM, Ethernet capability (I was prepared to compromise with a second chip for this). With this type of distributed architecture, I need lots of IO versatility (analog, PWM, UART, I2C, SPI, counters etc.) but multiplexed on relatively few pins since if you run out of IO you just add another chip. It should therefore be possible to have a simple 20-40 pin package which could be available in hand-solderable form.

It is very disappointing that after many months still the only chip that comes near is the LPC2888 which seems to be buggy and expensive (the very minimalist LPC-H2888 prototype board is over $150). Looking at the schematics for this board really reinforced my intuition about the importance of on-chip memory – a ridiculous number of pins (and therefore PCB traces) is wasted on the external memory interface. And the economics are terrible - for just $20 more, you can get the new Acer Aspire Revo R3600 nettop (in Linux rather than Vista trim). The latter has both wired and wireless networking, 1GB RAM and an 8GB SSD!

IO is the problem of course with an X86 platform. However in my research I found this incredibly poorly marketed chip:

http://delcomproduct.com/products_USBIO.asp#DemoBrd

A versatile USB to IO pins chip for only $8! This looks like great universal IO problem solver. Unlike most other DIY USB solutions I’ve seen which require a driver and/or serial port emulator, this is HID based and therefore driverless on all major OS’s. I have ordered some of these chips and will report back how it goes.

I am beginning to think it might just be better to cooperate with market forces here since I suspect that X86 computing is going to keep widening the functionality gap and reducing the price gap. Rather than trying to squeeze Lua onto a cramped chip with no operating system, would it maybe be better to produce a custom cut-down Linux distro with Lua built in (and perhaps acting as the shell)?

What do others think? Will there be cheap, single chip ARM devices meeting my spec available in the next few months?

_______________________________________________
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

John Hind

Re: Single Chip Lua Prospects

I must look at PIC32 again myself! But is the serial port really necessary? The MX chips have USB and the (free) Microchip USB stack does Mass Storage Device as well as Human Interface Device (at least on the PIC 18 it does and it will even do both at once). Similar to the Mbed, would it not be possible to make the chip mount as a disk drive on the host computer and edit the script files directly in place?

Ideally there could be a switch on the board and you’d flip it one way for MSD to load your scripts and flip it the other way to run the scripts with access to USB as HID so you could create USB devices.

Time for another look, I think – Thanks Tony!

From: [hidden email] [mailto:[hidden email]] On Behalf Of Bogdan Marinescu
Sent: 05 March 2010 10:10
To: eLua Users and Development List (www.eluaproject.net)
Subject: Re: [eLua-dev] Single Chip Lua Prospects

Thanks for all the good news, Tony! You made my day.

On Fri, Mar 5, 2010 at 1:07 AM, Tony <[hidden email]> wrote:

2. Microchip has PIC32MX MCUs with 128K SRAM and 512K flash in a QFP-64.

3. If you want to go for broke, Renesas has the SH7216 series with 200MHz speed, FPU, 128K SRAM and 1024K flash -- but as usual with Renesas, availability is poor and the price is high (Digikey only lists one model, not in stock, for $42.27 qty 1).

4. Someday Renesas promises they'll have a new RX600 MCU with 256K SRAM and 4M flash. On the good side, Renesas does make a lot of very capable MCUs in QFPs. But, I'm not holding my breath waiting for availability (my guess is it's at least several years away).

You're probably right, but it's very good to see this "more on-board RAM and Flash" trend. Very nice for eLua, as we all know :)

Best,
Bogdan

--Tony

On Mon, Jun 22, 2009 at 2:42 AM, John Hind <[hidden email]> wrote:

When I subscribed to this list half a year ago I confidently expected to be able to use a single chip Lua device in my projects by now. I wanted to use many such chips in a seriously distributed architecture with the processing kept near to the IO to simplify wiring. To avoid buying an endless succession of development boards I set a simple threshold specification of 512K on-chip flash, 64K on-chip RAM, Ethernet capability (I was prepared to compromise with a second chip for this). With this type of distributed architecture, I need lots of IO versatility (analog, PWM, UART, I2C, SPI, counters etc.) but multiplexed on relatively few pins since if you run out of IO you just add another chip. It should therefore be possible to have a simple 20-40 pin package which could be available in hand-solderable form.

It is very disappointing that after many months still the only chip that comes near is the LPC2888 which seems to be buggy and expensive (the very minimalist LPC-H2888 prototype board is over $150). Looking at the schematics for this board really reinforced my intuition about the importance of on-chip memory – a ridiculous number of pins (and therefore PCB traces) is wasted on the external memory interface. And the economics are terrible - for just $20 more, you can get the new Acer Aspire Revo R3600 nettop (in Linux rather than Vista trim). The latter has both wired and wireless networking, 1GB RAM and an 8GB SSD!

IO is the problem of course with an X86 platform. However in my research I found this incredibly poorly marketed chip:

http://delcomproduct.com/products_USBIO.asp#DemoBrd

A versatile USB to IO pins chip for only $8! This looks like great universal IO problem solver. Unlike most other DIY USB solutions I’ve seen which require a driver and/or serial port emulator, this is HID based and therefore driverless on all major OS’s. I have ordered some of these chips and will report back how it goes.

I am beginning to think it might just be better to cooperate with market forces here since I suspect that X86 computing is going to keep widening the functionality gap and reducing the price gap. Rather than trying to squeeze Lua onto a cramped chip with no operating system, would it maybe be better to produce a custom cut-down Linux distro with Lua built in (and perhaps acting as the shell)?

What do others think? Will there be cheap, single chip ARM devices meeting my spec available in the next few months?

_______________________________________________
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

Re: Single Chip Lua Prospects

In reply to this post by BogdanM

On Sat, Mar 6, 2010 at 12:09 PM, John Hind <[hidden email]> wrote:

I must look at PIC32 again myself! But is the serial port really necessary? The MX chips have USB and the (free) Microchip USB stack does Mass Storage Device as well as Human Interface Device (at least on the PIC 18 it does and it will even do both at once).

Thanks, I didn't know that. The only PIC with USB I ever played with was a 18F21550, and I was greatly disappointed by it (more specifically by its USB implementation, which was extremely sensitive to electrical noise, even after I designed and build a PCB around it). I do expect an improvement in PIC32 though. I hope it can also do CDC out of the box (I'm sure it can, but I'm hoping to find support in Microchip's library for CDC, as I really don't feel like writing that), so we can get our serial port one way or another. Strictly speaking, a serial port is not *required* for eLua, but it does simplify the interaction with eLua quite a bit.

Similar to the Mbed, would it not be possible to make the chip mount as a disk drive on the host computer and edit the script files directly in place?

You probably could (James Snyder is already working on this for Mbed), but you'd still need a way to run the scripts. Currently, the only way to run without an explicit command from the shell is to have an "autorun.lua" file that is executed at startup. We'll think of new ways of interaction if needed :)

Ideally there could be a switch on the board and you’d flip it one way for MSD to load your scripts and flip it the other way to run the scripts with access to USB as HID so you could create USB devices.

I wouldn't go the HID way if I can do CDC. I don't see the point.

Time for another look, I think – Thanks Tony!

Yeah, my thoughts exactly :)

Best,
Bogdan

From: [hidden email] [mailto:[hidden email]] On Behalf Of Bogdan Marinescu
Sent: 05 March 2010 10:10
To: eLua Users and Development List (www.eluaproject.net)

Subject: Re: [eLua-dev] Single Chip Lua Prospects

Thanks for all the good news, Tony! You made my day.

On Fri, Mar 5, 2010 at 1:07 AM, Tony <[hidden email]> wrote:

Even more single-chip eLua candidates are coming, so the situation is a bit better than last year.

1. ST has expanded the STM32 Performance line with models with 96K SRAM and 768K or 1024K flash; packages include a 64-pin QFP. Not sure on availability, but should be fairly soon.

Excellent. I really like the STM32s. If their next step is to bump the RAM to 128k, I'll probably marry that chip (sorry, wife). 96k is good enough though, I have a board with a STM32F103RE (512kF/32kR) and it can do a lot of nice stuff.

2. Microchip has PIC32MX MCUs with 128K SRAM and 512K flash in a QFP-64.

WOW! Now this is something I really have to try soon. I have an older PIC32 board at home, but accessing its UART requires a connector that is hard to find and even harder to solder, so I didn't touch it yet (although PIC32 has been on eLua's TOPORT list for quite a while now). This is one thing about Microchip's PIC32 boards that annoys me quite a bit: in order to have a proper development environment for eLua (an UART, to be more precise), I'd have to buy the PIC32 board (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en535536) which should be then stuck in a PIC32 I/O expansion board (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en535444) and I still have to use some sort of daugherboard in that one to get a serial connector (if I don't feel like soldering, that is).
That said, I have to check if I can't use one of the on-board USB connections as a CDC, this might simplify things quite a bit. I don't think I have the time to develop a CDC device on PIC32 myself, but maybe they have something like this in their software library. And who knows, maybe they're even willing to sponsor us. Thanks for the hint! I had no idea about this new line (new to me, as least :) ) of PIC32 devices.

3. If you want to go for broke, Renesas has the SH7216 series with 200MHz speed, FPU, 128K SRAM and 1024K flash -- but as usual with Renesas, availability is poor and the price is high (Digikey only lists one model, not in stock, for $42.27 qty 1).

If they're not easily available in the US, chances are they aren't available at all in Europe. I found it quite hard to find Renesas products in Europe. Still, this chip sounds SWEET. Especially the FPU part.

4. Someday Renesas promises they'll have a new RX600 MCU with 256K SRAM and 4M flash. On the good side, Renesas does make a lot of very capable MCUs in QFPs. But, I'm not holding my breath waiting for availability (my guess is it's at least several years away).

You're probably right, but it's very good to see this "more on-board RAM and Flash" trend. Very nice for eLua, as we all know :)

Best,
Bogdan

--Tony

On Mon, Jun 22, 2009 at 2:42 AM, John Hind <[hidden email]> wrote:

When I subscribed to this list half a year ago I confidently expected to be able to use a single chip Lua device in my projects by now. I wanted to use many such chips in a seriously distributed architecture with the processing kept near to the IO to simplify wiring. To avoid buying an endless succession of development boards I set a simple threshold specification of 512K on-chip flash, 64K on-chip RAM, Ethernet capability (I was prepared to compromise with a second chip for this). With this type of distributed architecture, I need lots of IO versatility (analog, PWM, UART, I2C, SPI, counters etc.) but multiplexed on relatively few pins since if you run out of IO you just add another chip. It should therefore be possible to have a simple 20-40 pin package which could be available in hand-solderable form.

It is very disappointing that after many months still the only chip that comes near is the LPC2888 which seems to be buggy and expensive (the very minimalist LPC-H2888 prototype board is over $150). Looking at the schematics for this board really reinforced my intuition about the importance of on-chip memory – a ridiculous number of pins (and therefore PCB traces) is wasted on the external memory interface. And the economics are terrible - for just $20 more, you can get the new Acer Aspire Revo R3600 nettop (in Linux rather than Vista trim). The latter has both wired and wireless networking, 1GB RAM and an 8GB SSD!

IO is the problem of course with an X86 platform. However in my research I found this incredibly poorly marketed chip:

http://delcomproduct.com/products_USBIO.asp#DemoBrd

A versatile USB to IO pins chip for only $8! This looks like great universal IO problem solver. Unlike most other DIY USB solutions I’ve seen which require a driver and/or serial port emulator, this is HID based and therefore driverless on all major OS’s. I have ordered some of these chips and will report back how it goes.

I am beginning to think it might just be better to cooperate with market forces here since I suspect that X86 computing is going to keep widening the functionality gap and reducing the price gap. Rather than trying to squeeze Lua onto a cramped chip with no operating system, would it maybe be better to produce a custom cut-down Linux distro with Lua built in (and perhaps acting as the shell)?

What do others think? Will there be cheap, single chip ARM devices meeting my spec available in the next few months?

_______________________________________________
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

Re: Single Chip Lua Prospects

In reply to this post by BogdanM

On Sat, Mar 6, 2010 at 4:09 AM, John Hind <[hidden email]> wrote:
> I must look at PIC32 again myself! But is the serial port really necessary?
> The MX chips have USB and the (free) Microchip USB stack does Mass Storage
> Device as well as Human Interface Device (at least on the PIC 18 it does and
> it will even do both at once). Similar to the Mbed, would it not be possible
> to make the chip mount as a disk drive on the host computer and edit the
> script files directly in place?

FYI the way the MBED does this is by having 2 chips on the board, one
is the main NXP LPC1768, and the other one is the "mbed interface"
(another nxp mcu), and it's the interface one that's dedicated to
providing mass storage and the CDC (virtual serial port). The other
chip, I believe, doesn't have any direct connection to the USB port,
and doesn't need to know about it either. Programming is done by a
JTAG link between the interface chip and the main LPC1768.

Does the PIC32 have a USB bootloader for programming as well, that
would make this even more convenient.

> Ideally there could be a switch on the board and you’d flip it one way for
> MSD to load your scripts and flip it the other way to run the scripts with
> access to USB as HID so you could create USB devices.

You could also handle this in software where depending on whether the
mass storage device has been mounted on one side or the other, the
storage would be locked out for the opposite side (or read-only?).

>
>
>
> Time for another look, I think – Thanks Tony!
>
>
>
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Bogdan Marinescu
> Sent: 05 March 2010 10:10
> To: eLua Users and Development List (www.eluaproject.net)
>
> Subject: Re: [eLua-dev] Single Chip Lua Prospects
>
>
>
> Thanks for all the good news, Tony! You made my day.
>
> On Fri, Mar 5, 2010 at 1:07 AM, Tony <[hidden email]> wrote:
>
> Even more single-chip eLua candidates are coming, so the situation is a bit
> better than last year.
>
> 1. ST has expanded the STM32 Performance line with models with 96K SRAM and
> 768K or 1024K flash; packages include a 64-pin QFP. Not sure on
> availability, but should be fairly soon.
>
> Excellent. I really like the STM32s. If their next step is to bump the RAM
> to 128k, I'll probably marry that chip (sorry, wife). 96k is good enough
> though, I have a board with a STM32F103RE (512kF/32kR) and it can do a lot
> of nice stuff.
>
>
> 2. Microchip has PIC32MX MCUs with 128K SRAM and 512K flash in a QFP-64.
>
> WOW! Now this is something I really have to try soon. I have an older PIC32
> board at home, but accessing its UART requires a connector that is hard to
> find and even harder to solder, so I didn't touch it yet (although PIC32 has
> been on eLua's TOPORT list for quite a while now). This is one thing about
> Microchip's PIC32 boards that annoys me quite a bit: in order to have a
> proper development environment for eLua (an UART, to be more precise), I'd
> have to buy the PIC32 board
> (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en535536)
> which should be then stuck in a PIC32 I/O expansion board
> (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en535444)
> and I still have to use some sort of daugherboard in that one to get a
> serial connector (if I don't feel like soldering, that is).
> That said, I have to check if I can't use one of the on-board USB
> connections as a CDC, this might simplify things quite a bit. I don't think
> I have the time to develop a CDC device on PIC32 myself, but maybe they have
> something like this in their software library. And who knows, maybe they're
> even willing to sponsor us. Thanks for the hint! I had no idea about this
> new line (new to me, as least :) ) of PIC32 devices.
>
> 3. If you want to go for broke, Renesas has the SH7216 series with 200MHz
> speed, FPU, 128K SRAM and 1024K flash -- but as usual with Renesas,
> availability is poor and the price is high (Digikey only lists one model,
> not in stock, for $42.27 qty 1).
>
> If they're not easily available in the US, chances are they aren't available
> at all in Europe. I found it quite hard to find Renesas products in Europe.
> Still, this chip sounds SWEET. Especially the FPU part.
>
>
> 4. Someday Renesas promises they'll have a new RX600 MCU with 256K SRAM and
> 4M flash. On the good side, Renesas does make a lot of very capable MCUs in
> QFPs. But, I'm not holding my breath waiting for availability (my guess is
> it's at least several years away).
>
> You're probably right, but it's very good to see this "more on-board RAM and
> Flash" trend. Very nice for eLua, as we all know :)
>
> Best,
> Bogdan
>
>
> --Tony
>
> On Mon, Jun 22, 2009 at 2:42 AM, John Hind <[hidden email]> wrote:
>
> When I subscribed to this list half a year ago I confidently expected to be
> able to use a single chip Lua device in my projects by now. I wanted to use
> many such chips in a seriously distributed architecture with the processing
> kept near to the IO to simplify wiring. To avoid buying an endless
> succession of development boards I set a simple threshold specification of
> 512K on-chip flash, 64K on-chip RAM, Ethernet capability (I was prepared to
> compromise with a second chip for this). With this type of distributed
> architecture, I need lots of IO versatility (analog, PWM, UART, I2C, SPI,
> counters etc.) but multiplexed on relatively few pins since if you run out
> of IO you just add another chip. It should therefore be possible to have a
> simple 20-40 pin package which could be available in hand-solderable form.
>
>
>
> It is very disappointing that after many months still the only chip that
> comes near is the LPC2888 which seems to be buggy and expensive (the very
> minimalist LPC-H2888 prototype board is over $150). Looking at the
> schematics for this board really reinforced my intuition about the
> importance of on-chip memory – a ridiculous number of pins (and therefore
> PCB traces) is wasted on the external memory interface. And the economics
> are terrible - for just $20 more, you can get the new Acer Aspire Revo R3600
> nettop (in Linux rather than Vista trim). The latter has both wired and
> wireless networking, 1GB RAM and an 8GB SSD!
>
>
>
> IO is the problem of course with an X86 platform. However in my research I
> found this incredibly poorly marketed chip:
>
>
>
> http://delcomproduct.com/products_USBIO.asp#DemoBrd
>
>
>
> A versatile USB to IO pins chip for only $8! This looks like great universal
> IO problem solver. Unlike most other DIY USB solutions I’ve seen which
> require a driver and/or serial port emulator, this is HID based and
> therefore driverless on all major OS’s. I have ordered some of these chips
> and will report back how it goes.
>
>
>
> I am beginning to think it might just be better to cooperate with market
> forces here since I suspect that X86 computing is going to keep widening the
> functionality gap and reducing the price gap. Rather than trying to squeeze
> Lua onto a cramped chip with no operating system, would it maybe be better
> to produce a custom cut-down Linux distro with Lua built in (and perhaps
> acting as the shell)?
>
>
>
> What do others think? Will there be cheap, single chip ARM devices meeting
> my spec available in the next few months?
>
>
>
>
>
> _______________________________________________
> 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
>
>

--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
PGP: http://fanplastic.org/key.txt
Phone: (847) 448-0386
_______________________________________________
eLua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

Tony-12

Re: Single Chip Lua Prospects

In reply to this post by BogdanM

I'm glad to be the catalyst for a PIC32 port; I do think the PIC32MX795F512H looks pretty interesting. I was very surprised that Microchip included so much RAM, because in the past PIC micros have been pretty light on RAM.

It looks like the PIC32MX795F512's are just starting to reach the distributors (e.g. Mouser USA has 10 in stock).

Another bit of news: Atmel is working on a single precision FPU for the AVR32 U3 series. Since no parts were announced, it'll be a while (my guess: >2 years to reach distribution). But a AVR32U3 series with >= 128K SRAM and FPU would be pretty sweet.

--Tony

On Sat, Mar 6, 2010 at 2:09 AM, John Hind <[hidden email]> wrote:

I must look at PIC32 again myself! But is the serial port really necessary? The MX chips have USB and the (free) Microchip USB stack does Mass Storage Device as well as Human Interface Device (at least on the PIC 18 it does and it will even do both at once). Similar to the Mbed, would it not be possible to make the chip mount as a disk drive on the host computer and edit the script files directly in place?

Ideally there could be a switch on the board and you’d flip it one way for MSD to load your scripts and flip it the other way to run the scripts with access to USB as HID so you could create USB devices.

Time for another look, I think – Thanks Tony!

From: [hidden email] [mailto:[hidden email]] On Behalf Of Bogdan Marinescu
Sent: 05 March 2010 10:10
To: eLua Users and Development List (www.eluaproject.net)

Subject: Re: [eLua-dev] Single Chip Lua Prospects

Thanks for all the good news, Tony! You made my day.

On Fri, Mar 5, 2010 at 1:07 AM, Tony <[hidden email]> wrote:

Even more single-chip eLua candidates are coming, so the situation is a bit better than last year.

1. ST has expanded the STM32 Performance line with models with 96K SRAM and 768K or 1024K flash; packages include a 64-pin QFP. Not sure on availability, but should be fairly soon.

Excellent. I really like the STM32s. If their next step is to bump the RAM to 128k, I'll probably marry that chip (sorry, wife). 96k is good enough though, I have a board with a STM32F103RE (512kF/32kR) and it can do a lot of nice stuff.

2. Microchip has PIC32MX MCUs with 128K SRAM and 512K flash in a QFP-64.

WOW! Now this is something I really have to try soon. I have an older PIC32 board at home, but accessing its UART requires a connector that is hard to find and even harder to solder, so I didn't touch it yet (although PIC32 has been on eLua's TOPORT list for quite a while now). This is one thing about Microchip's PIC32 boards that annoys me quite a bit: in order to have a proper development environment for eLua (an UART, to be more precise), I'd have to buy the PIC32 board (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en535536) which should be then stuck in a PIC32 I/O expansion board (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en535444) and I still have to use some sort of daugherboard in that one to get a serial connector (if I don't feel like soldering, that is).
That said, I have to check if I can't use one of the on-board USB connections as a CDC, this might simplify things quite a bit. I don't think I have the time to develop a CDC device on PIC32 myself, but maybe they have something like this in their software library. And who knows, maybe they're even willing to sponsor us. Thanks for the hint! I had no idea about this new line (new to me, as least :) ) of PIC32 devices.

3. If you want to go for broke, Renesas has the SH7216 series with 200MHz speed, FPU, 128K SRAM and 1024K flash -- but as usual with Renesas, availability is poor and the price is high (Digikey only lists one model, not in stock, for $42.27 qty 1).

If they're not easily available in the US, chances are they aren't available at all in Europe. I found it quite hard to find Renesas products in Europe. Still, this chip sounds SWEET. Especially the FPU part.

4. Someday Renesas promises they'll have a new RX600 MCU with 256K SRAM and 4M flash. On the good side, Renesas does make a lot of very capable MCUs in QFPs. But, I'm not holding my breath waiting for availability (my guess is it's at least several years away).

You're probably right, but it's very good to see this "more on-board RAM and Flash" trend. Very nice for eLua, as we all know :)

Best,
Bogdan

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

John Hind

Re: Single Chip Lua Prospects

In reply to this post by BogdanM

I had a look at the datasheet last night. It looks ideal (on paper) – the USB is actually capable of Host/Device/On-The-Go, so it could actually host a MSD as well as acting as one (64GB anyone?). The Microchip stack does have CDC also.

I prefer HID over CDC for two reasons: On Windows virtual Com ports tend to shuffle about at random and it is difficult to write host-side software that can find the port number reliably in all circumstances without bothering the user with technical details. Secondly, using HID allows the device to emulate keyboard/mouse/game controllers without software on the host computer. Microchip actually have two bootloader implementations one of which uses HID and the other their own profile.

The Microchip stack also supports DOS file system in program memory (accessible via MSD and the microcontroller app) which should simplify implementation. Putting the Lua scripts in this file system with an “autorun.lua” seems a good way forward to me – keeps things really simple and cross-platform on the host computer.

From: [hidden email] [mailto:[hidden email]] On Behalf Of Bogdan Marinescu
Sent: 06 March 2010 12:26
To: eLua Users and Development List (www.eluaproject.net)
Subject: Re: [eLua-dev] Single Chip Lua Prospects

On Sat, Mar 6, 2010 at 12:09 PM, John Hind <[hidden email]> wrote:

I must look at PIC32 again myself! But is the serial port really necessary? The MX chips have USB and the (free) Microchip USB stack does Mass Storage Device as well as Human Interface Device (at least on the PIC 18 it does and it will even do both at once).

Similar to the Mbed, would it not be possible to make the chip mount as a disk drive on the host computer and edit the script files directly in place?

Ideally there could be a switch on the board and you’d flip it one way for MSD to load your scripts and flip it the other way to run the scripts with access to USB as HID so you could create USB devices.

I wouldn't go the HID way if I can do CDC. I don't see the point.

Time for another look, I think – Thanks Tony!

Yeah, my thoughts exactly :)

Best,
Bogdan

From: [hidden email] [mailto:[hidden email]] On Behalf Of Bogdan Marinescu
Sent: 05 March 2010 10:10
To: eLua Users and Development List (www.eluaproject.net)

Subject: Re: [eLua-dev] Single Chip Lua Prospects

Thanks for all the good news, Tony! You made my day.

On Fri, Mar 5, 2010 at 1:07 AM, Tony <[hidden email]> wrote:

Even more single-chip eLua candidates are coming, so the situation is a bit better than last year.

1. ST has expanded the STM32 Performance line with models with 96K SRAM and 768K or 1024K flash; packages include a 64-pin QFP. Not sure on availability, but should be fairly soon.

Excellent. I really like the STM32s. If their next step is to bump the RAM to 128k, I'll probably marry that chip (sorry, wife). 96k is good enough though, I have a board with a STM32F103RE (512kF/32kR) and it can do a lot of nice stuff.

2. Microchip has PIC32MX MCUs with 128K SRAM and 512K flash in a QFP-64.

WOW! Now this is something I really have to try soon. I have an older PIC32 board at home, but accessing its UART requires a connector that is hard to find and even harder to solder, so I didn't touch it yet (although PIC32 has been on eLua's TOPORT list for quite a while now). This is one thing about Microchip's PIC32 boards that annoys me quite a bit: in order to have a proper development environment for eLua (an UART, to be more precise), I'd have to buy the PIC32 board (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en535536) which should be then stuck in a PIC32 I/O expansion board (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en535444) and I still have to use some sort of daugherboard in that one to get a serial connector (if I don't feel like soldering, that is).
That said, I have to check if I can't use one of the on-board USB connections as a CDC, this might simplify things quite a bit. I don't think I have the time to develop a CDC device on PIC32 myself, but maybe they have something like this in their software library. And who knows, maybe they're even willing to sponsor us. Thanks for the hint! I had no idea about this new line (new to me, as least :) ) of PIC32 devices.

3. If you want to go for broke, Renesas has the SH7216 series with 200MHz speed, FPU, 128K SRAM and 1024K flash -- but as usual with Renesas, availability is poor and the price is high (Digikey only lists one model, not in stock, for $42.27 qty 1).

If they're not easily available in the US, chances are they aren't available at all in Europe. I found it quite hard to find Renesas products in Europe. Still, this chip sounds SWEET. Especially the FPU part.

4. Someday Renesas promises they'll have a new RX600 MCU with 256K SRAM and 4M flash. On the good side, Renesas does make a lot of very capable MCUs in QFPs. But, I'm not holding my breath waiting for availability (my guess is it's at least several years away).

You're probably right, but it's very good to see this "more on-board RAM and Flash" trend. Very nice for eLua, as we all know :)

Best,
Bogdan

--Tony

On Mon, Jun 22, 2009 at 2:42 AM, John Hind <[hidden email]> wrote:

When I subscribed to this list half a year ago I confidently expected to be able to use a single chip Lua device in my projects by now. I wanted to use many such chips in a seriously distributed architecture with the processing kept near to the IO to simplify wiring. To avoid buying an endless succession of development boards I set a simple threshold specification of 512K on-chip flash, 64K on-chip RAM, Ethernet capability (I was prepared to compromise with a second chip for this). With this type of distributed architecture, I need lots of IO versatility (analog, PWM, UART, I2C, SPI, counters etc.) but multiplexed on relatively few pins since if you run out of IO you just add another chip. It should therefore be possible to have a simple 20-40 pin package which could be available in hand-solderable form.

It is very disappointing that after many months still the only chip that comes near is the LPC2888 which seems to be buggy and expensive (the very minimalist LPC-H2888 prototype board is over $150). Looking at the schematics for this board really reinforced my intuition about the importance of on-chip memory – a ridiculous number of pins (and therefore PCB traces) is wasted on the external memory interface. And the economics are terrible - for just $20 more, you can get the new Acer Aspire Revo R3600 nettop (in Linux rather than Vista trim). The latter has both wired and wireless networking, 1GB RAM and an 8GB SSD!

IO is the problem of course with an X86 platform. However in my research I found this incredibly poorly marketed chip:

http://delcomproduct.com/products_USBIO.asp#DemoBrd

A versatile USB to IO pins chip for only $8! This looks like great universal IO problem solver. Unlike most other DIY USB solutions I’ve seen which require a driver and/or serial port emulator, this is HID based and therefore driverless on all major OS’s. I have ordered some of these chips and will report back how it goes.

I am beginning to think it might just be better to cooperate with market forces here since I suspect that X86 computing is going to keep widening the functionality gap and reducing the price gap. Rather than trying to squeeze Lua onto a cramped chip with no operating system, would it maybe be better to produce a custom cut-down Linux distro with Lua built in (and perhaps acting as the shell)?

What do others think? Will there be cheap, single chip ARM devices meeting my spec available in the next few months?

_______________________________________________
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

John Hind

Re: Single Chip Lua Prospects

In reply to this post by jbsnyder

Yes, the PIC32 has a dedicated bootloader flash memory on top of the 64MB
program memory. The Microchip USB stack has both HID based and proprietary
bootloaders. I'm not sure if the chip is shipped with a bootloader already
programmed. As far as I can see the PIC32 USB can do CDC, HID and MSD either
as host or device without any external hardware. It does need an external
MAC chip for Ethernet, which is a slight minus point.

The Microchip starter kits do use a separate USB - JTAG programmer chip
(another PIC32, which seems like overkill!), so maybe there is some gotcha
lurking!

> -----Original Message-----
> From: [hidden email] [mailto:elua-dev-
> [hidden email]] On Behalf Of James Snyder
> Sent: 06 March 2010 21:40
> To: eLua Users and Development List (www.eluaproject.net)
> Subject: Re: [eLua-dev] Single Chip Lua Prospects
>
> On Sat, Mar 6, 2010 at 4:09 AM, John Hind <[hidden email]> wrote:
> > I must look at PIC32 again myself! But is the serial port really
> necessary?
> > The MX chips have USB and the (free) Microchip USB stack does Mass
> Storage
> > Device as well as Human Interface Device (at least on the PIC 18 it
> does and
> > it will even do both at once). Similar to the Mbed, would it not be
> possible
> > to make the chip mount as a disk drive on the host computer and edit
> the
> > script files directly in place?
>
> FYI the way the MBED does this is by having 2 chips on the board, one
> is the main NXP LPC1768, and the other one is the "mbed interface"
> (another nxp mcu), and it's the interface one that's dedicated to
> providing mass storage and the CDC (virtual serial port). The other
> chip, I believe, doesn't have any direct connection to the USB port,
> and doesn't need to know about it either. Programming is done by a
> JTAG link between the interface chip and the main LPC1768.
>
> Does the PIC32 have a USB bootloader for programming as well, that
> would make this even more convenient.
>
> > Ideally there could be a switch on the board and youd flip it one
> way for
> > MSD to load your scripts and flip it the other way to run the scripts
> with
> > access to USB as HID so you could create USB devices.
>
> You could also handle this in software where depending on whether the
> mass storage device has been mounted on one side or the other, the
> storage would be locked out for the opposite side (or read-only?).
>
> >
> >
> >
> > Time for another look, I think Thanks Tony!
> >
> >
> >
> > From: [hidden email]
> > [mailto:[hidden email]] On Behalf Of Bogdan
> Marinescu
> > Sent: 05 March 2010 10:10
> > To: eLua Users and Development List (www.eluaproject.net)
> >
> > Subject: Re: [eLua-dev] Single Chip Lua Prospects
> >
> >
> >
> > Thanks for all the good news, Tony! You made my day.
> >
> > On Fri, Mar 5, 2010 at 1:07 AM, Tony <[hidden email]> wrote:
> >
> > Even more single-chip eLua candidates are coming, so the situation is
> a bit
> > better than last year.
> >
> > 1. ST has expanded the STM32 Performance line with models with 96K
> SRAM and
> > 768K or 1024K flash; packages include a 64-pin QFP. Not sure on
> > availability, but should be fairly soon.
> >
> > Excellent. I really like the STM32s. If their next step is to bump
> the RAM
> > to 128k, I'll probably marry that chip (sorry, wife). 96k is good
> enough
> > though, I have a board with a STM32F103RE (512kF/32kR) and it can do
> a lot
> > of nice stuff.
> >
> >
> > 2. Microchip has PIC32MX MCUs with 128K SRAM and 512K flash in a QFP-
> 64.
> >
> > WOW! Now this is something I really have to try soon. I have an older
> PIC32
> > board at home, but accessing its UART requires a connector that is
> hard to
> > find and even harder to solder, so I didn't touch it yet (although
> PIC32 has
> > been on eLua's TOPORT list for quite a while now). This is one thing
> about
> > Microchip's PIC32 boards that annoys me quite a bit: in order to have
> a
> > proper development environment for eLua (an UART, to be more
> precise), I'd
> > have to buy the PIC32 board
> >
> (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId
> =2615&dDocName=en535536)
> > which should be then stuck in a PIC32 I/O expansion board
> >
> (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId
> =2615&dDocName=en535444)
> > and I still have to use some sort of daugherboard in that one to get
> a
> > serial connector (if I don't feel like soldering, that is).
> > That said, I have to check if I can't use one of the on-board USB
> > connections as a CDC, this might simplify things quite a bit. I don't
> think
> > I have the time to develop a CDC device on PIC32 myself, but maybe
> they have
> > something like this in their software library. And who knows, maybe
> they're
> > even willing to sponsor us. Thanks for the hint! I had no idea about
> this
> > new line (new to me, as least :) ) of PIC32 devices.
> >
> > 3. If you want to go for broke, Renesas has the SH7216 series with
> 200MHz
> > speed, FPU, 128K SRAM and 1024K flash -- but as usual with Renesas,
> > availability is poor and the price is high (Digikey only lists one
> model,
> > not in stock, for $42.27 qty 1).
> >
> > If they're not easily available in the US, chances are they aren't
> available
> > at all in Europe. I found it quite hard to find Renesas products in
> Europe.
> > Still, this chip sounds SWEET. Especially the FPU part.
> >
> >
> > 4. Someday Renesas promises they'll have a new RX600 MCU with 256K
> SRAM and
> > 4M flash. On the good side, Renesas does make a lot of very capable
> MCUs in
> > QFPs. But, I'm not holding my breath waiting for availability (my
> guess is
> > it's at least several years away).
> >
> > You're probably right, but it's very good to see this "more on-board
> RAM and
> > Flash" trend. Very nice for eLua, as we all know :)
> >
> > Best,
> > Bogdan
> >
> >
> > --Tony
> >
> > On Mon, Jun 22, 2009 at 2:42 AM, John Hind <[hidden email]>
> wrote:
> >
> > When I subscribed to this list half a year ago I confidently expected
> to be
> > able to use a single chip Lua device in my projects by now. I wanted
> to use
> > many such chips in a seriously distributed architecture with the
> processing
> > kept near to the IO to simplify wiring. To avoid buying an endless
> > succession of development boards I set a simple threshold
> specification of
> > 512K on-chip flash, 64K on-chip RAM, Ethernet capability (I was
> prepared to
> > compromise with a second chip for this). With this type of
> distributed
> > architecture, I need lots of IO versatility (analog, PWM, UART, I2C,
> SPI,
> > counters etc.) but multiplexed on relatively few pins since if you
> run out
> > of IO you just add another chip. It should therefore be possible to
> have a
> > simple 20-40 pin package which could be available in hand-solderable
> form.
> >
> >
> >
> > It is very disappointing that after many months still the only chip
> that
> > comes near is the LPC2888 which seems to be buggy and expensive (the
> very
> > minimalist LPC-H2888 prototype board is over $150). Looking at the
> > schematics for this board really reinforced my intuition about the
> > importance of on-chip memory a ridiculous number of pins (and
> therefore
> > PCB traces) is wasted on the external memory interface. And the
> economics
> > are terrible - for just $20 more, you can get the new Acer Aspire
> Revo R3600
> > nettop (in Linux rather than Vista trim). The latter has both wired
> and
> > wireless networking, 1GB RAM and an 8GB SSD!
> >
> >
> >
> > IO is the problem of course with an X86 platform. However in my
> research I
> > found this incredibly poorly marketed chip:
> >
> >
> >
> > http://delcomproduct.com/products_USBIO.asp#DemoBrd
> >
> >
> >
> > A versatile USB to IO pins chip for only $8! This looks like great
> universal
> > IO problem solver. Unlike most other DIY USB solutions Ive seen
> which
> > require a driver and/or serial port emulator, this is HID based and
> > therefore driverless on all major OSs. I have ordered some of these
> chips
> > and will report back how it goes.
> >
> >
> >
> > I am beginning to think it might just be better to cooperate with
> market
> > forces here since I suspect that X86 computing is going to keep
> widening the
> > functionality gap and reducing the price gap. Rather than trying to
> squeeze
> > Lua onto a cramped chip with no operating system, would it maybe be
> better
> > to produce a custom cut-down Linux distro with Lua built in (and
> perhaps
> > acting as the shell)?
> >
> >
> >
> > What do others think? Will there be cheap, single chip ARM devices
> meeting
> > my spec available in the next few months?
> >
> >
> >
> >
> >
> > _______________________________________________
> > 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
> >
> >
>
>
>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> [hidden email]
> PGP: http://fanplastic.org/key.txt
> Phone: (847) 448-0386
> _______________________________________________
> 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

John Hind

Re: Single Chip Lua Prospects

In reply to this post by Tony-12

Yes, the PIC32 is a bit of a departure for Microchip in a number of directions. Note however that unlike the rest of the industry using ARM, Microchip have hone with a MIPS core – not sure if this will cause any problems for an eLua port?

From: [hidden email] [mailto:[hidden email]] On Behalf Of Tony
Sent: 07 March 2010 21:27
To: eLua Users and Development List (www.eluaproject.net)
Subject: Re: [eLua-dev] Single Chip Lua Prospects

On Sat, Mar 6, 2010 at 2:09 AM, John Hind <[hidden email]> wrote:

Time for another look, I think – Thanks Tony!

From: [hidden email] [mailto:[hidden email]] On Behalf Of Bogdan Marinescu
Sent: 05 March 2010 10:10
To: eLua Users and Development List (www.eluaproject.net)

Subject: Re: [eLua-dev] Single Chip Lua Prospects

Thanks for all the good news, Tony! You made my day.

On Fri, Mar 5, 2010 at 1:07 AM, Tony <[hidden email]> wrote:

2. Microchip has PIC32MX MCUs with 128K SRAM and 512K flash in a QFP-64.

3. If you want to go for broke, Renesas has the SH7216 series with 200MHz speed, FPU, 128K SRAM and 1024K flash -- but as usual with Renesas, availability is poor and the price is high (Digikey only lists one model, not in stock, for $42.27 qty 1).

4. Someday Renesas promises they'll have a new RX600 MCU with 256K SRAM and 4M flash. On the good side, Renesas does make a lot of very capable MCUs in QFPs. But, I'm not holding my breath waiting for availability (my guess is it's at least several years away).

You're probably right, but it's very good to see this "more on-board RAM and Flash" trend. Very nice for eLua, as we all know :)

Best,
Bogdan

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

BogdanM

Re: Single Chip Lua Prospects

In reply to this post by Tony-12

On Mon, Mar 8, 2010 at 11:24 AM, John Hind <[hidden email]> wrote:

Yes, the PIC32 is a bit of a departure for Microchip in a number of directions. Note however that unlike the rest of the industry using ARM, Microchip have hone with a MIPS core – not sure if this will cause any problems for an eLua port?

Not sure yet. The toolchain is GCC based, so no problems here. We might have troubles with the C library, I don't know what Microchip uses. If it's not Newlib, we're gonna have to either get Newlib on PIC32, or adapt eLua's console I/O and filesystems to another libc.

Best,
Bogdan

From: [hidden email] [mailto:[hidden email]] On Behalf Of Tony
Sent: 07 March 2010 21:27

To: eLua Users and Development List (www.eluaproject.net)
Subject: Re: [eLua-dev] Single Chip Lua Prospects

I'm glad to be the catalyst for a PIC32 port; I do think the PIC32MX795F512H looks pretty interesting. I was very surprised that Microchip included so much RAM, because in the past PIC micros have been pretty light on RAM.

It looks like the PIC32MX795F512's are just starting to reach the distributors (e.g. Mouser USA has 10 in stock).

Another bit of news: Atmel is working on a single precision FPU for the AVR32 U3 series. Since no parts were announced, it'll be a while (my guess: >2 years to reach distribution). But a AVR32U3 series with >= 128K SRAM and FPU would be pretty sweet.

--Tony

On Sat, Mar 6, 2010 at 2:09 AM, John Hind <[hidden email]> wrote:

I must look at PIC32 again myself! But is the serial port really necessary? The MX chips have USB and the (free) Microchip USB stack does Mass Storage Device as well as Human Interface Device (at least on the PIC 18 it does and it will even do both at once). Similar to the Mbed, would it not be possible to make the chip mount as a disk drive on the host computer and edit the script files directly in place?

Ideally there could be a switch on the board and you’d flip it one way for MSD to load your scripts and flip it the other way to run the scripts with access to USB as HID so you could create USB devices.

Time for another look, I think – Thanks Tony!

From: [hidden email] [mailto:[hidden email]] On Behalf Of Bogdan Marinescu
Sent: 05 March 2010 10:10
To: eLua Users and Development List (www.eluaproject.net)

Subject: Re: [eLua-dev] Single Chip Lua Prospects

Thanks for all the good news, Tony! You made my day.

On Fri, Mar 5, 2010 at 1:07 AM, Tony <[hidden email]> wrote:

Even more single-chip eLua candidates are coming, so the situation is a bit better than last year.

1. ST has expanded the STM32 Performance line with models with 96K SRAM and 768K or 1024K flash; packages include a 64-pin QFP. Not sure on availability, but should be fairly soon.

Excellent. I really like the STM32s. If their next step is to bump the RAM to 128k, I'll probably marry that chip (sorry, wife). 96k is good enough though, I have a board with a STM32F103RE (512kF/32kR) and it can do a lot of nice stuff.

2. Microchip has PIC32MX MCUs with 128K SRAM and 512K flash in a QFP-64.

WOW! Now this is something I really have to try soon. I have an older PIC32 board at home, but accessing its UART requires a connector that is hard to find and even harder to solder, so I didn't touch it yet (although PIC32 has been on eLua's TOPORT list for quite a while now). This is one thing about Microchip's PIC32 boards that annoys me quite a bit: in order to have a proper development environment for eLua (an UART, to be more precise), I'd have to buy the PIC32 board (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en535536) which should be then stuck in a PIC32 I/O expansion board (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2615&dDocName=en535444) and I still have to use some sort of daugherboard in that one to get a serial connector (if I don't feel like soldering, that is).
That said, I have to check if I can't use one of the on-board USB connections as a CDC, this might simplify things quite a bit. I don't think I have the time to develop a CDC device on PIC32 myself, but maybe they have something like this in their software library. And who knows, maybe they're even willing to sponsor us. Thanks for the hint! I had no idea about this new line (new to me, as least :) ) of PIC32 devices.

3. If you want to go for broke, Renesas has the SH7216 series with 200MHz speed, FPU, 128K SRAM and 1024K flash -- but as usual with Renesas, availability is poor and the price is high (Digikey only lists one model, not in stock, for $42.27 qty 1).

If they're not easily available in the US, chances are they aren't available at all in Europe. I found it quite hard to find Renesas products in Europe. Still, this chip sounds SWEET. Especially the FPU part.

4. Someday Renesas promises they'll have a new RX600 MCU with 256K SRAM and 4M flash. On the good side, Renesas does make a lot of very capable MCUs in QFPs. But, I'm not holding my breath waiting for availability (my guess is it's at least several years away).

You're probably right, but it's very good to see this "more on-board RAM and Flash" trend. Very nice for eLua, as we all know :)

Best,
Bogdan

_______________________________________________
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

Ross Berteig

Re: Single Chip Lua Prospects

In reply to this post by Tony-12

Sometime on 3/8/2010, John Hind wrote:
>I prefer HID over CDC for two reasons: On Windows virtual Com
>ports tend to shuffle about at random and it is difficult to
>write host-side software that can find the port number reliably
>in all circumstances without bothering the user with technical
>details.

The secret to preventing Windows from doing the COM port
assignment shuffle is to give every CDC device a unique serial
number descriptor. Without the serial number, Windows has to rely
on its internal name of the upstream USB port to which the device
is connected. If you move the device to a different port, then it
sees it as a new device, reloads the drivers, and reassigns the
COM port.

I don't know how easy Microchip makes it to do this. Ideally, it
would be easy to generate a serial number at runtime from some
factory guaranteed unique value (the FTDI chips do this, for
instance). Otherwise, you would have to provide for serializing
the devices as or after firmware is loaded.

Ross Berteig [hidden email]
Cheshire Engineering Corp. http://www.CheshireEng.com/

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

John Hind

Re: Single Chip Lua Prospects

I've never used Microchip CDC. If you have control of both ends why add the
complexity of emulating a serial link? I have used USB - Serial converters
to use Microchip serial ports with PCs without "real" serial ports. I
certainly recommend FTDI-based converters these days because their drivers
seem more stable on Vista and 7. They do seem better from a port shuffle
basis also. However you still have to find the serial port number in the
first place. The only way the user can find it is to interpret the highly
technical Device Manager and it is hard to write reliable automatic probes
because you do not know what other serial devices may be connected. In my
experience, using CDC virtually guarantees high support costs.

Besides this, writing good serial port code on a PC is difficult even
without emulation in the picture - I've virtually built a career fixing
badly written com port code!

> -----Original Message-----
> From: [hidden email] [mailto:elua-dev-
> [hidden email]] On Behalf Of Ross Berteig
> Sent: 08 March 2010 22:26
> To: [hidden email]
> Subject: Re: [eLua-dev] Single Chip Lua Prospects
>
> Sometime on 3/8/2010, John Hind wrote:
> >I prefer HID over CDC for two reasons: On Windows virtual Com
> >ports tend to shuffle about at random and it is difficult to
> >write host-side software that can find the port number reliably
> >in all circumstances without bothering the user with technical
> >details.
>
> The secret to preventing Windows from doing the COM port
> assignment shuffle is to give every CDC device a unique serial
> number descriptor. Without the serial number, Windows has to rely
> on its internal name of the upstream USB port to which the device
> is connected. If you move the device to a different port, then it
> sees it as a new device, reloads the drivers, and reassigns the
> COM port.
>
> I don't know how easy Microchip makes it to do this. Ideally, it
> would be easy to generate a serial number at runtime from some
> factory guaranteed unique value (the FTDI chips do this, for
> instance). Otherwise, you would have to provide for serializing
> the devices as or after firmware is loaded.
>
> Ross Berteig [hidden email]
> Cheshire Engineering Corp. http://www.CheshireEng.com/
>
> _______________________________________________
> 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

Re: Single Chip Lua Prospects

In reply to this post by Ross Berteig

On Tue, Mar 9, 2010 at 11:08 AM, John Hind <[hidden email]> wrote:

I've never used Microchip CDC. If you have control of both ends why add the
complexity of emulating a serial link?

I don't really want to _emulate_ a serial link, I just _want_ a serial link :) I actually do quite a bit of prototyping from within the eLua shell (which is one of the main ideas behind eLua), and I'd rather not give up this feature. And the new (exciting IMO) things that are coming to eLua also require a serial port, and they use it quite a lot. Of course, other people might find it easier and/or more convenient to do everything without a serial, but for me it's almost indispensable.

I have used USB - Serial converters
to use Microchip serial ports with PCs without "real" serial ports. I
certainly recommend FTDI-based converters these days because their drivers
seem more stable on Vista and 7. They do seem better from a port shuffle
basis also. However you still have to find the serial port number in the
first place. The only way the user can find it is to interpret the highly
technical Device Manager and it is hard to write reliable automatic probes
because you do not know what other serial devices may be connected.

I actually wrote a piece of code that detects only FTDI adapters a while ago. "Wrote" is a bit of an overstatement, because I just used some code I found on CodeProject :) If you want, I can send the relevant part of the code to you. Didn't use it in a while, but I remember that it worked quite well. And I'm quite sure it can be extended to recognize a broader range of devices, if needed.

In my experience, using CDC virtually guarantees high support costs.

I never had any problems with them. As long as one uses good quality USB to serial adapters (FTDIs being a very good example) everything seems to work fine. On the other hand, I never tested a microcontroller based CDC solution, and there's a very good chance that they don't perform equally well.

Besides this, writing good serial port code on a PC is difficult even
without emulation in the picture - I've virtually built a career fixing
badly written com port code!

eLua is going to release a cross platform serial library soon, so this problem will be over! :)

Best,
Bogdan

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]

> [hidden email]] On Behalf Of Ross Berteig
> Sent: 08 March 2010 22:26
> To: [hidden email]
> Subject: Re: [eLua-dev] Single Chip Lua Prospects
>

> Sometime on 3/8/2010, John Hind wrote:
> >I prefer HID over CDC for two reasons: On Windows virtual Com
> >ports tend to shuffle about at random and it is difficult to
> >write host-side software that can find the port number reliably
> >in all circumstances without bothering the user with technical
> >details.
>
> The secret to preventing Windows from doing the COM port
> assignment shuffle is to give every CDC device a unique serial
> number descriptor. Without the serial number, Windows has to rely
> on its internal name of the upstream USB port to which the device
> is connected. If you move the device to a different port, then it
> sees it as a new device, reloads the drivers, and reassigns the
> COM port.
>
> I don't know how easy Microchip makes it to do this. Ideally, it
> would be easy to generate a serial number at runtime from some
> factory guaranteed unique value (the FTDI chips do this, for
> instance). Otherwise, you would have to provide for serializing
> the devices as or after firmware is loaded.
>
> Ross Berteig [hidden email]
> Cheshire Engineering Corp. http://www.CheshireEng.com/
>
> _______________________________________________
> 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

Re: Single Chip Lua Prospects

In reply to this post by Ross Berteig

On Tue, Mar 9, 2010 at 3:08 AM, John Hind <[hidden email]> wrote:

> I've never used Microchip CDC. If you have control of both ends why add the
> complexity of emulating a serial link? I have used USB - Serial converters
> to use Microchip serial ports with PCs without "real" serial ports. I
> certainly recommend FTDI-based converters these days because their drivers
> seem more stable on Vista and 7. They do seem better from a port shuffle
> basis also. However you still have to find the serial port number in the
> first place. The only way the user can find it is to interpret the highly
> technical Device Manager and it is hard to write reliable automatic probes
> because you do not know what other serial devices may be connected. In my
> experience, using CDC virtually guarantees high support costs.

I'm not so sure about this. Arduino uses an FTDI virtual serial port,
and seems to do just fine with this. I'm forgetting what it's like
out of the box to figure out which port is the correct one, but I seem
to recall there just being some minimal instructions, and certainly
after it's first been attached it gets the same COM port on Windows,
and the same device name on OS X.

MBED uses a CDC that runs from an LPC microcontroller, and as far as I
recall it retains its name on OS X between connections w/ no driver,
for Windows they now provide some sort of additional "driver" which I
presume gives one a permanent COM port number, but it definitely gives
it a name in the device manager that makes it easy to pick out: "mbed
Serial Port"):
http://mbed.org/handbook/SerialPC

I suppose it depends on the interaction model desired, but if what one
wants is a tty, I suspect that presenting as an HID is going to make
it more complicated to support different platforms. One would either
have to provide a driver on each platform or use something like libusb
to talk to it, and then unless you've made it available as a COM port
you're likely going to provide an application that gives you a serial
terminal over the HID or whatever interaction model is desired. I
feel as if one is trading a bit of explanation about how to find a
serial port for a fair bit of code, testing and packaging. I
certainly see the value of this when rolling something out to
non-technical users or for making it easy to turn an eLua
microcontroller into an HID, but I guess I don't see the advantage
provided by making this the primary interaction model.

> Besides this, writing good serial port code on a PC is difficult even
> without emulation in the picture - I've virtually built a career fixing
> badly written com port code!

I have less experience with Windows, but I could certainly see how one
could end up in this situation with the POSIX serial model. As Bogdan
has noted, we'll be including some serial port library code so at
least there could be some standardization on what methods are used
while reading/writing to/from eLua devices.

>
>> -----Original Message-----
>> From: [hidden email] [mailto:elua-dev-
>> [hidden email]] On Behalf Of Ross Berteig
>> Sent: 08 March 2010 22:26
>> To: [hidden email]
>> Subject: Re: [eLua-dev] Single Chip Lua Prospects
>>
>> Sometime on 3/8/2010, John Hind wrote:
>> >I prefer HID over CDC for two reasons: On Windows virtual Com
>> >ports tend to shuffle about at random and it is difficult to
>> >write host-side software that can find the port number reliably
>> >in all circumstances without bothering the user with technical
>> >details.
>>
>> The secret to preventing Windows from doing the COM port
>> assignment shuffle is to give every CDC device a unique serial
>> number descriptor. Without the serial number, Windows has to rely
>> on its internal name of the upstream USB port to which the device
>> is connected. If you move the device to a different port, then it
>> sees it as a new device, reloads the drivers, and reassigns the
>> COM port.
>>
>> I don't know how easy Microchip makes it to do this. Ideally, it
>> would be easy to generate a serial number at runtime from some
>> factory guaranteed unique value (the FTDI chips do this, for
>> instance). Otherwise, you would have to provide for serializing
>> the devices as or after firmware is loaded.
>>
>> Ross Berteig [hidden email]
>> Cheshire Engineering Corp. http://www.CheshireEng.com/
>>
>> _______________________________________________
>> 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
>

John Hind

Re: Single Chip Lua Prospects

You are right of course, if you actually *want* a tty interaction model, CDC
has the edge. But are you sure this really is the base requirement? Mostly I
see one of the following: File transfer, which would be a packetized layer
on top of tty (such as X-Modem) and in the USB world would be better done
with MSD; and proprietary packetized command/response protocols for
debuggers or computer peripherals like GPS or PLC like devices (which would
be better done with HID or a custom USB profile).

Conceptually the problem with RS232/ASCII/tty is that it is not a complete
communications stack except for the intended teletype application. All the
actual modern applications require additional layers on top. In contrast,
the USB profiles are complete specifications right up to the application
layer.

The clincher for me is that you can do HID and MSD on any modern platform
without an additional device driver. I'm not sure why, or if this is just a
Windows problem, but you do need to source and install a manufacturer
specific device driver to do CDC. If you stick with FTDI-based devices, the
driver seems to be OK, but I have had endless problems with the (more common
in over-the-counter USB-Serial converters) Prolific chip drivers on Vista
and Windows 7.

> -----Original Message-----
> From: [hidden email] [mailto:elua-dev-
> [hidden email]] On Behalf Of James Snyder
> Sent: 09 March 2010 19:43
> To: eLua Users and Development List (www.eluaproject.net)
> Subject: Re: [eLua-dev] Single Chip Lua Prospects
>
> I suppose it depends on the interaction model desired, but if what one
> wants is a tty, I suspect that presenting as an HID is going to make
> it more complicated to support different platforms
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> [hidden email]
> PGP: http://fanplastic.org/key.txt
> Phone: (847) 448-0386
> _______________________________________________
> 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

Re: Single Chip Lua Prospects

In reply to this post by jbsnyder

You are right of course, if you actually *want* a tty interaction model, CDC
has the edge. But are you sure this really is the base requirement?

It is for me, and I explained why in a previous e-mail: prototyping. There are others too, read below.

Mostly I
see one of the following: File transfer, which would be a packetized layer
on top of tty (such as X-Modem)

Actually, after playing a bit with eLua, I realized that file transfer via X/Y/ZModem is extremely annoying. Doing the receive operation over and over again while prototyping can easily become extremely annoying. It's not just my impression, many other people have confirmed this. We have a much better alternative in the works (already functional actually), but I'm keeping this as a surprise for now :) And yes, it uses the serial port like crazy.

and in the USB world would be better done
with MSD;

and proprietary packetized command/response protocols for
debuggers or computer peripherals like GPS or PLC like devices (which would
be better done with HID or a custom USB profile).

Conceptually the problem with RS232/ASCII/tty is that it is not a complete
communications stack except for the intended teletype application. All the
actual modern applications require additional layers on top. In contrast,
the USB profiles are complete specifications right up to the application
layer.

This didn't bother me so far. In the way I use a serial port, a CDC profile and an actual hardware RS232 port are perfectly equivalent for me.

The clincher for me is that you can do HID and MSD on any modern platform
without an additional device driver. I'm not sure why, or if this is just a
Windows problem, but you do need to source and install a manufacturer
specific device driver to do CDC. If you stick with FTDI-based devices, the
driver seems to be OK, but I have had endless problems with the (more common
in over-the-counter USB-Serial converters) Prolific chip drivers on Vista
and Windows 7.

I think serial ports simply don't like you :) I have a Prolific (PL-2303 based) adapter that I use with all my eLua boards, and it never gave me any problems on any of the OSes I used it on (Linux, XP, Vista, W7). Are you on W7 64bits by any chance?

Best,
Bogdan

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]

> [hidden email]] On Behalf Of James Snyder
> Sent: 09 March 2010 19:43
> To: eLua Users and Development List (www.eluaproject.net)

> Subject: Re: [eLua-dev] Single Chip Lua Prospects
>

> I suppose it depends on the interaction model desired, but if what one
> wants is a tty, I suspect that presenting as an HID is going to make
> it more complicated to support different platforms

> --

> James Snyder
> Biomedical Engineering
> Northwestern University
> [hidden email]
> PGP: http://fanplastic.org/key.txt
> Phone: (847) 448-0386
> _______________________________________________
> 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

Re: Single Chip Lua Prospects

In reply to this post by jbsnyder

On Thu, Mar 11, 2010 at 3:52 AM, John Hind <[hidden email]> wrote:
> You are right of course, if you actually *want* a tty interaction model, CDC
> has the edge. But are you sure this really is the base requirement? Mostly I
> see one of the following: File transfer, which would be a packetized layer
> on top of tty (such as X-Modem) and in the USB world would be better done
> with MSD; and proprietary packetized command/response protocols for
> debuggers or computer peripherals like GPS or PLC like devices (which would
> be better done with HID or a custom USB profile).

I would certainly agree that for file transfer and various packetized
protocols, various USB profiles are certainly going to provide a more
reliable and higher throughput option compared with something like
RS232 or CDC. But I suppose the question needs to be answered: "What
interaction models do we want?"

I think being able to do MSD dramatically simplifies the concept of
transferring data back and forth (though it has downsides like 2
devices can't mount it at the same time). I'm not sure what of any
proprietary packetized formats might make sense for us in a general
sense, since a lot of those are geared towards one particular use.
Perhaps there are open ones as well, beyond the basic device classes
that might make for a generalized programmatic interface we could
provide, but none are coming to mind at the moment.

Right now our development paradigm involves either working with eLua
over a serial console as a command-line shell/interpreter or using
something like LuaRPC for a programmatic interaction model with a VM
running on the microcontroller. Certainly for the former, I think a
CDC (or similar) makes the most sense, and I would argue that having a
device class like this is always going to be useful on some level if
for nothing else that it provides a really easy way to make ad-hoc
communications between the embedded device and a desktop. Getting
some data from a device is as simple as opening a terminal and having
some print statements in the program. It might not be very
sophisticated, but it's a nice fallback when one is getting started or
wants to get quick details about program operation

Now, I could definitely see the benefit of using some sort of
packetized usb-based communication channel for supporting LuaRPC, it
would be less complicated (presumably) than using TCP/IP and it would
give you better throughput, latency, etc and would provide an
extensible model for user and developer interaction without having to
delve into the details of how the USB link works. I would still want
some sort of tty-like interface as a fallback, though.

>
> Conceptually the problem with RS232/ASCII/tty is that it is not a complete
> communications stack except for the intended teletype application. All the
> actual modern applications require additional layers on top. In contrast,
> the USB profiles are complete specifications right up to the application
> layer.

Right, I would agree. Especially without the control lines it has
pitfalls, especially with large quantities of data transmission and
small buffers, but so far it's actually worked reasonably well for us.

>
> The clincher for me is that you can do HID and MSD on any modern platform
> without an additional device driver.

I'm not sure if I'm missing something, but if one wants to use HID and
present as something other than a mouse or keyboard, doesn't one need
a driver? Using libusb might make it a user-space driver rather than
a kernel-space one, but I think you still need a driver if you want to
do something other than a human interface device.

> I'm not sure why, or if this is just a
> Windows problem, but you do need to source and install a manufacturer
> specific device driver to do CDC. If you stick with FTDI-based devices, the
> driver seems to be OK, but I have had endless problems with the (more common
> in over-the-counter USB-Serial converters) Prolific chip drivers on Vista
> and Windows 7.

They've all just popped up for me on OS X & Linux without any drivers,
but I think you're right about windows wanting something. I can't
imagine it being much more than a stub that has device and vendor data
and indicates that it should show up as a COM port, though.

FTDI devices are pretty nice, and they also have a programmatic
interface which you can access through a library they provide or with
libftdi (http://www.intra2net.com/en/developer/libftdi/).

>
>> -----Original Message-----
>> From: [hidden email] [mailto:elua-dev-
>> [hidden email]] On Behalf Of James Snyder
>> Sent: 09 March 2010 19:43
>> To: eLua Users and Development List (www.eluaproject.net)
>> Subject: Re: [eLua-dev] Single Chip Lua Prospects
>>
>> I suppose it depends on the interaction model desired, but if what one
>> wants is a tty, I suspect that presenting as an HID is going to make
>> it more complicated to support different platforms
>> --
>> James Snyder
>> Biomedical Engineering
>> Northwestern University
>> [hidden email]
>> PGP: http://fanplastic.org/key.txt
>> Phone: (847) 448-0386
>> _______________________________________________
>> 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
>

Tim Michals

Re: Single Chip Lua Prospects

In reply to this post by Tony-12

I've got a program working with CodeSourcery tools for the PIC32, using the UBW32. Next is start on a port of eLua. The goal is not use microchips gcc. Plus microchip gcc is old... etc...

John Hind

Re: Single Chip Lua Prospects

In reply to this post by jbsnyder

If you look at the HID profile, it *is* pretty much a generic packetized
protocol, albeit for relatively modest sized packets. As I mentioned before,
Microchip even have a bootloader that works over HID. I admit I've not
looked at the API for accessing HID other than on Windows, so that interface
may present cross-platform challenges. All the PC-connected microcontroller
applications I can envisage (except Ethernet of course) would be
accommodated either by HID or MSD (or maybe both together).

I'm not against using CDC were it is appropriate (simple HMI for example),
but if you are layering proprietary (or even open) packet or file transfer
protocols on top of it, you'd be better considering USB profiles designed
for those purposes.

However I do understand that if you are committed to supporting a wide range
of microcontroller chips some of which do not have USB, defaulting to the
"lowest common denominator" of RS232 has its attractions - it's just a
little "last century"!

Does anyone know of a generic CDC driver for Windows? This discussion has
made me realise that I do not understand why these drivers seem to be
vendor-specific. OK Microsoft have chosen not to support CDC natively, but
it is still a standard USB profile and so should work with a standard driver
at the PC end.

> -----Original Message-----
> From: [hidden email] [mailto:elua-dev-
> [hidden email]] On Behalf Of James Snyder
> Sent: 12 March 2010 02:14
> To: eLua Users and Development List (www.eluaproject.net)
> Subject: Re: [eLua-dev] Single Chip Lua Prospects
>
> On Thu, Mar 11, 2010 at 3:52 AM, John Hind <[hidden email]> wrote:
> > You are right of course, if you actually *want* a tty interaction
> model, CDC
> > has the edge. But are you sure this really is the base requirement?
> Mostly I
> > see one of the following: File transfer, which would be a packetized
> layer
> > on top of tty (such as X-Modem) and in the USB world would be better
> done
> > with MSD; and proprietary packetized command/response protocols for
> > debuggers or computer peripherals like GPS or PLC like devices (which
> would
> > be better done with HID or a custom USB profile).
>
> I would certainly agree that for file transfer and various packetized
> protocols, various USB profiles are certainly going to provide a more
> reliable and higher throughput option compared with something like
> RS232 or CDC. But I suppose the question needs to be answered: "What
> interaction models do we want?"
>
> I think being able to do MSD dramatically simplifies the concept of
> transferring data back and forth (though it has downsides like 2
> devices can't mount it at the same time). I'm not sure what of any
> proprietary packetized formats might make sense for us in a general
> sense, since a lot of those are geared towards one particular use.
> Perhaps there are open ones as well, beyond the basic device classes
> that might make for a generalized programmatic interface we could
> provide, but none are coming to mind at the moment.
>
> Right now our development paradigm involves either working with eLua
> over a serial console as a command-line shell/interpreter or using
> something like LuaRPC for a programmatic interaction model with a VM
> running on the microcontroller. Certainly for the former, I think a
> CDC (or similar) makes the most sense, and I would argue that having a
> device class like this is always going to be useful on some level if
> for nothing else that it provides a really easy way to make ad-hoc
> communications between the embedded device and a desktop. Getting
> some data from a device is as simple as opening a terminal and having
> some print statements in the program. It might not be very
> sophisticated, but it's a nice fallback when one is getting started or
> wants to get quick details about program operation
>
> Now, I could definitely see the benefit of using some sort of
> packetized usb-based communication channel for supporting LuaRPC, it
> would be less complicated (presumably) than using TCP/IP and it would
> give you better throughput, latency, etc and would provide an
> extensible model for user and developer interaction without having to
> delve into the details of how the USB link works. I would still want
> some sort of tty-like interface as a fallback, though.
>
>
> >
> > Conceptually the problem with RS232/ASCII/tty is that it is not a
> complete
> > communications stack except for the intended teletype application.
> All the
> > actual modern applications require additional layers on top. In
> contrast,
> > the USB profiles are complete specifications right up to the
> application
> > layer.
>
> Right, I would agree. Especially without the control lines it has
> pitfalls, especially with large quantities of data transmission and
> small buffers, but so far it's actually worked reasonably well for us.
>
> >
> > The clincher for me is that you can do HID and MSD on any modern
> platform
> > without an additional device driver.
>
> I'm not sure if I'm missing something, but if one wants to use HID and
> present as something other than a mouse or keyboard, doesn't one need
> a driver? Using libusb might make it a user-space driver rather than
> a kernel-space one, but I think you still need a driver if you want to
> do something other than a human interface device.
>
> > I'm not sure why, or if this is just a
> > Windows problem, but you do need to source and install a manufacturer
> > specific device driver to do CDC. If you stick with FTDI-based
> devices, the
> > driver seems to be OK, but I have had endless problems with the (more
> common
> > in over-the-counter USB-Serial converters) Prolific chip drivers on
> Vista
> > and Windows 7.
>
> They've all just popped up for me on OS X & Linux without any drivers,
> but I think you're right about windows wanting something. I can't
> imagine it being much more than a stub that has device and vendor data
> and indicates that it should show up as a COM port, though.
>
> FTDI devices are pretty nice, and they also have a programmatic
> interface which you can access through a library they provide or with
> libftdi (http://www.intra2net.com/en/developer/libftdi/).
>
> >
> >> -----Original Message-----
> >> From: [hidden email] [mailto:elua-dev-
> >> [hidden email]] On Behalf Of James Snyder
> >> Sent: 09 March 2010 19:43
> >> To: eLua Users and Development List (www.eluaproject.net)
> >> Subject: Re: [eLua-dev] Single Chip Lua Prospects
> >>
> >> I suppose it depends on the interaction model desired, but if what
> one
> >> wants is a tty, I suspect that presenting as an HID is going to make
> >> it more complicated to support different platforms
> >> --
> >> James Snyder
> >> Biomedical Engineering
> >> Northwestern University
> >> [hidden email]
> >> PGP: http://fanplastic.org/key.txt
> >> Phone: (847) 448-0386
> >> _______________________________________________
> >> 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
> >
>
>
>
> --
> James Snyder
> Biomedical Engineering
> Northwestern University
> [hidden email]
> PGP: http://fanplastic.org/key.txt
> Phone: (847) 448-0386
> _______________________________________________
> 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

Re: Single Chip Lua Prospects

In reply to this post by Tim Michals

Ah, I didn't know it was possible to program the PIC32s using a "regular" MIPS toolchain. Very good news, thank you!

On Fri, Mar 12, 2010 at 11:18 PM, Tim Michals <[hidden email]> wrote:

I've got a program working with CodeSourcery tools for the PIC32, using the
UBW32. Next is start on a port of eLua. The goal is not use microchips
gcc. Plus microchip gcc is old... etc...
--
View this message in context: http://n2.nabble.com/Re-Single-Chip-Lua-Prospects-tp4677969p4724512.html
Sent from the eLua Development mailing list archive at Nabble.com.
_______________________________________________
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