STM32 Bootloader Flashing in Python

[jbsnyder]

Today while looking for the nth time for an alternative to the Windows-
based loader for STM32 bootloader based flashing, I ran across the  
attached script, written in Python.

The original project can be found here: http://tuxotronic.org/wiki/projects/stm32loader

I found it necessary to adjust the serial options slightly, I assume  
the original author might have a different bootloader version, because  
I've adjusted it to match the settings suggested in the docs.

I've also set the serial port default to my own default, but you can  
change that or pass options at the command line.

./stm32loader.py -h provides an overview of usage.  I've been able to  
program my STM32 stamp with it, and it boots into eLua afterwards.

Between this and the new patches Bogdan committed for being agnostic  
about line endings, I can now cut windows out of the loop for STM32  
development :-)

FYI: I have an ADC implementation for STM32 that should basically  
work, but something is causing a hang on boot when I enable the ADC  
peripheral clock on boot.  I'll commit that and some changes to  
elua_adc that allow it to handle situations where a single interrupt  
gives you values from a series of channels.

--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
http://fanplastic.org/key.txt




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

[BogdanM]

Between this and the new patches Bogdan committed for being agnostic about line endings, I can now cut windows out of the loop for STM32 development :-)

You da man! :) Out of curiosity, what terminal emulator are you using in Linux? I was unable to find a decent one ("decent"=something that could compete with TeraTerm).
 

FYI: I have an ADC implementation for STM32 that should basically work, but something is causing a hang on boot when I enable the ADC peripheral clock on boot.  I'll commit that and some changes to elua_adc that allow it to handle situations where a single interrupt gives you values from a series of channels.

Good news, keep up the good work! After all the docs I wrote (and I'm still writing) I'm not even sure I know how to program anymore :)

Best,
Bogdan

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

[jbsnyder]

On Mar 19, 2009, at 3:10 AM, Bogdan Marinescu wrote:

Between this and the new patches Bogdan committed for being agnostic about line endings, I can now cut windows out of the loop for STM32 development :-)

You da man! :) Out of curiosity, what terminal emulator are you using in Linux? I was unable to find a decent one ("decent"=something that could compete with TeraTerm).

I haven't yet found something that is as easy to work with as TeraTerm, which I do find somewhat irritating.  For quick and dirty stuff (no transfers, just console) I just use screen, which one can fire up by just pointing it at the tty device (screen /dev/ttyUSB0 115200).

I've tried a few things including minicom, and haven't been thrilled with them.  One thing that I just stumbled upon, and haven't tried yet is CuteCom (http://cutecom.sourceforge.net/).  I'm going to try and compile that on my Mac, it looks like it's at least in the Ubuntu repositories though.

If that doesn't work well, I'll be further tempted to try and hack something together in Python... :-)

 

FYI: I have an ADC implementation for STM32 that should basically work, but something is causing a hang on boot when I enable the ADC peripheral clock on boot.  I'll commit that and some changes to elua_adc that allow it to handle situations where a single interrupt gives you values from a series of channels.

Good news, keep up the good work! After all the docs I wrote (and I'm still writing) I'm not even sure I know how to program anymore :)

I'm sure it'll come back to you :-)

I did get past that other issue I had mentioned, which, if I recall, came down to some issues of ordering the startup sequence.

I've found that the Stellaris platform is much easier to write something and have it behave the way you expect it to, without having to dig through large swaths of the reference documentation for the hardware.  That simplicity does have a cost, in that there's way more flexibility with STM32, but I find it takes more time to debug, and that solutions are sometimes non-obvious after the fact :-)  I don't think I'm alone there, since I've seen plenty of discussions on the STM32 forums that sound similar to my own experiences.

Right now non-clocked conversion seems to work OK, and it runs at a similar speed to LM3S6965 with adcscope.lua.  While this chip is clocked faster, I think it's not bad for a first pass at settings things up.  Their DMA support also allows for some flexibility that, in some ways, I like better than the dedicated FIFOs on Luminary.  The DMA includes both source and destination address incrementation, and has separate interrupts for half-full/complete events. 

I feel like their docs and/or driver model could be more friendly to someone who isn't intimately familiar with their peripheral architecture, though.  You definitely cannot write driver interfaces that differ much from their code examples using only the driver manual.  You need the chip reference manual to figure out how the hardware works, and then you can find the appropriate calls to set things up.  Certainly you have to do this, to some degree, on all platforms, but with Luminary's docs I got most of what I needed just from their driver manual, and from a few app notes.  This makes me wonder a bit about what things are like with other manufacturer's offerings :-)

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

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

[jbsnyder]

FYI: CuteCom is basically like Bray's terminal, if you've used it on windows.  It doesn't really handle terminal characters, so anything that's drawing text on the screen with term isn't going to work correctly.

Oh well :-)

-jsnyder

On Mar 19, 2009, at 1:11 PM, James Snyder wrote:

On Mar 19, 2009, at 3:10 AM, Bogdan Marinescu wrote:

Between this and the new patches Bogdan committed for being agnostic about line endings, I can now cut windows out of the loop for STM32 development :-)

You da man! :) Out of curiosity, what terminal emulator are you using in Linux? I was unable to find a decent one ("decent"=something that could compete with TeraTerm).

I haven't yet found something that is as easy to work with as TeraTerm, which I do find somewhat irritating.  For quick and dirty stuff (no transfers, just console) I just use screen, which one can fire up by just pointing it at the tty device (screen /dev/ttyUSB0 115200).

I've tried a few things including minicom, and haven't been thrilled with them.  One thing that I just stumbled upon, and haven't tried yet is CuteCom (http://cutecom.sourceforge.net/).  I'm going to try and compile that on my Mac, it looks like it's at least in the Ubuntu repositories though.

If that doesn't work well, I'll be further tempted to try and hack something together in Python... :-)

 

FYI: I have an ADC implementation for STM32 that should basically work, but something is causing a hang on boot when I enable the ADC peripheral clock on boot.  I'll commit that and some changes to elua_adc that allow it to handle situations where a single interrupt gives you values from a series of channels.

Good news, keep up the good work! After all the docs I wrote (and I'm still writing) I'm not even sure I know how to program anymore :)

I'm sure it'll come back to you :-)

I did get past that other issue I had mentioned, which, if I recall, came down to some issues of ordering the startup sequence.

I've found that the Stellaris platform is much easier to write something and have it behave the way you expect it to, without having to dig through large swaths of the reference documentation for the hardware.  That simplicity does have a cost, in that there's way more flexibility with STM32, but I find it takes more time to debug, and that solutions are sometimes non-obvious after the fact :-)  I don't think I'm alone there, since I've seen plenty of discussions on the STM32 forums that sound similar to my own experiences.

Right now non-clocked conversion seems to work OK, and it runs at a similar speed to LM3S6965 with adcscope.lua.  While this chip is clocked faster, I think it's not bad for a first pass at settings things up.  Their DMA support also allows for some flexibility that, in some ways, I like better than the dedicated FIFOs on Luminary.  The DMA includes both source and destination address incrementation, and has separate interrupts for half-full/complete events. 

I feel like their docs and/or driver model could be more friendly to someone who isn't intimately familiar with their peripheral architecture, though.  You definitely cannot write driver interfaces that differ much from their code examples using only the driver manual.  You need the chip reference manual to figure out how the hardware works, and then you can find the appropriate calls to set things up.  Certainly you have to do this, to some degree, on all platforms, but with Luminary's docs I got most of what I needed just from their driver manual, and from a few app notes.  This makes me wonder a bit about what things are like with other manufacturer's offerings :-)

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

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

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

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

[BogdanM]

Oh yes, I tried CuteCom a while ago. I'll give them credit for choosing the name: "cute" describes it perfectly. Simple interface, very little functionality. Cute, but wrong :)
I also think screen is the best choice in Linux, better than minicom anyway. But can you do XMODEM from screen?

Best,
Bogdan

On Thu, Mar 19, 2009 at 8:43 PM, James Snyder <[hidden email]> wrote:

FYI: CuteCom is basically like Bray's terminal, if you've used it on windows.  It doesn't really handle terminal characters, so anything that's drawing text on the screen with term isn't going to work correctly.

Oh well :-)

-jsnyder

On Mar 19, 2009, at 1:11 PM, James Snyder wrote:

On Mar 19, 2009, at 3:10 AM, Bogdan Marinescu wrote:

Between this and the new patches Bogdan committed for being agnostic about line endings, I can now cut windows out of the loop for STM32 development :-)

You da man! :) Out of curiosity, what terminal emulator are you using in Linux? I was unable to find a decent one ("decent"=something that could compete with TeraTerm).

I haven't yet found something that is as easy to work with as TeraTerm, which I do find somewhat irritating.  For quick and dirty stuff (no transfers, just console) I just use screen, which one can fire up by just pointing it at the tty device (screen /dev/ttyUSB0 115200).

I've tried a few things including minicom, and haven't been thrilled with them.  One thing that I just stumbled upon, and haven't tried yet is CuteCom (http://cutecom.sourceforge.net/).  I'm going to try and compile that on my Mac, it looks like it's at least in the Ubuntu repositories though.

If that doesn't work well, I'll be further tempted to try and hack something together in Python... :-)

 

FYI: I have an ADC implementation for STM32 that should basically work, but something is causing a hang on boot when I enable the ADC peripheral clock on boot.  I'll commit that and some changes to elua_adc that allow it to handle situations where a single interrupt gives you values from a series of channels.

Good news, keep up the good work! After all the docs I wrote (and I'm still writing) I'm not even sure I know how to program anymore :)

I'm sure it'll come back to you :-)

I did get past that other issue I had mentioned, which, if I recall, came down to some issues of ordering the startup sequence.

I've found that the Stellaris platform is much easier to write something and have it behave the way you expect it to, without having to dig through large swaths of the reference documentation for the hardware.  That simplicity does have a cost, in that there's way more flexibility with STM32, but I find it takes more time to debug, and that solutions are sometimes non-obvious after the fact :-)  I don't think I'm alone there, since I've seen plenty of discussions on the STM32 forums that sound similar to my own experiences.

Right now non-clocked conversion seems to work OK, and it runs at a similar speed to LM3S6965 with adcscope.lua.  While this chip is clocked faster, I think it's not bad for a first pass at settings things up.  Their DMA support also allows for some flexibility that, in some ways, I like better than the dedicated FIFOs on Luminary.  The DMA includes both source and destination address incrementation, and has separate interrupts for half-full/complete events. 

I feel like their docs and/or driver model could be more friendly to someone who isn't intimately familiar with their peripheral architecture, though.  You definitely cannot write driver interfaces that differ much from their code examples using only the driver manual.  You need the chip reference manual to figure out how the hardware works, and then you can find the appropriate calls to set things up.  Certainly you have to do this, to some degree, on all platforms, but with Luminary's docs I got most of what I needed just from their driver manual, and from a few app notes.  This makes me wonder a bit about what things are like with other manufacturer's offerings :-)

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

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

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

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

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

[jbsnyder]

I'm not sure if there's a way to do it with XMODEM, but there is for ZMODEM:

http://adammonsen.com/post/256

So I assume if eLua had ZMODEM support you could do the send example, replacing rz with recv from the eLua shell.

-jsnyder

On Mar 19, 2009, at 1:48 PM, Bogdan Marinescu wrote:

Oh yes, I tried CuteCom a while ago. I'll give them credit for choosing the name: "cute" describes it perfectly. Simple interface, very little functionality. Cute, but wrong :)
I also think screen is the best choice in Linux, better than minicom anyway. But can you do XMODEM from screen?

Best,
Bogdan

On Thu, Mar 19, 2009 at 8:43 PM, James Snyder <[hidden email]> wrote:

FYI: CuteCom is basically like Bray's terminal, if you've used it on windows.  It doesn't really handle terminal characters, so anything that's drawing text on the screen with term isn't going to work correctly.

Oh well :-)

-jsnyder

On Mar 19, 2009, at 1:11 PM, James Snyder wrote:

On Mar 19, 2009, at 3:10 AM, Bogdan Marinescu wrote:

Between this and the new patches Bogdan committed for being agnostic about line endings, I can now cut windows out of the loop for STM32 development :-)

You da man! :) Out of curiosity, what terminal emulator are you using in Linux? I was unable to find a decent one ("decent"=something that could compete with TeraTerm).

I haven't yet found something that is as easy to work with as TeraTerm, which I do find somewhat irritating.  For quick and dirty stuff (no transfers, just console) I just use screen, which one can fire up by just pointing it at the tty device (screen /dev/ttyUSB0 115200).

I've tried a few things including minicom, and haven't been thrilled with them.  One thing that I just stumbled upon, and haven't tried yet is CuteCom (http://cutecom.sourceforge.net/).  I'm going to try and compile that on my Mac, it looks like it's at least in the Ubuntu repositories though.

If that doesn't work well, I'll be further tempted to try and hack something together in Python... :-)

 

FYI: I have an ADC implementation for STM32 that should basically work, but something is causing a hang on boot when I enable the ADC peripheral clock on boot.  I'll commit that and some changes to elua_adc that allow it to handle situations where a single interrupt gives you values from a series of channels.

Good news, keep up the good work! After all the docs I wrote (and I'm still writing) I'm not even sure I know how to program anymore :)

I'm sure it'll come back to you :-)

I did get past that other issue I had mentioned, which, if I recall, came down to some issues of ordering the startup sequence.

I've found that the Stellaris platform is much easier to write something and have it behave the way you expect it to, without having to dig through large swaths of the reference documentation for the hardware.  That simplicity does have a cost, in that there's way more flexibility with STM32, but I find it takes more time to debug, and that solutions are sometimes non-obvious after the fact :-)  I don't think I'm alone there, since I've seen plenty of discussions on the STM32 forums that sound similar to my own experiences.

Right now non-clocked conversion seems to work OK, and it runs at a similar speed to LM3S6965 with adcscope.lua.  While this chip is clocked faster, I think it's not bad for a first pass at settings things up.  Their DMA support also allows for some flexibility that, in some ways, I like better than the dedicated FIFOs on Luminary.  The DMA includes both source and destination address incrementation, and has separate interrupts for half-full/complete events. 

I feel like their docs and/or driver model could be more friendly to someone who isn't intimately familiar with their peripheral architecture, though.  You definitely cannot write driver interfaces that differ much from their code examples using only the driver manual.  You need the chip reference manual to figure out how the hardware works, and then you can find the appropriate calls to set things up.  Certainly you have to do this, to some degree, on all platforms, but with Luminary's docs I got most of what I needed just from their driver manual, and from a few app notes.  This makes me wonder a bit about what things are like with other manufacturer's offerings :-)

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

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

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

_______________________________________________
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]

http://fanplastic.org/key.txt

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

[jbsnyder]

I quickly looked around to see if it would be easy to implement, and it appears to be quite a bit more complicated than XMODEM.  Recent up-to-date code is largely released under free for non-commercial use licenses, like the following:

Docs/code here:

http://pauillac.inria.fr/~doligez/zmodem/

The older, original code form 1988 is public domain though:

ftp://garbo.uwasa.fi/unix/goldies/rzsz-pd.zip

I'm thinking it wouldn't be too hard to use pyserial w/ the python curses module to make a pass-through terminal that behaves somewhat like screen, except provides support for xmodem.

On Mar 19, 2009, at 2:25 PM, James Snyder wrote:

I'm not sure if there's a way to do it with XMODEM, but there is for ZMODEM:

http://adammonsen.com/post/256

So I assume if eLua had ZMODEM support you could do the send example, replacing rz with recv from the eLua shell.

-jsnyder

On Mar 19, 2009, at 1:48 PM, Bogdan Marinescu wrote:

Oh yes, I tried CuteCom a while ago. I'll give them credit for choosing the name: "cute" describes it perfectly. Simple interface, very little functionality. Cute, but wrong :)
I also think screen is the best choice in Linux, better than minicom anyway. But can you do XMODEM from screen?

Best,
Bogdan

On Thu, Mar 19, 2009 at 8:43 PM, James Snyder <[hidden email]> wrote:

FYI: CuteCom is basically like Bray's terminal, if you've used it on windows.  It doesn't really handle terminal characters, so anything that's drawing text on the screen with term isn't going to work correctly.

Oh well :-)

-jsnyder

On Mar 19, 2009, at 1:11 PM, James Snyder wrote:

On Mar 19, 2009, at 3:10 AM, Bogdan Marinescu wrote:

Between this and the new patches Bogdan committed for being agnostic about line endings, I can now cut windows out of the loop for STM32 development :-)

You da man! :) Out of curiosity, what terminal emulator are you using in Linux? I was unable to find a decent one ("decent"=something that could compete with TeraTerm).

I haven't yet found something that is as easy to work with as TeraTerm, which I do find somewhat irritating.  For quick and dirty stuff (no transfers, just console) I just use screen, which one can fire up by just pointing it at the tty device (screen /dev/ttyUSB0 115200).

I've tried a few things including minicom, and haven't been thrilled with them.  One thing that I just stumbled upon, and haven't tried yet is CuteCom (http://cutecom.sourceforge.net/).  I'm going to try and compile that on my Mac, it looks like it's at least in the Ubuntu repositories though.

If that doesn't work well, I'll be further tempted to try and hack something together in Python... :-)

 

FYI: I have an ADC implementation for STM32 that should basically work, but something is causing a hang on boot when I enable the ADC peripheral clock on boot.  I'll commit that and some changes to elua_adc that allow it to handle situations where a single interrupt gives you values from a series of channels.

Good news, keep up the good work! After all the docs I wrote (and I'm still writing) I'm not even sure I know how to program anymore :)

I'm sure it'll come back to you :-)

I did get past that other issue I had mentioned, which, if I recall, came down to some issues of ordering the startup sequence.

I've found that the Stellaris platform is much easier to write something and have it behave the way you expect it to, without having to dig through large swaths of the reference documentation for the hardware.  That simplicity does have a cost, in that there's way more flexibility with STM32, but I find it takes more time to debug, and that solutions are sometimes non-obvious after the fact :-)  I don't think I'm alone there, since I've seen plenty of discussions on the STM32 forums that sound similar to my own experiences.

Right now non-clocked conversion seems to work OK, and it runs at a similar speed to LM3S6965 with adcscope.lua.  While this chip is clocked faster, I think it's not bad for a first pass at settings things up.  Their DMA support also allows for some flexibility that, in some ways, I like better than the dedicated FIFOs on Luminary.  The DMA includes both source and destination address incrementation, and has separate interrupts for half-full/complete events. 

I feel like their docs and/or driver model could be more friendly to someone who isn't intimately familiar with their peripheral architecture, though.  You definitely cannot write driver interfaces that differ much from their code examples using only the driver manual.  You need the chip reference manual to figure out how the hardware works, and then you can find the appropriate calls to set things up.  Certainly you have to do this, to some degree, on all platforms, but with Luminary's docs I got most of what I needed just from their driver manual, and from a few app notes.  This makes me wonder a bit about what things are like with other manufacturer's offerings :-)

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

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

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

_______________________________________________
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]

http://fanplastic.org/key.txt

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

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

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

[Arnim Littek]

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of James Snyder [[hidden email]]
> > terminal emulator are you using in Linux? I was unable to find a decent one ("decent"=something that could compete with TeraTerm).

> If that doesn't work well, I'll be further tempted to try and hack something together in Python... :-)

I haven't looked hard yet at what can be done with Lua, but in Python, knocking up something is trivially easy.  Starting with the sample code in the pyserial package, you hardly have to think about it.

A first pass two-channel logger cost me 40 lines of Python.  It has grown a bit over time, but is extensively used here.

Like you're saying here, I've been unsatisfied with terminal emulator/serial port software for Linux, and have munged one together that suits, based on the above.

And more recently I had the need to do a terminal emulator with independent Tx and Rx speeds, which required some trivial hacking of pyserial, but seems to work too.

I'd put the code up, but it is just hacks, and you can roll your own in an hour anyway.

Arnim.

Please consider the environment before printing this email
Warning:  This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails.
The views expressed in this email may not be those of Sirtrack. http://www.sirtrack.com
_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

[Georges]

Hi,

 

I am still using Elua O.5 with my Olimex SAM7EX256 board.

 

Has anybody a driver for the LCD Screen ( GE8 type ) or the SD Card ?

 

 

            Best regards

 

 

                          Georges

 

 

 

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

[jbsnyder]

Thanks for the encouragement.  I figured that even with the XMODEM  
stuff, it should be possible to get something working in under a  
hundred lines.  If you've had success doing dual channel in 40 lines,  
perhaps that's even an over-estimate, given rz and sz are available as  
system commands on many unix-like operating systems (haven't seen a  
python module).

Did you have something that was passing through terminal commands?  
I've not looked at the curses module much, but it seems like this  
would be the right thing to use to pipe the stuff coming in over  
serial through to whatever console was in use.

If I do anything more than a hack, I'll be sure to post it.

On Mar 19, 2009, at 3:54 PM, Arnim Littek wrote:

>
> ________________________________________
> From: [hidden email] [[hidden email]
> ] On Behalf Of James Snyder [[hidden email]]
>>> terminal emulator are you using in Linux? I was unable to find a  
>>> decent one ("decent"=something that could compete with TeraTerm).
>
>> If that doesn't work well, I'll be further tempted to try and hack  
>> something together in Python... :-)
>
> I haven't looked hard yet at what can be done with Lua, but in  
> Python, knocking up something is trivially easy.  Starting with the  
> sample code in the pyserial package, you hardly have to think about  
> it.
>
> A first pass two-channel logger cost me 40 lines of Python.  It has  
> grown a bit over time, but is extensively used here.
>
> Like you're saying here, I've been unsatisfied with terminal  
> emulator/serial port software for Linux, and have munged one  
> together that suits, based on the above.
>
> And more recently I had the need to do a terminal emulator with  
> independent Tx and Rx speeds, which required some trivial hacking of  
> pyserial, but seems to work too.
>
> I'd put the code up, but it is just hacks, and you can roll your own  
> in an hour anyway.
>
> Arnim.
>
> Please consider the environment before printing this email
> Warning:  This electronic message together with any attachments is  
> confidential. If you receive it in error: (i) you must not read,  
> use, disclose, copy or retain it; (ii) please contact the sender  
> immediately by reply email and then delete the emails.
> The views expressed in this email may not be those of Sirtrack. http://www.sirtrack.com
> _______________________________________________
> Elua-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/elua-dev

--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
http://fanplastic.org/key.txt


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

[BogdanM]

Did you have something that was passing through terminal commands?  I've not looked at the curses module much, but it seems like this would be the right thing to use to pipe the stuff coming in over serial through to whatever console was in use.

Really? I thought curses only deals with graphical terminal manipulation.
Nice idea, and maybe it would give us something quick&easy to use. I have a bigger idea for eLua, a complete dev env based on Scite (probably), but no resources to do something like that yet. So let's start small :) it would be great to have even some small steps in this direction.

Best,
Bogdan

On Mar 19, 2009, at 3:54 PM, Arnim Littek wrote:

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of James Snyder [[hidden email]]

terminal emulator are you using in Linux? I was unable to find a decent one ("decent"=something that could compete with TeraTerm).

If that doesn't work well, I'll be further tempted to try and hack something together in Python... :-)

I haven't looked hard yet at what can be done with Lua, but in Python, knocking up something is trivially easy.  Starting with the sample code in the pyserial package, you hardly have to think about it.

A first pass two-channel logger cost me 40 lines of Python.  It has grown a bit over time, but is extensively used here.

Like you're saying here, I've been unsatisfied with terminal emulator/serial port software for Linux, and have munged one together that suits, based on the above.

And more recently I had the need to do a terminal emulator with independent Tx and Rx speeds, which required some trivial hacking of pyserial, but seems to work too.

I'd put the code up, but it is just hacks, and you can roll your own in an hour anyway.

Arnim.

Please consider the environment before printing this email
Warning:  This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails.
The views expressed in this email may not be those of Sirtrack. http://www.sirtrack.com
_______________________________________________
Elua-dev mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/elua-dev

--
James Snyder
Biomedical Engineering
Northwestern University
[hidden email]
http://fanplastic.org/key.txt

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

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

[jbsnyder]

On Mar 20, 2009, at 2:48 PM, Bogdan Marinescu wrote:

Did you have something that was passing through terminal commands?  I've not looked at the curses module much, but it seems like this would be the right thing to use to pipe the stuff coming in over serial through to whatever console was in use.

Really? I thought curses only deals with graphical terminal manipulation.

Right, and it handles all the basic cell-character stuff.  Is it definitely needed?  I'm not sure, but I have a sneaking suspicion that one needs more than pyserial to print output/read input, and still have it behave like a term.

Certainly, though (I'm not suggesting that I love ncurses interfaces :-) ), even if that's not the case, you do get some other benefits to draw information about the current connection and progress for file transfers and the like.

Wrapping this all into a GUI I think requires a little more effort because if one does want to have a terminal emulator embedded into it, in order for the lua term stuff to work, you need to either find something that provides that or build your own.

Someone did build a terminal with python and PyGTK: http://reflog.googlepages.com/, but I've not read through to see if it required building the terminal using pretty raw primitives, or if you got all that mostly for free.

Nice idea, and maybe it would give us something quick&easy to use. I have a bigger idea for eLua, a complete dev env based on Scite (probably), but no resources to do something like that yet. So let's start small :) it would be great to have even some small steps in this direction.

A full dev environment would be quite nice :-)  I think if it's something that can be sketched out with a minimal amount of code in Python or some other language, it would be a good way to get started.

I would say that for getting a lot of users, it would be best to have something that can be installed on Mac, Linux/UNIX, and Windows, look fairly native, and require no messing around to get it working in the first place (so long as the hardware is all set up correctly).

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

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

[jbsnyder]

There is an SD card driver that is in one of the branches of subversion, however, at the moment it is only ported to the LM3S platform.  I don't believe it would be too complicated to port.

Based on previous discussions on the list, this won't go into the upcoming 0.6 release.

Regarding the LCD, we have drivers on other platforms for certain ones, but I don't believe there's one for GE8 type ones as of yet.

On Mar 19, 2009, at 4:49 PM, georges King wrote:

Hi,

 

I am still using Elua O.5 with my Olimex SAM7EX256 board.

 

Has anybody a driver for the LCD Screen ( GE8 type ) or the SD Card ?

 

 

            Best regards

 

 

                          Georges

 

 

 

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

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

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

[BogdanM]

Right, and it handles all the basic cell-character stuff.  Is it definitely needed?  I'm not sure, but I have a sneaking suspicion that one needs more than pyserial to print output/read input, and still have it behave like a term.

If you're going text mode, you're probably OK with using only ANSI escape sequences if your term supports them (and 99%+ of them do).
 

Someone did build a terminal with python and PyGTK: http://reflog.googlepages.com/, but I've not read through to see if it required building the terminal using pretty raw primitives, or if you got all that mostly for free.

Interesting, I'll take a look at that, might be a good starting point.

 

I would say that for getting a lot of users, it would be best to have something that can be installed on Mac, Linux/UNIX, and Windows, look fairly native, and require no messing around to get it working in the first place (so long as the hardware is all set up correctly).

That's why I thought about SciTE in the first place. Open source, fully integrated with Lua (or the other way around :) ), and it runs on all the platforms you mentioned (although I think it requires some tricks for Mac, can't test this though). And not that hard to modify from what I saw. I also thought about starting from a very small codebase and build from there, but SciTE seems to offer just about everything we need. Just begging to serve us :)

Best,
Bogdan

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

[jbsnyder]

On Mar 21, 2009, at 5:37 AM, Bogdan Marinescu wrote:

That's why I thought about SciTE in the first place. Open source, fully integrated with Lua (or the other way around :) ), and it runs on all the platforms you mentioned (although I think it requires some tricks for Mac, can't test this though). And not that hard to modify from what I saw. I also thought about starting from a very small codebase and build from there, but SciTE seems to offer just about everything we need. Just begging to serve us :)

I'll have to check out SciTE, I see they indicate Mac OS X support, so I'm curious if that means they're using the new GTK+ OS X framework, or just running in X11.  It should be possible to get it working with the new framework.

While poking around a little, I also ran across Textadept:

http://code.google.com/p/textadept/

"Textadept is a fast, minimalist, and ridiculously extensible text editor for Linux, Mac OSX, and Windows. The C++ core will always be less than 2000 lines of code (excluding comments and blank lines) and contains the bare framework for a text editor. More than half of the C++ base is the Lua extension, and nearly everything in Textadept is controlled by Lua, making the editor's extensibility almost limitless."

This sounds interesting as well :-)

--

James Snyder

Biomedical Engineering

Northwestern University

[hidden email]

http://fanplastic.org/key.txt

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

[Aret Carlsen]

This is the only Linux tool for STM32 flash writing that I've been able to find.

Running Ubuntu-Eee, I had to "apt-get install python-serial".

I spent a number of hours trying to debug why my writes weren't verifying before I realized that you have to erase on every write, at least for my STM32F103 (Futurlec board).  That's the "-e" option.

When trying to read to a file, I received this error:

Traceback (most recent call last):
  File "./stm32loader.py", line 392, in <module>
    file(args[0], 'wb').write(rdata)
TypeError: argument 1 must be string or read-only buffer, not list

The fix was to replace line 392 with:

# previously: file(args[0], 'wb').write(rdata)
file(args[0], 'wb').write(''.join(map(chr,rdata)))

[Dado Sutter]

Thanks for the report !
   I've heard that the STM32F103 comes with a different MCU than what is stated on the site.
   I've been trying to get a http://www.futurlec.com/ET-STM32_Stamp.shtml for some months now :(
   It is nice to know we can flash them from Linux !
 
Welcome to the list!
Regards
Dado

On Thu, Apr 2, 2009 at 20:40, Aret Carlsen <[hidden email]> wrote:

This is the only Linux tool for STM32 flash writing that I've been able to find.

Running Ubuntu-Eee, I had to "apt-get install python-serial".

I spent a number of hours trying to debug why my writes weren't verifying before I realized that you have to erase on every write, at least for my STM32F103 (Futurlec board).  That's the "-e" option.

When trying to read to a file, I received this error:


Traceback (most recent call last):
 File "./stm32loader.py", line 392, in <module>
   file(args[0], 'wb').write(rdata)
TypeError: argument 1 must be string or read-only buffer, not list


The fix was to replace line 392 with:

# previously: file(args[0], 'wb').write(rdata)
file(args[0], 'wb').write(''.join(map(chr,rdata)))


--
View this message in context: http://n2.nabble.com/STM32-Bootloader-Flashing-in-Python-tp2499766p2578184.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

[jbsnyder]

----- "Aret Carlsen" <[hidden email]> wrote:

> This is the only Linux tool for STM32 flash writing that I've been
> able to find.
>
> Running Ubuntu-Eee, I had to "apt-get install python-serial".
>
> I spent a number of hours trying to debug why my writes weren't
> verifying before I realized that you have to erase on every write, at
> least for my STM32F103 (Futurlec board).  That's the "-e" option.

Yeah, I have to do the same.  This seems to often be the case with flash programming whether from a bootloader or JTAG.

I've also got a slightly updated version of the code which will do a progress bar if you also have the progressbar module available.

>
> When trying to read to a file, I received this error:
>
>
> Traceback (most recent call last):
>   File "./stm32loader.py", line 392, in <module>
>     file(args[0], 'wb').write(rdata)
> TypeError: argument 1 must be string or read-only buffer, not list
>
>
> The fix was to replace line 392 with:
>
> # previously: file(args[0], 'wb').write(rdata)
> file(args[0], 'wb').write(''.join(map(chr,rdata)))

I've not tried copying what is in flash back to disk, thanks for the tip.

>
>
> --
> View this message in context:
> http://n2.nabble.com/STM32-Bootloader-Flashing-in-Python-tp2499766p2578184.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