Wow, fantastic! This was on my TODO list, so thanks for getting it working!

Normally I would make a separate directory (like unix/, stm/) for each port. Really, stm/ should be pyboard/, and there should be an stm32f4disc/ port directory.

BUT, in this case it seems that the F4disc is so similar that we should just have a few #define to select either pyboard or stm32f4disc.

So, if you want to go ahead and make defines for this board that would be great!

well alright then, I will finish up and send a pull request :)

I have also tried to run on the STM32F4Discovery board with some success. I have made the changes to rtc_init and sw_init and remapped the LEDs. I un-commented the usart_init and was able to interface to a USB to ttl converter connected to port pins PC6 and PC7. When I connect to the USB, I get a virtual com port on my Windows 8 PC but it does not communicate and I do not get a virtual disk drive. What do I need to get the virtual Disc and Com to work?

not sure, it worked out of the box, it showed up as MSD and CDC, on Linux

Oh, it might need a .inf or something like that, I'm not very good with windows..

For some practice :-) , I loaded espruino onto the STM32F4Discovery. In that setup, comms is done via the other USB port, i.e. no USB to ttl needed? I did need to download driver software from st.com

Normally I would make a separate directory (like unix/, stm/) for each port.

Well, there dozen+ Cortex-M vendors, each have dozens of MCUs, and one can make unlimited number of boards with each one (differing in which external device connected to which pin). That's the case I meant in #19 (hope to elaborate on it there still). So, one dir per port? Sounds good if it contains only mpconfigport.h, less good if 95% duplication of other dir (even worse if stuff written from scratch which is just duplication of another dir).

Let's take example of stm/usrsw.c:

#define PYB_USRSW_PORT (GPIOA)
#define PYB_USRSW_PIN (GPIO_Pin_13)

Those things don't belong there, but rather in mpconfigport.h. Then, usrsw module will support any stm MCU and any board.

Could the .inf file be "faked" by the source code when connected to a
computer instead of being a real file on the filesystem?

Send from my Samsung Galaxy Note II
El 05/01/2014 16:35, "Ibrahim Abd Elkader" notifications@github.com
escribió:

Oh, it might need a .inf or something like that, I'm not very good with
windows..

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/83#issuecomment-31606884
.

Normally I would make a separate directory (like unix/, stm/) for each
port.

Well, there dozen+ Cortex-M vendors, each have dozens of MCUs, and one
can make unlimited number of boards with each one (differing in which
external device connected to which pin). That's the case I meant in #19
(hope to elaborate on it there still). So, one dir per port? Sounds good if
it contains only mpconfigport.h, less good if 95% duplication of other dir
(even worse if stuff written from scratch which is just duplication of
another dir).

That's why each time I'm more convinced about using kconfig and set each
feature by #defines...

mpconfigport.h is for configuring the py/ part (the Python part). There should be nothing in there specific to boards.

We will need another config file specifically for board related stuff. Like in stm/ it would be stmconfig.h.

Then it's a tough question whether a new port is just a variation of an existing one (with #define's) or is a completely new subdirectory.

+1 for stmconfig.h I was thinking those #ifdef should be moved to a single header eventually, I've made some changes to the LED module, it now only requires a single #ifdef in one place to define the ports, pins and high/low without cluttering the code with #ifdef's now this can be moved to stmconfig.h the same can be done for other modules I guess..

A port to a micro in same series/family should be in the same directory, one for each series I think. different series will require different linker script and system init code...

oh, but I still think some code should be pulled out of stm/ the python code and bindings maybe...

We will need another config file specifically for board related stuff. Like in stm/ it would be stmconfig.h.

... Or we can think if we need this config proliferation and instead can treat mpconfigport.h as single config for a particular build (which includes both interpreter, board, etc. configuration).

Then it's a tough question whether a new port is just a variation of an existing one (with #define's) or is a completely new subdirectory.

What I'm advocating is to have a "default" stance of trying to refactor existing code and try to make it more parametrizable (i.e. config/data-driven), before giving up and duplicating it. This is contrary to how embedded projects are usually done - mostly people care only about what they have on their hands now and not how well that fits with what dozens and hundreds of other people are doing. Over time, big mess ensues. Take example of ARM support in Linux - it grew into Augean stables over last years, until Torvalds threated to just throw it out of the main tree. Only then great ARM feuds sit together to adopt Device Tree approach, which is exactly data-driven approach to configure all the drivers which in 90% differ in nothing but freq divisors and GPIOs used. We can learn from the history ;-).

Could the .inf file be "faked" by the source code when connected to a
computer instead of being a real file on the filesystem?

I don't think so, it's like a driver or something, Windows needs it even for standard USB classes.. the Arduino and the FTDI chips use one.

Could the .inf file be "faked" by the source code when connected to a
computer instead of being a real file on the filesystem?

I don't think so, it's like a driver or something, Windows needs it even
for standard USB classes.. the Arduino and the FTDI chips use one.

I don't know if the flash content is showed directly to the desktop
computer or is served by the microcontroler, in that later case I'm talking
about adding an entry point to a fake file that host the driver in a source
code string, instead of being a real file that can be changed or deleted.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

ah I see, yes the flash shows up as a small disk.

ah I see, yes the flash shows up as a small disk.

So the flash is accessed directly and it's not possible to add the fake
file. Ok, don't worry, it was just an idea :-)

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

So the flash is accessed directly and it's not possible to add the fake

why not ? the flash is accessible just like any regular flash stick, the micro exports part of its internal flash as a mass storage device, so I guess it can show a fake file, the mbed does something similar..

So the flash is accessed directly and it's not possible to add the fake

why not ? the flash is accessible just like any regular flash stick, the
micro exports part of its internal flash as a mass storage device, so I
guess it can show a fake file, the mbed does something similar..

If so, then it would be interesting to add it...

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

Excuse a retired ASM programmer who only knows how to cross
assemble/compile from a wdws ide, but the .inf file needed by
windows to recognise a usb device, lives in windows directory space -
root if you will - it is a config file and describes what the USB device
is, VID & PID and how to handle it, it does NOT live on the incoming
usb device so faking it is not very easy unless you are a W__d*ws
operating systems expert - equipped with quality Hackers Kit. (bit of an
overstement, but emulating a windows keyboard, breaking down to DOS etc
etc etc :eeek: )..
I Haven't read the micro datasheet yet, but I doubt the boot loader can
emulate a USB data stick well enough to present its flash memory, filing
system structure and all, to the outside world ..
I'd be happy to be told I was very wrong.
regards

On 05/01/2014 6:21 PM, Ibrahim Abd Elkader wrote:

So the flash is accessed directly and it's not possible to add the
fake

why not ? the flash is accessible just like any regular flash stick,
the micro exports part of its internal flash as a mass storage device,
so I guess it can show a fake file, the mbed does something similar..

—
Reply to this email directly or view it on GitHub
#83 (comment).

No virus found in this message.
Checked by AVG - www.avg.com http://www.avg.com
Version: 2013.0.3462 / Virus Database: 3658/6977 - Release Date: 01/05/14

I think the idea is to have the inf file on the same flash so you can just copy it instead of downloading it from somewhere, like for example I have a USB modem which also shows up as a flash drive that has drivers and datasheets.

but I doubt the boot loader can
emulate a USB data stick well enough to present its flash memory

The bootloader doesn't handle this, the code running on micro emulates both a VCP and MSC (mass storage class) using part of the flash, so yes it is possible.

I see three discovery boards for the STM32F4 on the stm site:

• STM32F429ZI
  • LQFP144 onchip 2MB flashROM, 256KB RAM
  • with mems 3axis Gyro, 2.4inch TFT, and 64MBits RAM
  • $25 USD direct
• STM32F407VG
  • LQFP100 onchip 1MB flashROM, 192KB RAM
  • with accelerometer, mems microphone, audio amp
  • $15 USD direct
• STM32F401VC
  • LQFP100 onchip 256KB flashROM, 64KB RAM
  • with 3axis gyro, 3axis accelerometer, 3axis compass, mems microphopne, audio amp
  • $14 USD direct

Which one(s) are you guys working on ?

So, one dir per port? Sounds good if it contains only mpconfigport.h, less good if 95% duplication of other dir (even worse if stuff written from scratch which is just duplication of another dir).

What I'm advocating is to have a "default" stance of trying to refactor existing code [...]. This is contrary to how embedded projects are usually done - mostly people care only about what they have on their hands now and not how well that fits with what dozens and hundreds of other people are doing. Over time, big mess ensues.

And it doesn't take long time to prove I'm right - #97. There're verbatim copies of: string0.c, gchelper.c, printf.c, malloc0.c (well, some files actually have random changes in them).

Now, if someone fixes/improve stm/printf.c, who will do monkey job of propagating those changes across this, and then dozens of other "ports"? Probably noone, because whoever does changes to printf.c, won't care that there're other ports which duplicate it, just the same as people who created those ports didn't care that they're 90% duplication of existing code.

Over time, big mess ensues.

So we need to define a policy then not accept pull requests unless policy is followed.
Hopefully this will persuade contributor to follow policy and help out...
What is it ?
Where do we put it and explain it ?

Well, we do discuss what such policy might be, with different opinions from different sides.

Note that this matter is usually two-fold for typical open-source projects - from one side, it's great that people contribute and supporting and appreciating that is a way to increase contribution, and setting too perfectionist threshold is a way in opposite direction (and I personally don't want to be PITA to impede people's contributing). On the other hand, accepting quickly hacked-up ports will lead to mess and increased maintenance efforts, taking time from more important things.

I don't think that "we" can decide how to go about it - it's ultimately Damien's project. But unlike typical FOSS project, it's backed by commercial effort and there's product to deliver. And formally, all these extra boards are competing with Damien's. I'm sure Damien doesn't want to suppress other ports, but on the other hand, if people give some code drop and say "Hey Damien, here's code for competing board, now take it, and spend your time maintaining it, risking delivery of your own product", then he may say "Cool, but please make it clean, so it can be maintained without much effort". And such approach actually may be more beneficial for the project and community.

Well, just imagining and contemplating here ;-).

I think the idea is to have the inf file on the same flash so you can just
copy it instead of downloading it from somewhere, like for example I have a
USB modem which also shows up as a flash drive that has drivers and
datasheets.

but I doubt the boot loader can
emulate a USB data stick well enough to present its flash memory

The bootloader doesn't handle this, the code running on micro emulates
both a VCP and MSC (mass storage class) using part of the flash, so yes it
is possible.

To don't continue with the offtopic, I've created the new issue #101 just
to discuss it.

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton
de sitios diferentes, simplemente escribe un sistema operativo Unix."
– Linus Tordvals, creador del sistema operativo Linux

I think string.c, gchelper.c, printf.c, malloc etc.. will be moved out of stm/ eventually, maybe this should be done sooner so no one will have to duplicate those files when porting, I imagine then each port will only have the platform specific code for low level I/O etc.. and link with the other stuff...

@Neon22 thanks for your input. My experience with MODBUS so far is using the modpoll simulator (http://www.focus-sw.com/fieldtalk/modpoll.html) to talk to a Midnite Solar charge controller. Some of my adventures can be found here:

http://midniteforum.com/index.php?PHPSESSID=qaou7qfeebj9jhqo6vbcfln3i1&topic=1431.msg11753#msg11753

I feel this discussion has strayed somewhat from the original title at the top of the page and am feeling a little guilty for pushing it forward here. However I am so grateful for all your input and would love to continue it. I also think, even if I say so myself, that a project like mine would be a good showcase for the micro python project. @dpgeorge are you interested in the showcase project concept?

Essentially what I am looking for is a bit of support in the form of answering questions like this:

My typical thought process:

• modbus_tk is dependent on pyserial
• looking in the micropython/stm directory I don't see any sign of serial support yet, humpf...
• with a bit of guidance I wouldn't mind giving serial support a bash (says he with his tail wagging...but not much of a clue of what is involved ;) )
• once serial support is covered, how would one incorporate a library like modbus_tk in the micro python build process?

Any suggestions where we could migrate this discussion to a more appropriate location?

If you're looking for serial support, look in usart.c in the stm directory.

Is the lcd module broken? Or is lcd support for Discovery board broken? I got this on my Discovery board:

Micro Python build <git hash> on 25/1/2014; F4DISC with STM32F405RG
Type "help()" for more information.
>>> dir()
['LCD', 'help', 'pyb', 'timer', 'micropython', 'open', '__name__']
>>> LCD
<function>
>>> LCD.get(0,0)
Traceback (most recent call last):
  File "<stdin>", in <module>
AttributeError: 'function' object has no attribute 'get'
>>> lcd=LCD()
>>> dir()
['LCD', 'lcd', 'help', 'pyb', 'timer', 'micropython', 'open', '__name__']
>>> lcd
<class 'LCD'>
>>> lcd.get(0,0)
0
>>> lcd.set(0,0)
>>> lcd.get(0,0)
0

LCD is a function? You will get a class if you call LCD? Don't know if I should open a new issue for this.

Shouldn't LCD be an importable module?

Send from my Samsung Galaxy Note II
El 06/02/2014 15:51, "xyb" notifications@github.com escribió:

Is the lcd module broken? Or is lcd support for Discovery board broken? I
got this on my Discovery board:

Micro Python build on 25/1/2014; F4DISC with STM32F405RG
Type "help()" for more information.

dir()
['LCD', 'help', 'pyb', 'timer', 'micropython', 'open', 'name']
LCD

LCD.get(0,0)
Traceback (most recent call last):
File "", in
AttributeError: 'function' object has no attribute 'get'
lcd=LCD()
dir()
['LCD', 'lcd', 'help', 'pyb', 'timer', 'micropython', 'open', 'name']
lcd
<class 'LCD'>
lcd.get(0,0)
0
lcd.set(0,0)
lcd.get(0,0)
0

LCD is a function? You will get a class if you call LCD? Don't know if I
should open a new issue for this.

Reply to this email directly or view it on GitHubhttps://github.com//issues/83#issuecomment-34329416
.

LCD is a pre-loaded builtin module now, and you can't import it:

>>> import LCD
Traceback (most recent call last):
  File "<stdin>", in <module>
ImportError: ImportError: No module named 'LCD'
>>> import lcd
Traceback (most recent call last):
  File "<stdin>", in <module>
ImportError: ImportError: No module named 'lcd'

Maybe LCD should be an import-able module?

Yes, I think it should be a non pre-loaded, importable module.

Send from my Samsung Galaxy Note II
El 06/02/2014 16:01, "xyb" notifications@github.com escribió:

LCD is a pre-loaded builtin module now, and you can't import it:

import LCD
Traceback (most recent call last):
File "", in
ImportError: ImportError: No module named 'LCD'
import lcd
Traceback (most recent call last):
File "", in
ImportError: ImportError: No module named 'lcd'

Maybe LCD should be an import-able module?

Reply to this email directly or view it on GitHubhttps://github.com//issues/83#issuecomment-34330439
.

Yes, LCD should be something you can import.

LCD (at the moment) is the driver for the specific LCD that I have and that will ship with the kits. LCD support for other modules, like the Discovery board, needs a completely different driver.

@royemmerich re showcase: for now I want to get the pyboard fully working, and that will be the first "showcase" :) After that can come other cases, but most likely by others (like yourself) doing the coding.

Can you help Port it to NXP'S LPC 1768 ARM cortex M3 Boards ?

Hi! I got it working... but pyb.Accel() seems not to be implemented for the board. Are there plans on this?

@marcel12bell pyb.Accel() is specifically for the pyboard. I don't have the time to make it work with the sensor on the STM32F4DISC, but if you or someone else does, please submit a PR and I'll happily merge it.

Now supported. Build in stmhal/ directory with make BOARD=STMF4DISC.

@dpgeorge thanks! Make and flashing worked, but the board is not showing the tty port like usually. Is there another output of the terminal over uart?

Does it present a USB flash drive? If so, it should also present a CDC device for the tty port.

Otherwise, there is an option on line 308 of main.c to put the REPL on UART6.

It all works fine for me following these instructions:

https://github.com/micropython/micropython/wiki/Board-STM32F407-Discovery

sorry, I was in the fork from iabdalkader on building. now it worked fine.

Hi Guys,

I am not an expert in microprocessor programming but would like to start understanding and using it. I bought STM32407 -Discovery board to port python, but am completely lost in how to start to port it. I have never done porting before and I tried looking up online to see the steps to do it but so far no luck

can anyone, please guide me and send me the necessary steps either in windows or in ubuntu so that i can port is successfully.

Thanks

Already ported. Just follow these instructions.

https://github.com/micropython/micropython/wiki/Board-STM32F407-Discovery
On 2 May 2016 19:13, "55win" notifications@github.com wrote:

can anyone, please guide me and send me the necessary steps either in
windows or in ubuntu so that i can port is successfully.

Thanks

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#83 (comment)

Thanks Paul. Will follow the instructions.