Greetings,
Noticing that the main community of users for Artec Group's LPC dongle has been at Coreboot, I have two announcements to make:
1) The current LPC dongle model is EOL. Some components no longer exist on the market so, after the batch we're producing this month, it's gone.
2) We're already working on a new LPC dongle to replace the current one.
In conjunction with item #2 above, we are hereby giving the Coreboot community an opportunity to influence the design of this new product. While we cannot guarantee that every idea submitted will be used, we will definitely be reading all the feedback we receive.
The end result will be an even better LPC dongle that serves the growing needs of the embedded hardware developer community.
To compare with the current dongle design, see:
http://artecgroup.myshopify.com/products/programmable-lpc-dongle
Looking forward to receiving your ideas for this new LPC dongle product.
Best Regards,
On Fri, Aug 08, 2008 at 02:15:39PM +0300, Martin-Éric Racine wrote:
In conjunction with item #2 above, we are hereby giving the Coreboot community an opportunity to influence the design of this new product.
I have a few thoughts, in order of importance they are:
* By far the most important one: Use a more intelligent USB chip
USB can do 480Mbps so transfering half a megabyte should not need to take several seconds. There is obviously a huge opportunity for improvement here, and as it happens this is also the main bottleneck in the dongle when doing intensive development.
The most elegant solution is to implement USB completely in the FPGA, but a separate chip is likely more economical. Key point is that it must not be a dumb serial chip.
Cypress had the EZ-USB SX2 (not FX2) but unfortunately it's EOL.
The PLX NET2270/NET2272 are really powerful, but may be a bit costly.
NEC µPD720122 is another option, it's on par with the Netchip.
NXP ISP1582 may be the winner. Unit price/2k is 2.87 USD.
Finally it's of course also possible to implement part of USB in the FPGA and only use an external transceiver chip. There are plenty of those chips available.
* Use an Actel FPGA that is live from power on
This allows the dongle to be powered comfortably from the target without compromising usability.
* Automatic power switch with a few protection diodes
Get rid of the power switch jumper.
* Replace any other jumpers with toggle switches
Ideally remove hardware configuration completely and do all settings via USB.
* SMD LEDs
Because the through hole ones often get bent out of shape when the dongle is carried in a bag.
//Peter
Dear Martin-Éric,
we're using two of the dongles at coresystems; and they're in use many times every day. Thank you guys for creating this device. It almost completely replaced the Galep V here for non-SPI systems.
With parallel abuild, a compile+flash cycle for an 8MBit image takes about 30s, the dongle part takes about 25s of that time.
Peter Stuge wrote:
On Fri, Aug 08, 2008 at 02:15:39PM +0300, Martin-Éric Racine wrote:
In conjunction with item #2 above, we are hereby giving the Coreboot community an opportunity to influence the design of this new product.
I have a few thoughts, in order of importance they are:
- By far the most important one: Use a more intelligent USB chip
USB can do 480Mbps so transfering half a megabyte should not need to take several seconds. There is obviously a huge opportunity for improvement here, and as it happens this is also the main bottleneck in the dongle when doing intensive development.
The most elegant solution is to implement USB completely in the FPGA, but a separate chip is likely more economical. Key point is that it must not be a dumb serial chip.
* Possibly, in connection with this, use SRAM or DRAM to store or cache the images transferred from the host side. I think writing the flash takes about as long as transferring it over serial port, so using a faster USB (network instead of serial) chip would only move the bottle neck.
* One habit of the dongle is very ugly; the need to reset it after loading it. I think it would be a good idea to have the dongle reset itself (or, the lpc part of itself) after the write process is complete.
* 0x3f8 serial port logging support on lpc. (Sorry, I never looked into this)
* A couple of jumper pins could be preconfigured as host side software programmable GPIOs for tasks like triggering a reset on the target system.
* Deliver the dongle with a PLCC plug header, or offer it as an option.
Best regards, Stefan
On Fri, Aug 08, 2008 at 03:02:13PM +0200, Stefan Reinauer wrote:
Peter Stuge wrote:
- By far the most important one: Use a more intelligent USB chip
- Possibly, in connection with this, use SRAM or DRAM to store or
cache the images transferred from the host side. I think writing the flash takes about as long as transferring it over serial port,
Each 128K block erase+write takes at least 1.8s. Look for a flash part with better performance for the next generation.
so using a faster USB (network instead of serial) chip would only move the bottle neck.
Exactly how a fast USB interface should work is a great question. Making the device a CDC Ethernet device like the GALEP-5 would be nice because it will be easy to interface with, but it would also require the FPGA to run a full IP stack, which I don't think we want.
I would look for other device class specs but possibly the best solution would simply be a vendor specific device with two (IN+OUT) bulk endpoints and an efficient protocol. As long as documentation is provided, I don't think there's any shame in vendor specific devices. (And with the dongle there's source.)
- One habit of the dongle is very ugly; the need to reset it after
loading it. I think it would be a good idea to have the dongle reset itself (or, the lpc part of itself) after the write process is complete.
Great point. It should not need a reset at all. Hopefully this does not go beyond the VHDL.
- 0x3f8 serial port logging support on lpc. (Sorry, I never looked
into this)
Great idea, also VHDL. Besides Stefan's points I have another VHDL request;
* Don't require explicit enable for full memory decode.
- A couple of jumper pins could be preconfigured as host side
software programmable GPIOs for tasks like triggering a reset on the target system.
Yes, some open collector outputs should be cheap to add.
//Peter
Peter Stuge wrote:
- 0x3f8 serial port logging support on lpc. (Sorry, I never looked
into this)
Great idea, also VHDL. Besides Stefan's points I have another VHDL request;
- Don't require explicit enable for full memory decode.
... or make the enable switch available both from the host and the target side...
Stefan Reinauer wrote:
Dear Martin-Éric,
- 0x3f8 serial port logging support on lpc. (Sorry, I never looked into
this)
Good idea.
Power and reset headers are handy for remote development. Maybe the GPIO header could be used for that on the current model?
Marc
Marc Jones wrote:
Stefan Reinauer wrote:
Dear Martin-Éric,
- 0x3f8 serial port logging support on lpc. (Sorry, I never looked
into this)
Good idea.
Power and reset headers are handy for remote development. Maybe the GPIO header could be used for that on the current model?
Yes, I believe it could be done. The bigger task though is getting the "reset LPC part after flash update" part right. The VHDL code locks the LPC side of the dongle during flash update, so no interference can happen. But it stays that way after the update. There might be reasons for that, I am not sure.
Stefan Reinauer wrote:
Marc Jones wrote:
Stefan Reinauer wrote:
Dear Martin-Éric,
- 0x3f8 serial port logging support on lpc. (Sorry, I never looked
into this)
Good idea.
Power and reset headers are handy for remote development. Maybe the GPIO header could be used for that on the current model?
Yes, I believe it could be done. The bigger task though is getting the "reset LPC part after flash update" part right. The VHDL code locks the LPC side of the dongle during flash update, so no interference can happen. But it stays that way after the update. There might be reasons for that, I am not sure.
Ah, I see. That would be a problem. Power and reset would be good for the automated testbed.
I can't find the twiki page for the automated testbed. Can you put a link on the mainpage or the qa page?
Marc
Marc Jones wrote:
Ah, I see. That would be a problem. Power and reset would be good for the automated testbed.
absolutely.
I can't find the twiki page for the automated testbed. Can you put a link on the mainpage or the qa page?
On the mainpage, go to Developer -> Testsystem
Stefan
Take a look at the VHDL source for both the the Xilinx and Altera fpga's at http://www.sump.org/projects/analyzer/
All the work is almost done for you. Just add your LPC VHDL and build on the Java interface for a complete, spi and lpc interface plus flash emulator and logic analyzer, with serial, usb (host and device) and vga ports.
-Bari
Martin-Éric Racine wrote:
Greetings,
Noticing that the main community of users for Artec Group's LPC dongle has been at Coreboot, I have two announcements to make:
- The current LPC dongle model is EOL. Some components no longer exist
on the market so, after the batch we're producing this month, it's gone.
- We're already working on a new LPC dongle to replace the current one.
In conjunction with item #2 above, we are hereby giving the Coreboot community an opportunity to influence the design of this new product. While we cannot guarantee that every idea submitted will be used, we will definitely be reading all the feedback we receive.
The end result will be an even better LPC dongle that serves the growing needs of the embedded hardware developer community.
To compare with the current dongle design, see:
http://artecgroup.myshopify.com/products/programmable-lpc-dongle
Looking forward to receiving your ideas for this new LPC dongle product.
Best Regards,
Hi Martin-Éric,
On 08.08.2008 13:15, Martin-Éric Racine wrote:
Noticing that the main community of users for Artec Group's LPC dongle has been at Coreboot, I have two announcements to make:
- The current LPC dongle model is EOL. Some components no longer exist
on the market so, after the batch we're producing this month, it's gone.
That's unfortunate.
- We're already working on a new LPC dongle to replace the current one.
Now that's great.
In conjunction with item #2 above, we are hereby giving the Coreboot community an opportunity to influence the design of this new product. While we cannot guarantee that every idea submitted will be used, we will definitely be reading all the feedback we receive.
Cool, thanks for giving us this opportunity.
The end result will be an even better LPC dongle that serves the growing needs of the embedded hardware developer community.
A few suggestions to improve on the already great dongle: - It's a LPC dongle, but having SPI support as well would be really cool. - Maybe sell a dongle<->PLCC32 connector as well. - Provide a memory access (read/write) logger with timing info.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
The end result will be an even better LPC dongle that serves the growing needs of the embedded hardware developer community.
A few suggestions to improve on the already great dongle:
- It's a LPC dongle, but having SPI support as well would be really cool.
BTW, for SPI I can very much recommend the Dediprog SF100. It's quite inexpensive, and allows you to program flashes in-place. Only downside: It requires Windows (in a VM)
Stefan
On Fri, Aug 8, 2008 at 4:15 AM, Martin-Éric Racine martin-eric.racine@artecgroup.com wrote:
In conjunction with item #2 above, we are hereby giving the Coreboot community an opportunity to influence the design of this new product. While we cannot guarantee that every idea submitted will be used, we will definitely be reading all the feedback we receive.
The current LPC dongle is great--I've been using it for a couple of weeks and it speeds up firmware debugging enormously.
Here's my wish list for a new version of the dongle (some of which overlap previous responses). I'd like to be able to:
1. Reset the dongle by issuing a command from the host, instead of pushing a button on the dongle.
2. Reset the target by issuing a command from the host that toggles a GPIO connected to a reset pin on the target.
3. Enable 4MB addressing by setting a jumper on the dongle or by issuing a command from the host.
4. Purchase a prewired PLCC32 LPC/FWH plug adapter instead of hunting for parts and assembling them myself.
5. Pay via credit card. I would happily pay you a surcharge to avoid the time and expense of dealing with checks and banks and wire transfers.
--Ed
On Mon, Aug 11, 2008 at 08:20:57AM -0700, Ed Swierk wrote:
The current LPC dongle is great--I've been using it for a couple of weeks and it speeds up firmware debugging enormously.
Here's my wish list for a new version of the dongle (some of which overlap previous responses). I'd like to be able to:
- Reset the dongle by issuing a command from the host, instead of
pushing a button on the dongle.
- Reset the target by issuing a command from the host that toggles a
GPIO connected to a reset pin on the target.
- Enable 4MB addressing by setting a jumper on the dongle or by
issuing a command from the host.
- Purchase a prewired PLCC32 LPC/FWH plug adapter instead of hunting
for parts and assembling them myself.
I second all those points!
Thanks, Ward.
Ed Swierk kirjoitti:
- Pay via credit card. I would happily pay you a surcharge to avoid
the time and expense of dealing with checks and banks and wire transfers.
This is already possible since a few weeks:
http://artecgroup.myshopify.com/products/programmable-lpc-dongle
On Mon, Aug 11, 2008 at 8:20 AM, Ed Swierk eswierk@arastra.com wrote:
Here's my wish list for a new version of the dongle (some of which overlap previous responses). I'd like to be able to:
- Reset the dongle by issuing a command from the host, instead of
pushing a button on the dongle.
- Reset the target by issuing a command from the host that toggles a
GPIO connected to a reset pin on the target.
- Enable 4MB addressing by setting a jumper on the dongle or by
issuing a command from the host.
- Purchase a prewired PLCC32 LPC/FWH plug adapter instead of hunting
for parts and assembling them myself.
- Pay via credit card. I would happily pay you a surcharge to avoid
the time and expense of dealing with checks and banks and wire transfers.
One more wish, if you're still taking requests:
6. Log to the USB serial port LPC flash reads and writes (similar to the existing POST code logger mode).
--Ed
Ed Swierk kirjoitti:
On Mon, Aug 11, 2008 at 8:20 AM, Ed Swierk eswierk@arastra.com wrote:
Here's my wish list for a new version of the dongle (some of which overlap previous responses). I'd like to be able to:
[...]
One more wish, if you're still taking requests:
- Log to the USB serial port LPC flash reads and writes (similar to
the existing POST code logger mode).
We're always open to suggestions, but these will have to be sent to our FPGA developer, Mr.Jüri Toomessoo at the above address, in the future, as this is my last week working for Artec Group.
-
bari -
Carl-Daniel Hailfinger -
Ed Swierk -
Ed Swierk -
Marc Jones -
Martin-Éric Racine -
Peter Stuge -
Stefan Reinauer -
Ward Vandewege