stm32f4 discovery board?
Locked
1234
1234
|
On Thu, Oct 13, 2011 at 2:09 PM, Bogdan Marinescu <[hidden email]> wrote:
Wine runs the installer just fine, the file ends up in: ~/.wine/drive_c/Program Files/STMicroelectronics/Software/DfuSe/Sources/Doc/UM0391.pdf -- rec -- _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Fri, Oct 14, 2011 at 12:05 AM, Roger Critchlow <[hidden email]> wrote:
> > > On Thu, Oct 13, 2011 at 2:09 PM, Bogdan Marinescu > <[hidden email]> wrote: >> >> Yes, UM0391 (DfuSe File Format Specification) is available after >> installing the DfuSe software (Windows only) from here: >> >> >> http://www.st.com/internet/com/SOFTWARE_RESOURCES/SW_COMPONENT/SW_DEMO/um0412.zip >> > > Wine runs the installer just fine, the file ends up in: > ~/.wine/drive_c/Program > Files/STMicroelectronics/Software/DfuSe/Sources/Doc/UM0391.pdf Thanks! Should've tryied my luck with wine before firing up VirtualBox :) Best, Bogdan > -- rec -- > _______________________________________________ > 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 |
|
|
In reply to this post by Roger Critchlow
On Thu, Oct 13, 2011 at 3:02 PM, Roger Critchlow <[hidden email]> wrote: I am confused about that, too. It isn't an ST-LINK. It is an ST-LINK V2. They use completely different protocols. The V1 uses USB mass storage class, the V2 is something proprietary.
It probably won't work since it isn't a V1 ST-LINK.
Mike
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Here is what I found about the JTAG http://comments.gmane.org/gmane.comp.debugging.openocd.devel/18248 There is some projects out there, but can reprogram and use it as a veralsoon board From: Mike Panetta <[hidden email]> To: eLua Users and Development List (www.eluaproject.net) <[hidden email]> Sent: Thursday, October 13, 2011 4:37 PM Subject: Re: [eLua-dev] stm32f4 discovery board? On Thu, Oct 13, 2011 at 3:02 PM, Roger Critchlow <[hidden email]> wrote: I am confused about that, too. It isn't an ST-LINK. It is an ST-LINK V2. They use completely different protocols. The V1 uses USB mass storage class, the V2 is something proprietary.
It probably won't work since it isn't a V1 ST-LINK.
Mike
_______________________________________________ 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 |
|
|
In reply to this post by Mike Panetta
On Thu, Oct 13, 2011 at 3:37 PM, Mike Panetta <[hidden email]> wrote:
You're right, it's a new usb product id, and the Interface reports as vendor specific where it used to be mass storage, and there's a third endpoint where there were only two before, and stlink-download gets nowhere with it because it never gets the mass storage driver loaded. I wonder if it's the same broken mass storage implementation underneath.
-- rec -- _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Roger Critchlow
The STM32F4 Discovery board is pretty tempting; since the cheapest STM32F4 at Mouser is $8, I'm pretty sure ST is losing money in the short term (and hoping to make it up in the long run).
This board also brings up another point to consider: single precision floating point. Yes, the STM32F4 has single precision floating point, and I've seen a lot of other new MCUs and DSPs with single precision floating point (from ST, TI, Atmel, and Freescale) -- and very few with double precision. Hardware floating point is really nice, except single precision doesn't work well with Lua's one number format model. So what's the best way of integrating a single precision FPU with eLua? --Tony On Wed, Oct 12, 2011 at 5:44 PM, Roger Critchlow <[hidden email]> wrote: Greetings eLua developers. _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Fri, Oct 14, 2011 at 1:49 AM, Tony <[hidden email]> wrote:
> The STM32F4 Discovery board is pretty tempting; since the cheapest STM32F4 > at Mouser is $8, I'm pretty sure ST is losing money in the short term (and > hoping to make it up in the long run). > > This board also brings up another point to consider: single precision > floating point. Yes, the STM32F4 has single precision floating point, and > I've seen a lot of other new MCUs and DSPs with single precision floating > point (from ST, TI, Atmel, and Freescale) -- and very few with double > precision. Hardware floating point is really nice, except single precision > doesn't work well with Lua's one number format model. > > So what's the best way of integrating a single precision FPU with eLua? This is a _very_ good question. My answer, unfortunately, is "I have no idea at the moment". Single precision will probably be considered too "weak" for eLua (since it can't even hold a 32-bit integer) and I don't know of a good way to use a single precision FPU to accelerate the emulation of double precision operations. There are other ways we could use this, of course (for example via specialized modules), but the main part of eLua will probably still be emulated. Presumtively we could also use something like LNUM and deffer the operations that can be done in single precision to the FPU, but the overhead added by LNUM might not make this worthy. Interesting brain teaser :) Best, Bogdan > > --Tony > > On Wed, Oct 12, 2011 at 5:44 PM, Roger Critchlow <[hidden email]> wrote: >> >> Greetings eLua developers. >> I just received an STM32F4 Discovery >> board, http://www.st.com/internet/evalboard/product/252419.jsp, and while >> trolling the internets for open source, linux based development tools I came >> upon eLua. It seems that with 1Mbyte of flash and 192kbytes of RAM and >> priced at US$19.50 this ARM Cortex-M4 board might be a reasonable candidate >> target board for eLua, but I'm working from a very sketchy understanding of >> eLua. Is it a reasonable target for eLua? >> Many thanks, >> -- rec -- >> >> _______________________________________________ >> 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 |
|
|
I ran into this issue while trying to compile the code. My understanding is there are three methods to compile - soft: all done in software -soft-vpu: The code uses the soft ABI for floating point libraries but uses hard floating point to speed up operations. - hard: Everything must be compiled using hard floating point. So, a special newlib, clib etc must be compiled. Right now I'm using soft-vpu, to get it to link and move forward get it working first. More to add to the list ;) From: Bogdan Marinescu <[hidden email]> To: eLua Users and Development List (www.eluaproject.net) <[hidden email]> Sent: Friday, October 14, 2011 1:56 AM Subject: Re: [eLua-dev] stm32f4 discovery board? On Fri, Oct 14, 2011 at 1:49 AM, Tony <[hidden email]> wrote: > The STM32F4 Discovery board is pretty tempting; since the cheapest STM32F4 > at Mouser is $8, I'm pretty sure ST is losing money in the short term (and > hoping to make it up in the long run). > > This board also brings up another point to consider: single precision > floating point. Yes, the STM32F4 has single precision floating point, and > I've seen a lot of other new MCUs and DSPs with single precision floating > point (from ST, TI, Atmel, and Freescale) -- and very few with double > precision. Hardware floating point is really nice, except single precision > doesn't work well with Lua's one number format model. > > So what's the best way of integrating a single precision FPU with eLua? This is a _very_ good question. My answer, unfortunately, is "I have no idea at the moment". Single precision will probably be considered too "weak" for eLua (since it can't even hold a 32-bit integer) and I don't know of a good way to use a single precision FPU to accelerate the emulation of double precision operations. There are other ways we could use this, of course (for example via specialized modules), but the main part of eLua will probably still be emulated. Presumtively we could also use something like LNUM and deffer the operations that can be done in single precision to the FPU, but the overhead added by LNUM might not make this worthy. Interesting brain teaser :) Best, Bogdan > > --Tony > > On Wed, Oct 12, 2011 at 5:44 PM, Roger Critchlow <[hidden email]> wrote: >> >> Greetings eLua developers. >> I just received an STM32F4 Discovery >> board, http://www.st.com/internet/evalboard/product/252419.jsp, and while >> trolling the internets for open source, linux based development tools I came >> upon eLua. It seems that with 1Mbyte of flash and 192kbytes of RAM and >> priced at US$19.50 this ARM Cortex-M4 board might be a reasonable candidate >> target board for eLua, but I'm working from a very sketchy understanding of >> eLua. Is it a reasonable target for eLua? >> Many thanks, >> -- rec -- >> >> _______________________________________________ >> 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 |
|
|
I have made a temporary build and runs on the stm32f4 discovery board, only the UART works. As I also have stm32f2 board, I'm also trying run elua on stm32f2xx, hopes it could works shortly.
Might be an FAQ: How to contribute code to elua project? |
|
|
Hi,
On Sun, Oct 16, 2011 at 03:27, Zhanjun Dong <[hidden email]> wrote: I have made a temporary build and runs on the stm32f4 discovery board, only Yes, we would love to refine and promote the use of our FAQ, currently at http://wiki.eluaproject.net/FAQ There is also the tracker, with it's internal tools (issue comments, dev-wiki, follow-ups, .....) at http://tracker.eluaproject.net How to contribute code to elua project? You are already doing it ! :) Thankssss. (and yes, I wish I was doing much better these days too :( If I've only got rid of some silly health problems......:( But hey, we've got great people around and very commited to eLua too! We're moving!) Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by Roger Critchlow
Any further progress made on the interface from something other than windows? I've requested a sample of one of these boards to experiment with and saw a flurry of messages related to the interface but nothing entirely conclusive? Perhaps if all else fails there may be some way to get the mcu into a dfu mode and upload firmware that way? -- James Snyder Biomedical Engineering Northwestern University ph: (847) 448-0386
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Sun, Oct 16, 2011 at 8:24 PM, James Snyder <[hidden email]> wrote:
Again, has anyone tried stm32ld? If the protocol stayed the same (and why wouldn't it?) it should be quite straightforward to modify. Of course a bit of new hardware would be required too, but that should be fairly trivial.
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
 
|
Tim Michals |
LPC43xx/LPC18xx boards comming soon
|
|
Here is NXP M4 cortex demo board: http://shop.ngxtechnologies.com/product_info.php?products_id=104 Also, look at the LPC18xx: http://shop.ngxtechnologies.com/product_info.php?cPath=21_33&products_id=105 - 2MB of flash - 136K of RAM _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Mon, Oct 17, 2011 at 5:06 PM, Tim michals <[hidden email]> wrote:
The future definitely looks good, thanks. And at $0.00 per piece, I'll order a LOT of them.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
Martin Guy |
Re: LPC43xx/LPC18xx boards comming soon
|
|
In reply to this post by Tim Michals
Hi
Empty publicity in a technical forum is not on. If you had something to give, like you ported eLua to them and need some final help or - at the limit - if you wanted to find people for free samples hoping that *they* would port eLua to it (which is a quiet but pointful type of free publicity), that would make sense. Just posting links to your half-finished shop is spam. M _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Mon, Oct 17, 2011 at 5:36 PM, Martin Guy <[hidden email]> wrote: Hi Errr, no. It's a way to let the world know that M4-based boards are coming. This is debatable (as always), but I for one don't see this as "spam". Especially considering Tim's activity on this list.
Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by BogdanM
On Sun, Oct 16, 2011 at 1:28 PM, Bogdan Marinescu
<[hidden email]> wrote: > > > On Sun, Oct 16, 2011 at 8:24 PM, James Snyder <[hidden email]> > wrote: >> >> Any further progress made on the interface from something other than >> windows? I've requested a sample of one of these boards to experiment with >> and saw a flurry of messages related to the interface but nothing entirely >> conclusive? > > Again, has anyone tried stm32ld? If the protocol stayed the same (and why > wouldn't it?) it should be quite straightforward to modify. Of course a bit > of new hardware would be required too, but that should be fairly trivial. That's a good point as well. I haven't fully investigated whether they've kept this the same. It looks like BOOT0/BOOT1 are brought out. The getting started guide actually mention a DFU mode in conjunction with these pins which would be even better since there's freely available DFU software out there that's cross platform. I believe some of the earlier messages refer to trying this mode.. FYI, aside from the avr-related dfu-programmer, there's also dfu-util: http://dfu-util.gnumonks.org/ Which is used for openmoko, leaflabs maple, and some other hardware so it's probably a good candidate for a compatible loader. -jsnyder > >> >> Perhaps if all else fails there may be some way to get the mcu into a dfu >> mode and upload firmware that way? >> >> -- >> James Snyder >> Biomedical Engineering >> Northwestern University >> http://fanplastic.org/key.txt >> ph: (847) 448-0386 >> On Oct 13, 2011, at 17:31, Roger Critchlow <[hidden email]> wrote: >> >> >> >> On Thu, Oct 13, 2011 at 3:37 PM, Mike Panetta <[hidden email]> >> wrote: >>> >>> It isn't an ST-LINK. It is an ST-LINK V2. They use completely different >>> protocols. The V1 uses USB mass storage class, the V2 is something >>> proprietary. >>> >>>> But I'm puzzled by the contents arm-utilities/stlink-download. Guess I >>>> should just compile something and try flashing. >>> >>> It probably won't work since it isn't a V1 ST-LINK. >>> >> >> You're right, it's a new usb product id, and the Interface reports as >> vendor specific where it used to be mass storage, and there's a third >> endpoint where there were only two before, and stlink-download gets nowhere >> with it because it never gets the mass storage driver loaded. I wonder if >> it's the same broken mass storage implementation underneath. >> -- rec -- >> >> _______________________________________________ >> 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 |
|
|
It looks like it should support both DFU & the older serial mode (from
page 59 of the Reference Manual): Embedded bootloader The embedded bootloader mode is used to reprogram the Flash memory using one of the following serial interfaces: ● USART1(PA9/PA10) ● USART3(PB10/11 and PC10/11) ● CAN2(PB5/13) ● USB OTG FS(PA11/12) in Device mode (DFU: device firmware upgrade). The USART peripherals operate at the internal 16 MHz oscillator (HSI) frequency, while the CAN and USB OTG FS require an external clock (HSE) multiple of 1 MHz (ranging from 4 to 26 MHz). The embedded bootloader code is located in system memory. It is programmed by ST during production. For additional information, refer to application note AN2606. Nice :-) On Mon, Oct 17, 2011 at 12:36 PM, James Snyder <[hidden email]> wrote: > On Sun, Oct 16, 2011 at 1:28 PM, Bogdan Marinescu > <[hidden email]> wrote: >> >> >> On Sun, Oct 16, 2011 at 8:24 PM, James Snyder <[hidden email]> >> wrote: >>> >>> Any further progress made on the interface from something other than >>> windows? I've requested a sample of one of these boards to experiment with >>> and saw a flurry of messages related to the interface but nothing entirely >>> conclusive? >> >> Again, has anyone tried stm32ld? If the protocol stayed the same (and why >> wouldn't it?) it should be quite straightforward to modify. Of course a bit >> of new hardware would be required too, but that should be fairly trivial. > > That's a good point as well. I haven't fully investigated whether > they've kept this the same. It looks like BOOT0/BOOT1 are brought > out. > > The getting started guide actually mention a DFU mode in conjunction > with these pins which would be even better since there's freely > available DFU software out there that's cross platform. I believe > some of the earlier messages refer to trying this mode.. > > FYI, aside from the avr-related dfu-programmer, there's also dfu-util: > http://dfu-util.gnumonks.org/ > > Which is used for openmoko, leaflabs maple, and some other hardware so > it's probably a good candidate for a compatible loader. > > -jsnyder > >> >>> >>> Perhaps if all else fails there may be some way to get the mcu into a dfu >>> mode and upload firmware that way? >>> >>> -- >>> James Snyder >>> Biomedical Engineering >>> Northwestern University >>> http://fanplastic.org/key.txt >>> ph: (847) 448-0386 >>> On Oct 13, 2011, at 17:31, Roger Critchlow <[hidden email]> wrote: >>> >>> >>> >>> On Thu, Oct 13, 2011 at 3:37 PM, Mike Panetta <[hidden email]> >>> wrote: >>>> >>>> It isn't an ST-LINK. It is an ST-LINK V2. They use completely different >>>> protocols. The V1 uses USB mass storage class, the V2 is something >>>> proprietary. >>>> >>>>> But I'm puzzled by the contents arm-utilities/stlink-download. Guess I >>>>> should just compile something and try flashing. >>>> >>>> It probably won't work since it isn't a V1 ST-LINK. >>>> >>> >>> You're right, it's a new usb product id, and the Interface reports as >>> vendor specific where it used to be mass storage, and there's a third >>> endpoint where there were only two before, and stlink-download gets nowhere >>> with it because it never gets the mass storage driver loaded. I wonder if >>> it's the same broken mass storage implementation underneath. >>> -- rec -- >>> >>> _______________________________________________ >>> 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 |
|
|
Okay, so holding BOOT0 high and BOOT1=PB2 low during reset, and keeping the USART and CAN lines quiescent, should bring up a DFU bootloader on the USB micro-AB port.
Jumpered PB2=GND, BOOT0=3V; powered over the STLink port and no demo booted; connected USB-OTG with a micro-B:
Bus 006 Device 004: ID 0483:3748 SGS Thomson Microelectronics Bus 003 Device 002: ID 0483:df11 SGS Thomson Microelectronics 0483:3748 is the STLink, 0483:df11 is "STM device in DFU mode" -- rec -- On Mon, Oct 17, 2011 at 11:42 AM, James Snyder <[hidden email]> wrote: It looks like it should support both DFU & the older serial mode (from _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
More progress, it appears that this stlink interface package: has been upgraded to support the STLinkV2 on the STM32F4 and other boards. I haven't tried it, yet, but a poster on hackaday says it works, and sure enough the source has a udev rule for the new 0483:4788 STLink device.
-- rec -- _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |