I am not sure how this phpBBS quoting works. If I messed up in my reply my apologies in advance. I tried and backed out better quoting attempts. I just messed up too much trying. I do not use lists often and more the test/eMail based ones when I do.

Slammer wrote:

keypunch wrote:
1) Can I use this in usual IDE approach using Linux? I do not use Windows, do not have Windows, no thank you if I can avoid. Thoughs on pros and cons for a strickly Linux based development of the Iteadmaple?

IDE is working under linux. No problem.

keypunch: Wonderful.

keypunch wrote:
2) There is this USB for serial and DFU matter some have experienced and some have not.

USB serial is working as advertised. Sometimes you need to repeat the download process, but it is OK.

keypunch: This means one does not the have to press one or both bottons on board?

keypunch wrote:
3) Are there new/alternative bootloaders that can be used? If so pros and cons. I have read a little about this over past week, but not enough yet to know.

It is better to use the bootloader V2, requires less memory.

keypunch: Is Bootloader V2 a load after have board to replace bootloader that board came with or some boards come with V2 already?

keypunch wrote:
4) I assume the ADCs are 10 bit?

No. ADC of F103 are 12 bit.

keypunch: That is bonus for sure.

keypunch wrote:
5) It appears shields may be a challenge for the pins G, 23-37 of Iteadmaple.

Dont expect full adruino shield compatibility. Some of them are working without modifications, some other no for various reasons

keypunch: I was not expecting full compatibility given the G,23-37 Pin block. I asked in case there were interesting tips, sources, etc I have not stumbled on via research in internet so far. Example was only last week did this board appear in search happened to fall into criteria for not knowing about board or any similar board. This after a few months of searcing, reading, etc. Hence the question.

keypunch wrote:
6) I assume I will have enough pins left over to use some I2C devices if I need to and more than pair in event I have some I2C device address conflicts that cannot be resolved with jumpers (cable or pin headers)?

You can use two I2C interfaces without problem.

keypunch wrote:
7) What experiences have you had as a datalogger using an SD card? No coding examples are needed unless you feel there is a need to explain. Just the pros, cons, unexpected, or same as any other Arduino experiences is what I am seeking.

As I know, the SD read/writing is working.

keypunch: Encouraging

keypunch wrote:
8) Does the UFC and USB serial matter also exist when using Linux? My sense is yes, based on how I understand the reason this is by choice of design of the bootloader. I am assuming even if there is no Windows driver factor when using Linux in the design of the bootloader that this will remain so in Linux as this is how the bootloader was designed. Therefore I am assuming that sets the behaviour no matter what OS one would use?

No problem in both systems with USB/Bootloader operation.

Note that while the STM32F103RE supports 16 ADC channels, these channels are not always available as various peripherals are using the same pins (for example UART2). You have to consider which peripherals are needed for your application and then to examine the pin allocation and the ADC pins availability.

The combinations of channels, ADCs, available with the multipin defined functions is what I am trying to sort out. I asked/hinted about in case there are any tips that are obvious I have not figured out or come across the single pin out diagram or similar to have a sense of.

In just a few words how would you compare this Iteadmaple/stm32 board to the Arduino Due Board and if same or different ported libraries are needed to ported libraries to Iteadmaple/stm32? No Need to comment about memory, 12 vs 16 ADC and clock speed differences and hope I have not missed noting other obvious differences.

I have found searching this site are some libraries ported that are on my main list. I will read a bit more on the library matter and if I have questions there seems to be a topic such questions can be asked.

keypunch wrote:
In just a few words how would you compare this Iteadmaple/stm32 board to the Arduino Due Board and if same or different ported libraries are needed to ported libraries to Iteadmaple/stm32? No Need to comment about memory, 12 vs 16 ADC and clock speed differences and hope I have not missed noting other obvious differences.

The Arduino Due uses a completely different MCU. The Due and STM32 share the same CPU core but the internal peripheral interface is completely different. If a library is ported to the Due it doesn't mean it will work on the STM32.
The only time a Due lib is more likely work, on the STM32, than an AVR library, is if someone has removed all the direct hardware access code from the AVR library and replaced it with normal high level GPIO and SPI or I2C calls e.g. replaced PORTx code with digitalRead and digitalWrite.

There are also some compatible boards (with STM32F103V/Z) with much more I/O pins, in these devices you will have no problem to use more pins for ADC and/or Digital I/O, and as bonus you will have more memory, more I2Cs, more UARTS, for your program.

keypunch wrote:
In just a few words how would you compare this Iteadmaple/stm32 board to the Arduino Due Board and if same or different ported libraries are needed to ported libraries to Iteadmaple/stm32? No Need to comment about memory, 12 vs 16 ADC and clock speed differences and hope I have not missed noting other obvious differences.

The Arduino Due uses a completely different MCU. The Due and STM32 share the same CPU core but the internal peripheral interface is completely different. If a library is ported to the Due it doesn't mean it will work on the STM32.
The only time a Due lib is more likely work, on the STM32, than an AVR library, is if someone has removed all the direct hardware access code from the AVR library and replaced it with normal high level GPIO and SPI or I2C calls e.g. replaced PORTx code with digitalRead and digitalWrite.

Roger,

Your comment has filled in some blanks I had not dug into yet.

I still have lots of blanks to fill in. This means I see the technical gaps in what I know has to be, but not the how is in what seems to be a larger Arduino concept of devices. This means seperating the concept and hardware layers. That is OK and does not throw me. I just need to learn what the gaps and layers are so I have my perspective the right way about for the Arduino concept.

Would a device classed as an STM32 have same MCU and by extension same ported libraries (I assume binaries from the ported source)? I ask so I have a sense of where I find the same hardware layer so I know if and when I am in need to determine if libraries need are ported or if I will take a go doing so.

As you know I have only looked at some sketches to have a sense of language and concept of how the Arduino runs code and what coding effort I will need and can apply to a program for the Arduino. I have never used an Arduino before. I understand quite well the nature of direct/low level vs high level API calls and what implications that has on code portability you noted that impacts porting code to different MCUs.

I'm not really sure where you are trying to get to, or precisely what your questions mean, but...

When you say STM32, you could be referring to about 1 of 1000 different MCU's

We have good support for the STM32F103 series (which probably amounts to 20 or more different MCU's) and the code probably works for most of the STM321xx devices (though with limitations)

However STM make the F1, F2, F3, F4, and F7 series, as well as the L0, .... Lx series

Binaries for the F1 will not run on the F2, etc, as the way the peripherals are controlled is subtly different between each series (and sometimes its completely different)

We also have moderate support in Libmaple for the F4 series, and some old code thats supposed to work with the F3 (but its very limited and untested)

So, a while ago, @sheepdoll started to write a new core that used STM's own HAL code rather than libmaple (originally written my Leaflabs)
@vassilis did some more work on this and it is at alpha stage and is the closest thing we have to a solution to writing code for the F7 or L0 etc etc (anything thats not an F103)

I'm not really sure where you are trying to get to, or precisely what your questions mean, but...

When you say STM32, you could be referring to about 1 of 1000 different MCU's

We have good support for the STM32F103 series (which probably amounts to 20 or more different MCU's) and the code probably works for most of the STM321xx devices (though with limitations)

However STM make the F1, F2, F3, F4, and F7 series, as well as the L0, .... Lx series

Binaries for the F1 will not run on the F2, etc, as the way the peripherals are controlled is subtly different between each series (and sometimes its completely different)

We also have moderate support in Libmaple for the F4 series, and some old code thats supposed to work with the F3 (but its very limited and untested)

So, a while ago, @sheepdoll started to write a new core that used STM's own HAL code rather than libmaple (originally written my Leaflabs)
@vassilis did some more work on this and it is at alpha stage and is the closest thing we have to a solution to writing code for the F7 or L0 etc etc (anything thats not an F103)

Roger,

Your answer was bang on to my question. It means you understood what I was asking.

The answer now gives me a sense of the subtle and not so subtle differences, not to mention the large number of variations. Clearly I need to do more research and evaluate what options, pros and cons to my reasons for considering a MCU.