Re: [Emc-users] STM32 Blue Pill --> distance between pins

[Jon Elson]

On 03/12/2019 10:25 PM, Gene Heskett wrote:


Here, I don't think I communicated that my problems were in the math to
properly space the slots the ATS-667's were nestled in. Purely a
mechanical mistake in carving the slots they hide in. I didn't grok that
half a tooth spacing was actually 180 degrees, not 90.

And, I made EXACTLY the same mistake!  But, after looking at 
the 180 degree phase difference on a scope for just a FEW 
minutes, I figured out what I had done wrong.  Mine was made 
with provisions for adjustment built in, but I had to widen 
the adjustment slot a bit to get it right.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill --> distance between pins

[Gene Heskett]

On Tuesday 12 March 2019 18:40:49 Chris Albertson wrote:

> > > So a Pi with an external STM32 may well send step/dir signals or
> > > SPI based messages to the driver but tracking that spindle encoder
> > > for threading is a bit more intensive.
>
> The STM32 chip has hardware quadrature decoders.  These are a set of
> flip-flops and counters that exist on the chip but outside the CPU.
> The CPU has access to the counters and can poll the count or reset
> them.
>
> Because it uses hardware it can handle a few MHz.The larger STM32
> chips have several sets of quadrature decoders the blue pill device
> only one usable decoder.
>
> I've also tried using interrupts  Placing the A and B quadrature
> signal on GPIO pins.   I can control two motors this way (using four
> interrupt pins) up to about 10,000 per second per pin.   But the
> hardware decoders at literally 1000 times faster and don't use up CPU
> cycles.
>
> This is an important part of selecting a chip.   Don't just look at
> the CPU, RAM, and ROM.   Most chips have a ton on peripheral hardware
> that can be used pick one that hasthe stuff you need.
>
> > Which is what I'm doing on the Sheldon, with an alu  bracket, curved
> > to match the size of the bull gear on the spindle. Biggest problem
> > was my math, getting the pair of ATS-667 hall effect sensors
> > properly spaced to get a decent quadrature timed set of pulses out
> > of it.

Here, I don't think I communicated that my problems were in the math to 
properly space the slots the ATS-667's were nestled in. Purely a 
mechanical mistake in carving the slots they hide in. I didn't grok that 
half a tooth spacing was actually 180 degrees, not 90.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill --> distance between pins

[Chris Albertson]

> > So a Pi with an external STM32 may well send step/dir signals or SPI
> > based messages to the driver but tracking that spindle encoder for
> > threading is a bit more intensive.


The STM32 chip has hardware quadrature decoders.  These are a set of
flip-flops and counters that exist on the chip but outside the CPU.
The CPU has access to the counters and can poll the count or reset
them.

Because it uses hardware it can handle a few MHz.The larger STM32
chips have several sets of quadrature decoders the blue pill device
only one usable decoder.

I've also tried using interrupts  Placing the A and B quadrature
signal on GPIO pins.   I can control two motors this way (using four
interrupt pins) up to about 10,000 per second per pin.   But the
hardware decoders at literally 1000 times faster and don't use up CPU
cycles.

This is an important part of selecting a chip.   Don't just look at
the CPU, RAM, and ROM.   Most chips have a ton on peripheral hardware
that can be used pick one that hasthe stuff you need.

> >
> Which is what I'm doing on the Sheldon, with an alu  bracket, curved to
> match the size of the bull gear on the spindle. Biggest problem was my
> math, getting the pair of ATS-667 hall effect sensors properly spaced to
> get a decent quadrature timed set of pulses out of it.
-- 

Chris Albertson
Redondo Beach, California


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Nicklas Karlsson]

> About the ICE, all ARM processors have hardware debuggers built-in.
>   This helps a LOT with the case you described where you must
> debugging in the field.   Just any notebook PC and a USB cable.

Debugger for ARM is good. Trace function is really good then available, 
printf(...) is often very useful.


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill --> Microchip pin configuration

[Nicklas Karlsson]

> Too true.  The level of support for Microchip still exceed many of the other 
> systems.  Having said that I'd still rather use MPLAB-8 compared to MPLAB-X 
> but I can see why Microchip had to go in that direction. ...

I remember Microchip Micro controllers have a lot more freedom then it come pin 
configuration. There signal should be used it is selected where it should come 
from. Many if not almost all others have chosen the opposite direction and 
there are collisions.


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Nicklas Karlsson]

> ...
> I upgraded the System Workbench for STM32 on my WIN-7 system and tried for 
> over an hour to create a simple Hello World Project.  It's been years since I 
> touched the ST family. ...

Now I think think it work really well but remember I had to struggle a while 
before.

I prefer the new LL drivers instead of the old HAL drivers but my programs are 
usually rather simple. I consider none of them really good. If compiler worked 
well registers should be a structure and there would be a warning if a value 
was uninitialized then higher level could be implemented on top of this but 
even going for a higher level programming there is always the problem if a bit 
is there are not.


Nicklas Karlsson


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Chris Albertson]

On Sun, Mar 10, 2019 at 8:30 PM John Dammeyer  wrote:
>
>
>
> > -Original Message-
> > From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> >
> > What market share gives a product familty is suport for a while eco
> > system.   For example I think the basic Arduino is not the best or
> > most usfull platform but because it is so popular there is so much
> > suport for it.   ANy device likey has an Arduino library written for
> > it and by know just about anyone can program an Arduno.
>
> The ESP8266 also has a nice following and Arduino support.
> >
> > Markit share gives you a wider base of support.  .
>
> Totally agree!
> >
> > On Sun, Mar 10, 2019 at 4:26 PM John Dammeyer 
> > wrote:
> >
> > > I upgraded the System Workbench for STM32 on my WIN-7
> >
> > that was the root of the problem.  That system is far to complex and
> > forces you to learn how each version of the chip works in too much
> > detail.
> >
>
> Too true.  The level of support for Microchip still exceed many of the other 
> systems.  Having said that I'd still rather use MPLAB-8 compared to MPLAB-X 
> but I can see why Microchip had to go in that direction.  Android and their 
> stupid little icons for everything currently rule the world and lately 
> everything has to have an android look and feel.
>
> > take that same STM32 and plug it into the Arduino IDE then simply do
> > file->example->blink and press the "load" icon and the LED blinks.
> >
> > On ARM's embed system it is about the same, you select the blinky
> > example, click "compile" then  drag the *.bin file to the STM32 device
> > and the LED blinks.
> >
> The biggest complaint about the Arduino is how effectively the IDE cleans up 
> after a compile.  You can't really install breakpoints or single step through 
> the machine code to see where it's going wrong.
>
> > Arduino is best if the program logic can fit in one loop, mbed gives
> > to a full RTOS.
> >
> > The System Workbench is almost never needed.  It is used only if you
> > are needing to do some very esoteric things wi the STM32 chip.
> >
> I disagree there.  But it could be we work on different kinds of projects.

If you use What Arm Holding (those are the folks in the UK who own the
ARM architecture) calls
their "preffered development system" then you can drag the "blinky"
demo to the STM32 chip
and the LED blinks.

You can also set breakpoints and step through lines of source code,
read and modify memory.  It all runs either on their ODE or you can
set it up on Eclipse.If you use their IDE it is about as easy as
Arduino.Another big deal
is the source code runs on the full family of ARM M chips.

You can do all this on Mac. Linux or Windows and the software open
source.ARM does not make chips, they sell linces the STM, TI and
everyone else so their motivation is to make the ARM chips so easy to
use that everying will use them.

You are correct about the lack of debug with Arduino. but they is
intended only for the most simple uses andtheir target users would not
know how to use a debugger.   Arm's eMbed is targeted at professionals
who are developing "edge devices", robots and so on.

About the ICE, all ARM processors have hardware debuggers built-in.
  This helps a LOT with the case you described where you must
debugging in the field.   Just any notebook PC and a USB cable.

I do remember the days when every chips needed it's own special
hardware develpment system.   Bt now JTAG works.



>
> One of my projects was located in the shop where I didn't have easy access to 
> the hardware.  I had to do the debugging and testing with print statements 
> and add commands to the interactive monitor to figure out why the mix of a 
> number of pseudo intelligent systems weren't behaving.When I was able to 
> get it back into the lab and connect to the ICE where I could throw in break 
> points debugging became easier and faster.
>
> Both techniques worked.  One just required hours while the other one required 
> minutes.
>
> I thought I'd lost my STM32F4 Discovery kit but just found it in the box with 
> the STMBL Servo parts.  It's listed as one of the debugging modules for the 
> STMBL.  In order to compile the code for the STMBLs two processors I ended up 
> creating a custom 16GB MicroSD for a Pi3B and wrote up a document exactly how 
> to 'make' a version and download it into the STMs on the STMBL.  No IDE 
> required because I'm not really working with the code.  Just doing a GIT for 
> the latest version and running make.  But that was 11 months ago.  Hard to 
> say if what I wrote up will make sense.
>
> So I will try to get the IDE working with the discovery kit.  But truthfully, 
> I like the PIC32 better.
>
> John
>
>
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



-- 

Chris Albertson
Redondo Beach, California

Re: [Emc-users] STM32 Blue Pill --> boot loader

[Kirk Wallace]

On 3/10/19 6:25 PM, Kirk Wallace wrote:
Thank you for the tips. I was hoping to make a webpage documenting what 
I have tried so far in more detail. Maybe it will get done tonight. 


Just in case of interest, here is what I have started:

http://wallacecompany.com/STM32_Blue_Pill/




--
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[John Dammeyer]

> -Original Message-
> From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> 
> What market share gives a product familty is suport for a while eco
> system.   For example I think the basic Arduino is not the best or
> most usfull platform but because it is so popular there is so much
> suport for it.   ANy device likey has an Arduino library written for
> it and by know just about anyone can program an Arduno.

The ESP8266 also has a nice following and Arduino support.
> 
> Markit share gives you a wider base of support.  .

Totally agree!
> 
> On Sun, Mar 10, 2019 at 4:26 PM John Dammeyer 
> wrote:
> 
> > I upgraded the System Workbench for STM32 on my WIN-7
> 
> that was the root of the problem.  That system is far to complex and
> forces you to learn how each version of the chip works in too much
> detail.
> 

Too true.  The level of support for Microchip still exceed many of the other 
systems.  Having said that I'd still rather use MPLAB-8 compared to MPLAB-X but 
I can see why Microchip had to go in that direction.  Android and their stupid 
little icons for everything currently rule the world and lately everything has 
to have an android look and feel.

> take that same STM32 and plug it into the Arduino IDE then simply do
> file->example->blink and press the "load" icon and the LED blinks.
> 
> On ARM's embed system it is about the same, you select the blinky
> example, click "compile" then  drag the *.bin file to the STM32 device
> and the LED blinks.
> 
The biggest complaint about the Arduino is how effectively the IDE cleans up 
after a compile.  You can't really install breakpoints or single step through 
the machine code to see where it's going wrong.  

> Arduino is best if the program logic can fit in one loop, mbed gives
> to a full RTOS.
> 
> The System Workbench is almost never needed.  It is used only if you
> are needing to do some very esoteric things wi the STM32 chip.
> 
I disagree there.  But it could be we work on different kinds of projects.  

One of my projects was located in the shop where I didn't have easy access to 
the hardware.  I had to do the debugging and testing with print statements and 
add commands to the interactive monitor to figure out why the mix of a number 
of pseudo intelligent systems weren't behaving.When I was able to get it 
back into the lab and connect to the ICE where I could throw in break points 
debugging became easier and faster.

Both techniques worked.  One just required hours while the other one required 
minutes.  

I thought I'd lost my STM32F4 Discovery kit but just found it in the box with 
the STMBL Servo parts.  It's listed as one of the debugging modules for the 
STMBL.  In order to compile the code for the STMBLs two processors I ended up 
creating a custom 16GB MicroSD for a Pi3B and wrote up a document exactly how 
to 'make' a version and download it into the STMs on the STMBL.  No IDE 
required because I'm not really working with the code.  Just doing a GIT for 
the latest version and running make.  But that was 11 months ago.  Hard to say 
if what I wrote up will make sense.

So I will try to get the IDE working with the discovery kit.  But truthfully, I 
like the PIC32 better.

John





___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill --> distance between pins

[Gene Heskett]

On Sunday 10 March 2019 15:45:06 John Dammeyer wrote:

> > -Original Message-
> > From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com]
> > On Sun, 10 Mar 2019 11:57:53 -0500
> >
> > Jon Elson  wrote:
> > > On 03/10/2019 05:18 AM, Nicklas Karlsson wrote:
> > > >> Hey Chris,
> > > >>
> > > >> AFAIK, the Pi has better HDMI support compared to the Beagle
> > > >> but then
> >
> > it was designed more for multimedia.  The Beagle PRUs have the
> > advantage that they have access to some of the Beagle Processor RAM.
> >  That gives them a bit of an advantage over the PI/32 bit hybrid
> > using SPI.
> >
> > > The PRUs are 200 MHz 32-bit RISC processors.  There are 3
> > > shared RAM data sections between the PRUs and the ARM.  The
> > > PRUs have a limited number of direct IO pads that bypass all
> > > the ARM high-level I/O fabric, and so can be read/written at
> > > the 5 ns rate of the PRU, which is a big plus for various
> > > special bit-fiddling I/O tasks.
> > >
> > > Charles Steinkuehler wrote a general driver for Machinekit
> > > that uses the PRU for step generation, PWM and encoder input.
> >
> > But why use a PRU then this kind of hardware is usually part of the
> > micro controller and very cheap?
>
> Jon,
> You make a very good point.  Why bother, with the new 32 bit
> controllers that do so much even bother with the antiquated idea that
> the LinuxCNC PC should close the loop on positioning.  Running
> encoders from a servo motor back into the PC to some sort of
> controller board that creates +/- 10V out is now not really a good
> option.
>
> Whether it's a PC with a plug in card running LinuxCNC or a BeagleBone
> Black running MachineKit there's not much point. Or is there?
>
> For a lathe, spindle tracking in order to move the carriage and if
> also tapering at the same time to track and move the cross slide does
> require something tightly coupled.
>
> So a Pi with an external STM32 may well send step/dir signals or SPI
> based messages to the driver but tracking that spindle encoder for
> threading is a bit more intensive.
>
Which is what I'm doing on the Sheldon, with an alu  bracket, curved to 
match the size of the bull gear on the spindle. Biggest problem was my 
math, getting the pair of ATS-667 hall effect sensors properly spaced to 
get a decent quadrature timed set of pulses out of it.  For index I 
reversed the third one, and I have a piece of a 8-32 screw gooped to the 
side of the gear so the end of the screw matches a tooth. Its only a 60 
tooth gear, but thats 240 edges per revolution, and works really well. I 
do not have a pid in the spindle control, its a vfd. In making that 
10-24 thread on the back end of a shorter stylus for the touch probe, I 
forgot to put a g4p1 in front of the g76 to give the spindle some accel 
time to get to 100 rpms, so when the g76 starts the first time, I hear 
the z accelerating with the spindle, but on thinking about it, the z is 
just following orders, which is as it should be. I didn't fix it.

Approaching the correct size, I wound up with a fit I smoothed somewhat 
with the locknut, and which fits the plastic spider a heck of a lot 
better that the shlopppy darned near stripped factory fit. But I picked 
up enough noise on an unshielded testing cable that my first test run 2 
days ago blew some of the 74HCT245's in the C1G rev 4, my fav BoB, and 
Arturo does not supply schematics, so its shotgun all 4 of those, which 
I have, but theres also 3 or 4 74HCT04's which I might have to order. I 
can see the probe working on the cards leds, but its not getting to the 
pc.

I have got to see about getting this 6040's framing all grounded together 
in spite of quite a few layers of epoxy paint on everything.  Its going 
to be fun stringing 1/4" braid thru all the cable chains just to get a 
ground on the spindle motor, picking up the rest of the gantry on the 
way by.  Then find and break all the ground loops that will no doubt 
cause. Fun? Not!

My point is that on a lathe, with spindle power to spare, for threading, 
all you need is for z to take orders, and that pretty straight forward, 
no real pid magic needed. All you need is a fine grained enough spindle 
encoder, and 1.5 degrees of resolution seems to be more than enough when 
you have a relatively high motion smoothing mass in the spindle and 
chuck.

On the G0704, with the spindle in low gear, I have 360/14250
(nominally)=0.0252631578947 degrees per edge, and I can run plumb 
ridiculous amounts of Pgain in that spindle PID. Speed control is STIFF.
Rigid tapping, up to the 17 amp current limit set in the servo amp, just 
works. And thats as close as I'll ever get to getting a 2200 lb 
Percheron sized horsepower out of that PMDC motor.

> John Dammeyer
> http://www.autoartisans.com
>
> > > Jon
> > >
> > >
> > > ___
> > > Emc-users mailing list
> > > Emc-users@lists.sourceforge.net
> > > 

Re: [Emc-users] STM32 Blue Pill

[Chris Albertson]

mpiler/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard\libc.a(lib_a-fstatr.o):
>  In function `_fstat_r':
> fstatr.c:(.text._fstat_r+0x10): undefined reference to `_fstat'
> c:/ac6/systemworkbench/plugins/fr.ac6.mcu.externaltools.arm-none.win32_1.17.0.201812190825/tools/compiler/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv4-sp/hard\libc.a(lib_a-isattyr.o):
>  In function `_isatty_r':
> isattyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty'
> collect2.exe: error: ld returned 1 exit status
> make: *** [Hello1.elf] Error 1
> makefile:34: recipe for target 'Hello1.elf' failed
>
> 15:49:11 Build Finished (took 2s.946ms)
>
> *
>
> OK.  So a PIC32MX512 will also work as a hardware platform.  Up till now I 
> still prefer MPLAB-8 but to be fair I've used the latest Microchip MPLABX.
> Create a project named HelloWorld.
> New C File that is HelowWorldMain.c
> IDE creates this for me and I added in the printf(Hello World\n");  BTW, I've 
> also chosen the ICD-3 in circuit debugger as my debug/program tool.
>
> /*
>  * File:   HelloWorldMain.c
>  * Author: john
>  *
>  * Created on March 10, 2019, 3:32 PM
>  */
>
> #include 
> #include 
>
> /*
>  *
>  */
> int main(int argc, char** argv) {
> printf("Hello World\n");
> return (EXIT_SUCCESS);
> }
>
> So far not that different right?
>
> Next click on Project and Build and here's the output.
>
> make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-conf
> make[1]: Entering directory 'C:/Users/john/MPLABXProjects/HelloWorld.X'
> make  -f nbproject/Makefile-default.mk 
> dist/default/production/HelloWorld.X.production.hex
> make[2]: Entering directory 'C:/Users/john/MPLABXProjects/HelloWorld.X'
> "C:\Microchip\MPLAB C32 Suite\bin\pic32-gcc.exe" -g -x c -c 
> -mprocessor=32MX795F512L -MMD -MF build/default/production/HelloWorldMain.o.d 
> -o build/default/production/HelloWorldMain.o HelloWorldMain.c
> "C:\Microchip\MPLAB C32 Suite\bin\pic32-gcc.exe"   -mprocessor=32MX795F512L  
> -o dist/default/production/HelloWorld.X.production.elf 
> build/default/production/HelloWorldMain.o   
> -Wl,--defsym=__MPLAB_BUILD=1,-Map="dist/default/production/HelloWorld.X.production.map"
> "C:\Microchip\MPLAB C32 Suite\bin"\\pic32-bin2hex 
> dist/default/production/HelloWorld.X.production.elf
> make[2]: Leaving directory 'C:/Users/john/MPLABXProjects/HelloWorld.X'
> make[1]: Leaving directory 'C:/Users/john/MPLABXProjects/HelloWorld.X'
>
> BUILD SUCCESSFUL (total time: 4s)
> Loading code from 
> C:/Users/john/MPLABXProjects/HelloWorld.X/dist/default/production/HelloWorld.X.production.hex...
> Loading completed
>
>
> No errors.
>
> Really no reason to continue with STM32 development when the PIC32 MPLABX is 
> that easy.
>
> John
>
> > -Original Message-
> > From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> > Sent: March-10-19 2:40 PM
> > To: Enhanced Machine Controller (EMC)
> > Subject: Re: [Emc-users] STM32 Blue Pill
> >
> > Yes the PRU is unique.   This is both good and bad.  Bad because using
> > it locks you to Texas Instruments "forever" Good because the PRU
> > bandwidth is very good because of the shared memory.
> >
> > As for debugging.  The STM32 has that, hardware breakpoint and all.
> >
> > The STM32 now has about 2/3 of the market which means that 33% of the
> > time some other solution worked better.
> >
> > One good thing about thePi/STM32hybris of the TI's integrated PRUs is
> > that if your requirements grow you are "stuck" if your software it
> > tried to the Beagle Board.   With Pi3/STM32 there is a LOT of room to
> > grow. The Pi3canbe replaced with a Xeon-based server class machine and
> > the STMline goes all the way to the M7. Also there as only two
> > PRUs, if your project needs more pins you are again"stuck" but you can
> > always add more STM32 and connect them all with I2C.
> >
> > I like the BBB.  I own two of them.  But only for a project that is
> > never going to get big.
> >
> > On Sat, Mar 9, 2019 at 1:52 PM John Dammeyer 
> > wrote:
> > >
> > > Hey Chris,
> > >
> > > AFAIK, the Pi has better HDMI support compared to the Beagle but then it
> > was designed more for multimedia.  The Beagle PRUs have the advantage
> > that they have access to some of the Beagle Processor RAM.  That gives
> > them a bit of an advantage over the PI/32 bit hybrid using S

Re: [Emc-users] STM32 Blue Pill --> boot loader

[Kirk Wallace]

Thank you for the tips. I was hoping to make a webpage documenting what 
I have tried so far in more detail. Maybe it will get done tonight. 
(Darn I can't hear myself type -- it's raining again.)


On 3/10/19 4:27 PM, Chris Albertson wrote:

On Sun, Mar 10, 2019 at 3:23 AM Nicklas Karlsson
 wrote:





Which boot loader? I got my ST-Link dongle to load a couple of
bootloader files but neither seemed to work.


Do you mean that the boot loader loaded but did not run, maybe have a
bug or that you could not load the bootloader?

There is a learning curve.  On the "blue pill" you must move the
shoring block on the boot pins to program the device and then move the
pins to boot the boot loader.   Itis easy to get this backward and the
shorting block are way to m=samll for by fingers.   During development
when you are re-programming this every 5 minutes make toggle switch
cable to speed things up.

If programming and booting don't work, likey the shorting blocks are
on the wrong pins.If you have a real Arduino there is a separate.
the second processor on the board to the boot stuff automatically.
but for $2.50 you have to move the shoring blocks with tweezers.

A better entry into STM32 programming is with an STM"Nucleo" board.
STM sells these for about $13 via US based resellers like Digikey or
Mouser.  So there is no need to deal with Chinese eBaers and wait a
month.

  The Nucleo board makes programming and booting trivially simple.
The board loks like the USB "thumb drive" to the OS so you can drag
and drop the binary file onto the processor.   This works the same on
Linux, Mac and Windows.The Nucleao has a built-in ST-Link dongle
with a special mode to make it look like a USB storage device.

Later, move to the bare chip "Blue Pill" if you like but I'd not start
there until gaining experience






--
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill --> boot loader

[Chris Albertson]

On Sun, Mar 10, 2019 at 3:23 AM Nicklas Karlsson
 wrote:
>

> > Which boot loader? I got my ST-Link dongle to load a couple of
> > bootloader files but neither seemed to work.

Do you mean that the boot loader loaded but did not run, maybe have a
bug or that you could not load the bootloader?

There is a learning curve.  On the "blue pill" you must move the
shoring block on the boot pins to program the device and then move the
pins to boot the boot loader.   Itis easy to get this backward and the
shorting block are way to m=samll for by fingers.   During development
when you are re-programming this every 5 minutes make toggle switch
cable to speed things up.

If programming and booting don't work, likey the shorting blocks are
on the wrong pins.If you have a real Arduino there is a separate.
the second processor on the board to the boot stuff automatically.
but for $2.50 you have to move the shoring blocks with tweezers.

A better entry into STM32 programming is with an STM"Nucleo" board.
STM sells these for about $13 via US based resellers like Digikey or
Mouser.  So there is no need to deal with Chinese eBaers and wait a
month.

 The Nucleo board makes programming and booting trivially simple.
The board loks like the USB "thumb drive" to the OS so you can drag
and drop the binary file onto the processor.   This works the same on
Linux, Mac and Windows.The Nucleao has a built-in ST-Link dongle
with a special mode to make it look like a USB storage device.

Later, move to the bare chip "Blue Pill" if you like but I'd not start
there until gaining experience



-- 

Chris Albertson
Redondo Beach, California


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[John Dammeyer]

tyr.c:(.text._isatty_r+0xc): undefined reference to `_isatty'
collect2.exe: error: ld returned 1 exit status
make: *** [Hello1.elf] Error 1
makefile:34: recipe for target 'Hello1.elf' failed

15:49:11 Build Finished (took 2s.946ms)

*

OK.  So a PIC32MX512 will also work as a hardware platform.  Up till now I 
still prefer MPLAB-8 but to be fair I've used the latest Microchip MPLABX.
Create a project named HelloWorld.
New C File that is HelowWorldMain.c
IDE creates this for me and I added in the printf(Hello World\n");  BTW, I've 
also chosen the ICD-3 in circuit debugger as my debug/program tool.

/* 
 * File:   HelloWorldMain.c
 * Author: john
 *
 * Created on March 10, 2019, 3:32 PM
 */

#include 
#include 

/*
 * 
 */
int main(int argc, char** argv) {
printf("Hello World\n");
return (EXIT_SUCCESS);
}

So far not that different right?

Next click on Project and Build and here's the output.

make -f nbproject/Makefile-default.mk SUBPROJECTS= .build-conf
make[1]: Entering directory 'C:/Users/john/MPLABXProjects/HelloWorld.X'
make  -f nbproject/Makefile-default.mk 
dist/default/production/HelloWorld.X.production.hex
make[2]: Entering directory 'C:/Users/john/MPLABXProjects/HelloWorld.X'
"C:\Microchip\MPLAB C32 Suite\bin\pic32-gcc.exe" -g -x c -c 
-mprocessor=32MX795F512L -MMD -MF build/default/production/HelloWorldMain.o.d 
-o build/default/production/HelloWorldMain.o HelloWorldMain.c 
"C:\Microchip\MPLAB C32 Suite\bin\pic32-gcc.exe"   -mprocessor=32MX795F512L  -o 
dist/default/production/HelloWorld.X.production.elf 
build/default/production/HelloWorldMain.o   
-Wl,--defsym=__MPLAB_BUILD=1,-Map="dist/default/production/HelloWorld.X.production.map"
"C:\Microchip\MPLAB C32 Suite\bin"\\pic32-bin2hex 
dist/default/production/HelloWorld.X.production.elf  
make[2]: Leaving directory 'C:/Users/john/MPLABXProjects/HelloWorld.X'
make[1]: Leaving directory 'C:/Users/john/MPLABXProjects/HelloWorld.X'

BUILD SUCCESSFUL (total time: 4s)
Loading code from 
C:/Users/john/MPLABXProjects/HelloWorld.X/dist/default/production/HelloWorld.X.production.hex...
Loading completed


No errors.  

Really no reason to continue with STM32 development when the PIC32 MPLABX is 
that easy.

John

> -Original Message-
> From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> Sent: March-10-19 2:40 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] STM32 Blue Pill
> 
> Yes the PRU is unique.   This is both good and bad.  Bad because using
> it locks you to Texas Instruments "forever" Good because the PRU
> bandwidth is very good because of the shared memory.
> 
> As for debugging.  The STM32 has that, hardware breakpoint and all.
> 
> The STM32 now has about 2/3 of the market which means that 33% of the
> time some other solution worked better.
> 
> One good thing about thePi/STM32hybris of the TI's integrated PRUs is
> that if your requirements grow you are "stuck" if your software it
> tried to the Beagle Board.   With Pi3/STM32 there is a LOT of room to
> grow. The Pi3canbe replaced with a Xeon-based server class machine and
> the STMline goes all the way to the M7. Also there as only two
> PRUs, if your project needs more pins you are again"stuck" but you can
> always add more STM32 and connect them all with I2C.
> 
> I like the BBB.  I own two of them.  But only for a project that is
> never going to get big.
> 
> On Sat, Mar 9, 2019 at 1:52 PM John Dammeyer 
> wrote:
> >
> > Hey Chris,
> >
> > AFAIK, the Pi has better HDMI support compared to the Beagle but then it
> was designed more for multimedia.  The Beagle PRUs have the advantage
> that they have access to some of the Beagle Processor RAM.  That gives
> them a bit of an advantage over the PI/32 bit hybrid using SPI.
> > >
> > > Somepeople are using BeagalBone Black boards because the BBB has
> those
> > > PRUs.   This is like the Pi/STM32 hybrid, logically identical.
> > >
> >
> > I did a project last year where I used a PIC32 as a Vehicle CAN bus monitor
> collecting CAN packets, timestamping and logging GPS information during
> the 20 seconds or so it took the Pi3 to boot.   Once the PI was alive, an app
> written initially in Python but then changed to C for speed, would gather
> and file the messages chronologically for later forwarding up to a cloud
> database. Someone else wrote that software.   Our connection between the
> two applications the files and pipes.
> >
> > In developing that project I chose the PIC32 over an STM32 because price
> of the processor wasn't a consideration but having an ICD-3 In Circuit
> Debugging tool was invaluable.  I used 

Re: [Emc-users] STM32 Blue Pill --> multicore isolation

[Chris Albertson]

This is also a good reason to use Ethernet (or Ethercat).   All
Ethernet cables are galvanically isolated by transformers.  I think
this is a little known fact, Ethernet uses magnetic isolation to
prevent ground loops.

This is kind of a big deal in a large system.   Some types of signals
just cannot go over long distances and the only way to use the types
of signals that can travel long-distance is to have some kind of
"intelligent" device at the far end.

On Sun, Mar 10, 2019 at 3:16 AM Nicklas Karlsson
 wrote:
>
> > > -Original Message-
> > > From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> >
> >
> > > The STM32 has no problem with MHz level bit flipping.   Reading or
> > > creating is MHz level is not hard.
> > > And the Pi3 has to be about the most well understood and documented
> > > machines on Earth.  they
> > > are ultra-common.
> > >
> > > The pi still is beat by an Intel desktop PC but the Pi has that GPIO
> > > header and you can get at signals.  The OS causes unpredictable
> > > latency so use the STM32 if that matters.
> > >
> > > As for compute power if the Pi is not enough you offload from the Pi
> > > to the bigger box.But for machine tools the Pi is overkill unless
> > > you are doing vision.
> > >
> > And the STM32s are so inexpensive that the STMBL AC Servo drive uses two of 
> > them.  One to handle the actual 3 phase drive output and one to deal with 
> > the encoders and user interface etc.  It's a nice solution where the 
> > computer side (LinuxCNC) is electrically isolated from the 350V Motor side.
>
> There are good reason to place Micro controller on rectified negative rail 
> while other signal need to be electrical isolated. This might be the reason 
> two micro controllers are used.
>
>
> Nicklas Karlsson
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



-- 

Chris Albertson
Redondo Beach, California


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Chris Albertson]

Yes the PRU is unique.   This is both good and bad.  Bad because using
it locks you to Texas Instruments "forever" Good because the PRU
bandwidth is very good because of the shared memory.

As for debugging.  The STM32 has that, hardware breakpoint and all.

The STM32 now has about 2/3 of the market which means that 33% of the
time some other solution worked better.

One good thing about thePi/STM32hybris of the TI's integrated PRUs is
that if your requirements grow you are "stuck" if your software it
tried to the Beagle Board.   With Pi3/STM32 there is a LOT of room to
grow. The Pi3canbe replaced with a Xeon-based server class machine and
the STMline goes all the way to the M7. Also there as only two
PRUs, if your project needs more pins you are again"stuck" but you can
always add more STM32 and connect them all with I2C.

I like the BBB.  I own two of them.  But only for a project that is
never going to get big.

On Sat, Mar 9, 2019 at 1:52 PM John Dammeyer  wrote:
>
> Hey Chris,
>
> AFAIK, the Pi has better HDMI support compared to the Beagle but then it was 
> designed more for multimedia.  The Beagle PRUs have the advantage that they 
> have access to some of the Beagle Processor RAM.  That gives them a bit of an 
> advantage over the PI/32 bit hybrid using SPI.
> >
> > Somepeople are using BeagalBone Black boards because the BBB has those
> > PRUs.   This is like the Pi/STM32 hybrid, logically identical.
> >
>
> I did a project last year where I used a PIC32 as a Vehicle CAN bus monitor 
> collecting CAN packets, timestamping and logging GPS information during the 
> 20 seconds or so it took the Pi3 to boot.   Once the PI was alive, an app 
> written initially in Python but then changed to C for speed, would gather and 
> file the messages chronologically for later forwarding up to a cloud 
> database. Someone else wrote that software.   Our connection between the two 
> applications the files and pipes.
>
> In developing that project I chose the PIC32 over an STM32 because price of 
> the processor wasn't a consideration but having an ICD-3 In Circuit Debugging 
> tool was invaluable.  I used the free PIC32 compiler and MPLAB IDE.  
> Development board that could hold MIKROE Click modules
> https://www.mikroe.com/click
> The CLICK boards made changing our minds really easy.
>
>
> What's available for the STM32 that is equivalent to the In Circuit Debuggers 
> from Microchip?
>
> John Dammeyer
> http://www.autoartisans.com
>
> >
> > Chris Albertson
> > Redondo Beach, California
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



-- 

Chris Albertson
Redondo Beach, California


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill --> distance between pins

[John Dammeyer]

I think we're actually all saying about the same thing.  A controller like a PC 
or a Pi3 needs some sort of external hardware that can deal with high speed 
quadrature encoders.  Whether it's done with a STM32 or FPGS doesn't really 
matter for the sake of discussion.   Meanwhile, as Jon reiterated, the BBB has 
the dual 200MHz PRUs that share memory and I/O and therefore can work with the 
Beagle main processor much more efficiently.  So although internal, it's still 
really a separate processor (sort of)...
John Dammeyer
http://www.autoartisans.com

> -Original Message-
> From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com]
> Sent: March-10-19 1:25 PM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] STM32 Blue Pill --> distance between pins
> 
> > > ...
> > Jon,
> > You make a very good point.  Why bother, with the new 32 bit controllers
> that do so much even bother with the antiquated idea that the LinuxCNC PC
> should close the loop on positioning.  Running encoders from a servo motor
> back into the PC to some sort of controller board that creates +/- 10V out is
> now not really a good option.
> 
> To locally close the control is the best option and the method I use. Values
> sent for position and encoder values are still the same but I do not have a
> PID.
> 
> If a +/- 10V signal is used with local feedback there will be nested control
> loops which may add problems but local speed control loop and linuxcnc
> position control loop might work well. Analog signals may have a high
> update rate.
> 
> 
> Nicklas Karlsson
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill --> distance between pins

[Nicklas Karlsson]

> > ...
> Jon,
> You make a very good point.  Why bother, with the new 32 bit controllers that 
> do so much even bother with the antiquated idea that the LinuxCNC PC should 
> close the loop on positioning.  Running encoders from a servo motor back into 
> the PC to some sort of controller board that creates +/- 10V out is now not 
> really a good option.

To locally close the control is the best option and the method I use. Values 
sent for position and encoder values are still the same but I do not have a PID.

If a +/- 10V signal is used with local feedback there will be nested control 
loops which may add problems but local speed control loop and linuxcnc position 
control loop might work well. Analog signals may have a high update rate.


Nicklas Karlsson


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill --> distance between pins

[Jon Elson]

On 03/10/2019 01:24 PM, Nicklas Karlsson wrote:

On Sun, 10 Mar 2019 11:57:53 -0500
Jon Elson  wrote:


Charles Steinkuehler wrote a general driver for Machinekit
that uses the PRU for step generation, PWM and encoder input.

But why use a PRU then this kind of hardware is usually part of the micro 
controller and very cheap?


The PRU's ARE part of the microprocessor!  They are built 
INTO the Sitara chip on the Beagle Bone.  Not some external 
box at additional cost.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill --> distance between pins

[John Dammeyer]

> -Original Message-
> From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com]
> On Sun, 10 Mar 2019 11:57:53 -0500
> Jon Elson  wrote:
> 
> > On 03/10/2019 05:18 AM, Nicklas Karlsson wrote:
> > >> Hey Chris,
> > >>
> > >> AFAIK, the Pi has better HDMI support compared to the Beagle but then
> it was designed more for multimedia.  The Beagle PRUs have the advantage
> that they have access to some of the Beagle Processor RAM.  That gives
> them a bit of an advantage over the PI/32 bit hybrid using SPI.
> > >>
> > The PRUs are 200 MHz 32-bit RISC processors.  There are 3
> > shared RAM data sections between the PRUs and the ARM.  The
> > PRUs have a limited number of direct IO pads that bypass all
> > the ARM high-level I/O fabric, and so can be read/written at
> > the 5 ns rate of the PRU, which is a big plus for various
> > special bit-fiddling I/O tasks.
> >
> > Charles Steinkuehler wrote a general driver for Machinekit
> > that uses the PRU for step generation, PWM and encoder input.
> 
> But why use a PRU then this kind of hardware is usually part of the micro
> controller and very cheap?
> 
Jon,
You make a very good point.  Why bother, with the new 32 bit controllers that 
do so much even bother with the antiquated idea that the LinuxCNC PC should 
close the loop on positioning.  Running encoders from a servo motor back into 
the PC to some sort of controller board that creates +/- 10V out is now not 
really a good option.  

Whether it's a PC with a plug in card running LinuxCNC or a BeagleBone Black 
running MachineKit there's not much point. 
Or is there?

For a lathe, spindle tracking in order to move the carriage and if also 
tapering at the same time to track and move the cross slide does require 
something tightly coupled.  

So a Pi with an external STM32 may well send step/dir signals or SPI based 
messages to the driver but tracking that spindle encoder for threading is a bit 
more intensive.

John Dammeyer
http://www.autoartisans.com

> > Jon
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
> 
> 
> --
> Nicklas Karlsson 
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill --> multicore isolation

[Nicklas Karlsson]

> > -Original Message-
> > From: Nicklas Karlsson [mailto:nicklas.karlsso...@gmail.com]
> > > > -Original Message-
> > > > From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> > >
> > >
> > > > The STM32 has no problem with MHz level bit flipping.   Reading or
> > > > creating is MHz level is not hard.
> > > > And the Pi3 has to be about the most well understood and documented
> > > > machines on Earth.  they
> > > > are ultra-common.
> > > >
> > > > The pi still is beat by an Intel desktop PC but the Pi has that GPIO
> > > > header and you can get at signals.  The OS causes unpredictable
> > > > latency so use the STM32 if that matters.
> > > >
> > > > As for compute power if the Pi is not enough you offload from the Pi
> > > > to the bigger box.But for machine tools the Pi is overkill unless
> > > > you are doing vision.
> > > >
> > > And the STM32s are so inexpensive that the STMBL AC Servo drive uses
> > two of them.  One to handle the actual 3 phase drive output and one to deal
> > with the encoders and user interface etc.  It's a nice solution where the
> > computer side (LinuxCNC) is electrically isolated from the 350V Motor side.
> > 
> > There are good reason to place Micro controller on rectified negative rail
> > while other signal need to be electrical isolated. This might be the reason
> > two micro controllers are used.
> 
> Other than frame ground an AC Servo using 350VDC derived directly from the AC 
> power line (w/o a transformer) must never have that 350VDC connected in any 
> way to the instrument DC logic (or even transformer isolated DC relay/stepper 
> motors).
> 
> So now you have the issue of an encoder that uses 5V.  Intelligent Serial 
> Control or Step/Dir or even quadrature position signals all at 5V logic 
> referenced to the instrument bus.  Either optically couple all that at the 
> input of the AC Servo controller (gets expensive in both parts and board 
> area), or just use two processors on two boards with a high speed control 
> signal between them that is optically and physically isolated.
> 
> Once again shows how clever the designers are.   Were it not for the 
> discontinued driver device there would be many more of them out there.  The 
> size of this unit given the power capabilities is very small compared to a 
> lot of other units out there.  My issue right now is finding an inexpensive 3 
> phase 2HP motor I can swap into my Mill Spindle.  Ie. I have the cart  but 
> not the horse...
> 
> John Dammeyer
> http://www.autoartisans.com

Now you mentioned the good reasons and I agree.


Nicklas Karlsson


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill --> distance between pins

[Nicklas Karlsson]

On Sun, 10 Mar 2019 11:57:53 -0500
Jon Elson  wrote:

> On 03/10/2019 05:18 AM, Nicklas Karlsson wrote:
> >> Hey Chris,
> >>
> >> AFAIK, the Pi has better HDMI support compared to the Beagle but then it 
> >> was designed more for multimedia.  The Beagle PRUs have the advantage that 
> >> they have access to some of the Beagle Processor RAM.  That gives them a 
> >> bit of an advantage over the PI/32 bit hybrid using SPI.
> >>
> The PRUs are 200 MHz 32-bit RISC processors.  There are 3 
> shared RAM data sections between the PRUs and the ARM.  The 
> PRUs have a limited number of direct IO pads that bypass all 
> the ARM high-level I/O fabric, and so can be read/written at 
> the 5 ns rate of the PRU, which is a big plus for various 
> special bit-fiddling I/O tasks.
> 
> Charles Steinkuehler wrote a general driver for Machinekit 
> that uses the PRU for step generation, PWM and encoder input.

But why use a PRU then this kind of hardware is usually part of the micro 
controller and very cheap?

> Jon
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


-- 
Nicklas Karlsson 


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill --> distance between pins

[John Dammeyer]

> -Original Message-
> From: Jon Elson [mailto:el...@pico-systems.com]
> Sent: March-10-19 9:58 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] STM32 Blue Pill --> distance between pins
> 
> On 03/10/2019 05:18 AM, Nicklas Karlsson wrote:
> >> Hey Chris,
> >>
> >> AFAIK, the Pi has better HDMI support compared to the Beagle but then it
> was designed more for multimedia.  The Beagle PRUs have the advantage
> that they have access to some of the Beagle Processor RAM.  That gives
> them a bit of an advantage over the PI/32 bit hybrid using SPI.
> >>
> The PRUs are 200 MHz 32-bit RISC processors.  There are 3
> shared RAM data sections between the PRUs and the ARM.  The
> PRUs have a limited number of direct IO pads that bypass all
> the ARM high-level I/O fabric, and so can be read/written at
> the 5 ns rate of the PRU, which is a big plus for various
> special bit-fiddling I/O tasks.
> 
> Charles Steinkuehler wrote a general driver for Machinekit
> that uses the PRU for step generation, PWM and encoder input.

I probably posted this already but if not here's the BeagleBone and MachinekIt 
running the knee stepper motor (Gecko) and Y axis DC Servo (HP_UHU).  Xylotex 
interface board.
https://youtu.be/9GF709ZfLRQ

It's not closed loop with an encoder through the Beagle.  The HP_UHU does that.

John Dammeyer
http://www.autoartisans.com

> 
> Jon
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill --> distance between pins

[Jon Elson]

On 03/10/2019 05:18 AM, Nicklas Karlsson wrote:

Hey Chris,

AFAIK, the Pi has better HDMI support compared to the Beagle but then it was 
designed more for multimedia.  The Beagle PRUs have the advantage that they 
have access to some of the Beagle Processor RAM.  That gives them a bit of an 
advantage over the PI/32 bit hybrid using SPI.

The PRUs are 200 MHz 32-bit RISC processors.  There are 3 
shared RAM data sections between the PRUs and the ARM.  The 
PRUs have a limited number of direct IO pads that bypass all 
the ARM high-level I/O fabric, and so can be read/written at 
the 5 ns rate of the PRU, which is a big plus for various 
special bit-fiddling I/O tasks.


Charles Steinkuehler wrote a general driver for Machinekit 
that uses the PRU for step generation, PWM and encoder input.


Jon


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill --> boot loader

[Nicklas Karlsson]

On Sat, 9 Mar 2019 14:48:28 -0800
Kirk Wallace  wrote:

> On 3/8/19 11:55 PM, Chris Albertson wrote:
> > The easy way to program a "Blue Pill" is with the Arduino IDE.
> ...
> > The way you program this is to just connect them to the USB port like an
> > Arduino.   But the key is
> > you need to first load a boot loader into the chip.
> ...
> 
> Which boot loader? I got my ST-Link dongle to load a couple of 
> bootloader files but neither seemed to work. (generic_boot20_pc13.bin, 
> maple_mini_boot20.bin)

You edited link file?

Boot loader should be put in block there execution start and application 
somewhere else in the memory. There is usually also a need to mover interrupt 
vectors to from Flash to RAM so that these are part of the application.

Boot loader use to screw up debugger which is really annoying.


Nicklas Karlsson


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill --> distance between pins

[Nicklas Karlsson]

> Hey Chris,
> 
> AFAIK, the Pi has better HDMI support compared to the Beagle but then it was 
> designed more for multimedia.  The Beagle PRUs have the advantage that they 
> have access to some of the Beagle Processor RAM.  That gives them a bit of an 
> advantage over the PI/32 bit hybrid using SPI.
> > 
> > Somepeople are using BeagalBone Black boards because the BBB has those
> > PRUs.   This is like the Pi/STM32 hybrid, logically identical.
> > 
> 
> I did a project last year where I used a PIC32 as a Vehicle CAN bus monitor 
> collecting CAN packets, timestamping and logging GPS information during the 
> 20 seconds or so it took the Pi3 to boot.   Once the PI was alive, an app 
> written initially in Python but then changed to C for speed, would gather and 
> file the messages chronologically for later forwarding up to a cloud 
> database. Someone else wrote that software.   Our connection between the two 
> applications the files and pipes.
> 
> In developing that project I chose the PIC32 over an STM32 because price of 
> the processor wasn't a consideration but having an ICD-3 In Circuit Debugging 
> tool was invaluable.  I used the free PIC32 compiler and MPLAB IDE.  
> Development board that could hold MIKROE Click modules
> https://www.mikroe.com/click
> The CLICK boards made changing our minds really easy.

I once wanted to choose PIC instead of STM32 because Micro controller had 
larger space between pins but think I was ignored.


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill --> multicore isolation

[Nicklas Karlsson]

> > -Original Message-
> > From: Chris Albertson [mailto:albertson.ch...@gmail.com]
> 
> 
> > The STM32 has no problem with MHz level bit flipping.   Reading or
> > creating is MHz level is not hard.
> > And the Pi3 has to be about the most well understood and documented
> > machines on Earth.  they
> > are ultra-common.
> > 
> > The pi still is beat by an Intel desktop PC but the Pi has that GPIO
> > header and you can get at signals.  The OS causes unpredictable
> > latency so use the STM32 if that matters.
> > 
> > As for compute power if the Pi is not enough you offload from the Pi
> > to the bigger box.But for machine tools the Pi is overkill unless
> > you are doing vision.
> > 
> And the STM32s are so inexpensive that the STMBL AC Servo drive uses two of 
> them.  One to handle the actual 3 phase drive output and one to deal with the 
> encoders and user interface etc.  It's a nice solution where the computer 
> side (LinuxCNC) is electrically isolated from the 350V Motor side.

There are good reason to place Micro controller on rectified negative rail 
while other signal need to be electrical isolated. This might be the reason two 
micro controllers are used.


Nicklas Karlsson


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Gene Heskett]

On Saturday 09 March 2019 16:49:34 Chris Albertson wrote:

> On Sat, Mar 9, 2019 at 12:39 PM Gene Heskett  
wrote:
> > Thats doing pretty good, but you're in the realm of on-offs no one
> > else can fix too. I find thats the major objection to the pi, no one
> > knows how it works but me.
>
> Sorry, but I completely missed this comment?
>
> "the realm of on-offs no one else can fix too" ???
>
Because if it screws up, you built it, so you are the only one who knows 
how to fix it.
>
>
> The STM32 has no problem with MHz level bit flipping.   Reading or
> creating is MHz level is not hard.
> And the Pi3 has to be about the most well understood and documented
> machines on Earth.  they
> are ultra-common.
>
> The pi still is beat by an Intel desktop PC but the Pi has that GPIO
> header and you can get at signals.  The OS causes unpredictable
> latency so use the STM32 if that matters.
>
> As for compute power if the Pi is not enough you offload from the Pi
> to the bigger box.But for machine tools the Pi is overkill unless
> you are doing vision.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Kirk Wallace]

On 3/8/19 11:55 PM, Chris Albertson wrote:

The easy way to program a "Blue Pill" is with the Arduino IDE.

...

The way you program this is to just connect them to the USB port like an
Arduino.   But the key is
you need to first load a boot loader into the chip.

...

Which boot loader? I got my ST-Link dongle to load a couple of 
bootloader files but neither seemed to work. (generic_boot20_pc13.bin, 
maple_mini_boot20.bin)


"...
Arduino: 1.8.5 (Linux), Board: "Generic STM32F103C series, STM32F103C8 
(20k RAM. 64k Flash), Serial, 72Mhz (Normal), Smallest (default)"


Sketch uses 12668 bytes (19%) of program storage space. Maximum is 65536 
bytes.
Global variables use 2456 bytes (11%) of dynamic memory, leaving 18024 
bytes for local variables. Maximum is 20480 bytes.

Failed to init device.
stm32flash Arduino_STM32_0.9

http://github.com/rogerclarkmelbourne/arduino_stm32

Using Parser : Raw BINARY
Interface serial_posix: 115200 8E1

An error occurred while uploading the sketch

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.
..."

It seems to be connected because this scrolls in the serial monitor:
"...
Congratulations, you have installed the STM32duino bootloader

See https://github.com/rogerclarkmelbourne/STM32duino-bootloader



For more information about Arduino on STM32

and http://www.stm32duino.com
..."

--
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[John Dammeyer]

> -Original Message-
> From: Chris Albertson [mailto:albertson.ch...@gmail.com]


> The STM32 has no problem with MHz level bit flipping.   Reading or
> creating is MHz level is not hard.
> And the Pi3 has to be about the most well understood and documented
> machines on Earth.  they
> are ultra-common.
> 
> The pi still is beat by an Intel desktop PC but the Pi has that GPIO
> header and you can get at signals.  The OS causes unpredictable
> latency so use the STM32 if that matters.
> 
> As for compute power if the Pi is not enough you offload from the Pi
> to the bigger box.But for machine tools the Pi is overkill unless
> you are doing vision.
> 
And the STM32s are so inexpensive that the STMBL AC Servo drive uses two of 
them.  One to handle the actual 3 phase drive output and one to deal with the 
encoders and user interface etc.  It's a nice solution where the computer side 
(LinuxCNC) is electrically isolated from the 350V Motor side.


John Dammeyer
http://www.autoartisans.com

> 
> 
> --
> 
> Chris Albertson
> Redondo Beach, California
> 
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[John Dammeyer]

Hey Chris,

AFAIK, the Pi has better HDMI support compared to the Beagle but then it was 
designed more for multimedia.  The Beagle PRUs have the advantage that they 
have access to some of the Beagle Processor RAM.  That gives them a bit of an 
advantage over the PI/32 bit hybrid using SPI.
> 
> Somepeople are using BeagalBone Black boards because the BBB has those
> PRUs.   This is like the Pi/STM32 hybrid, logically identical.
> 

I did a project last year where I used a PIC32 as a Vehicle CAN bus monitor 
collecting CAN packets, timestamping and logging GPS information during the 20 
seconds or so it took the Pi3 to boot.   Once the PI was alive, an app written 
initially in Python but then changed to C for speed, would gather and file the 
messages chronologically for later forwarding up to a cloud database. Someone 
else wrote that software.   Our connection between the two applications the 
files and pipes.

In developing that project I chose the PIC32 over an STM32 because price of the 
processor wasn't a consideration but having an ICD-3 In Circuit Debugging tool 
was invaluable.  I used the free PIC32 compiler and MPLAB IDE.  Development 
board that could hold MIKROE Click modules
https://www.mikroe.com/click
The CLICK boards made changing our minds really easy.


What's available for the STM32 that is equivalent to the In Circuit Debuggers 
from Microchip?  

John Dammeyer
http://www.autoartisans.com

> 
> Chris Albertson
> Redondo Beach, California
> 
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Chris Albertson]

On Sat, Mar 9, 2019 at 12:39 PM Gene Heskett  wrote:
>

> Thats doing pretty good, but you're in the realm of on-offs no one else
> can fix too. I find thats the major objection to the pi, no one knows
> how it works but me.
>


Sorry, but I completely missed this comment?

"the realm of on-offs no one else can fix too" ???



The STM32 has no problem with MHz level bit flipping.   Reading or
creating is MHz level is not hard.
And the Pi3 has to be about the most well understood and documented
machines on Earth.  they
are ultra-common.

The pi still is beat by an Intel desktop PC but the Pi has that GPIO
header and you can get at signals.  The OS causes unpredictable
latency so use the STM32 if that matters.

As for compute power if the Pi is not enough you offload from the Pi
to the bigger box.But for machine tools the Pi is overkill unless
you are doing vision.



-- 

Chris Albertson
Redondo Beach, California


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Gene Heskett]

On Saturday 09 March 2019 14:12:43 Chris Albertson wrote:

>   Gene,
>
> Yes, the Pi has slow I/O but this thread is about the "Blue Pill"
> board that costs $2.60 with free shipping.
>
> SO what I do is build a hybrid.   The cheap little STM32F103 has many
> I/O pins that are robust and even 5 volt tolerent.   I use the STM32
> to connet to the world and then SPI to telk betwween the Pi and the
> STM32
>
>
> Allof the I/O on the Pi is not slow.The current version o the pi,
> to Pi3B+ can do networking at 300 megabits persecond.This is
> faster then any 100BaseT device but not the 1000BaseT we would like.  
> None the less fast enough
>
> But the Pi's SPI and I2C pins on the GPIO head go DIRECT to the CPU
> chip, In fact all the lines in the 40 pin header to straight to the
> chip.
>
> Back to the hybrid system.   This is thebest model and is very much
> like the old PC drinving a Measa FPGA card.   A the can replace the
> old PC and an STM32 ( can replace the Mesa.
>
> Somepeople are using BeagalBone Black boards because the BBB has those
> PRUs.   This is like the Pi/STM32 hybrid, logically identical.
>
> Dn't complain about the Pi3B+.  If you are still using a 100BaseT
> network switch, that switch will be the bottleneck,not the Pi.
>
>
> My hybrid right not is runing real-time control at microsecond
> resolution over WiFi, I have the "blue pill" device phyically near the
> motors then a short cable to a Pi3 then WiFi to my Macbook. Motors are
> DC with 64 pulse encoders running up to about 10,000 RPM into a 100:1
> reduction gearbox. So we see roughtly about 10,000 encoder edges per
> second times two motors in the worst case of "full speed".The PID
> loops work fine even using low-end STM32 chips
>
Thats doing pretty good, but you're in the realm of on-offs no one else 
can fix too. I find thats the major objection to the pi, no one knows 
how it works but me.

> On Sat, Mar 9, 2019 at 5:33 AM Gene Heskett  
wrote:
> > On Saturday 09 March 2019 07:53:05 Nicklas Karlsson wrote:
> > > > On Sat, 9 Mar 2019 at 11:59, Nicklas Karlsson
> > > >
> > > >  wrote:
> > > > > I think CPU Cortex-M4 is a lot slower than arduino
> > > >
> > > > Really? That isn't my experience. Given that the M4 is running
> > > > at 120MHz and the Arduino is 8MHz and both are running the same
> > > > code?
> > >
> > > No I got it wrong and mixed it with raspberry, I think.
> >
> > The pi's huge, glaring slow i/o problem is that internal usb-2 hub.
> > AIUI, only the wifi and gpio bypass that huge bottleneck.
> >
> > > ___
> > > Emc-users mailing list
> > > Emc-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-users
> >
> > Cheers, Gene Heskett
> > --
> > "There are four boxes to be used in defense of liberty:
> >  soap, ballot, jury, and ammo. Please use in that order."
> > -Ed Howdershelt (Author)
> > Genes Web page 
> >
> >
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Nicklas Karlsson]

> ... The PID loops work fine even
> using low-end STM32 chips

Yes these chips are really good.


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Chris Albertson]

  Gene,

Yes, the Pi has slow I/O but this thread is about the "Blue Pill" board
that costs $2.60 with free shipping.

SO what I do is build a hybrid.   The cheap little STM32F103 has many I/O
pins that are robust and even 5 volt tolerent.   I use the STM32 to connet
to the world and then SPI to telk betwween the Pi and the STM32


Allof the I/O on the Pi is not slow.The current version o the pi, to
Pi3B+ can do networking at 300 megabits persecond.This is faster then
any 100BaseT device but not the 1000BaseT we would like.   None the less
fast enough

But the Pi's SPI and I2C pins on the GPIO head go DIRECT to the CPU chip,
 In fact all the lines in the 40 pin header to straight to the chip.

Back to the hybrid system.   This is thebest model and is very much like
the old PC drinving a Measa FPGA card.   A the can replace the old PC and
an STM32 ( can replace the Mesa.

Somepeople are using BeagalBone Black boards because the BBB has those
PRUs.   This is like the Pi/STM32 hybrid, logically identical.

Dn't complain about the Pi3B+.  If you are still using a 100BaseT network
switch, that switch will be the bottleneck,not the Pi.


My hybrid right not is runing real-time control at microsecond resolution
over WiFi, I have the "blue pill" device phyically near the motors then a
short cable to a Pi3 then WiFi to my Macbook. Motors are DC with 64 pulse
encoders running up to about 10,000 RPM into a 100:1 reduction gearbox.
 So we see roughtly about 10,000 encoder edges per second times two
motors in the worst case of "full speed".The PID loops work fine even
using low-end STM32 chips





On Sat, Mar 9, 2019 at 5:33 AM Gene Heskett  wrote:

> On Saturday 09 March 2019 07:53:05 Nicklas Karlsson wrote:
>
> > > On Sat, 9 Mar 2019 at 11:59, Nicklas Karlsson
> > >
> > >  wrote:
> > > > I think CPU Cortex-M4 is a lot slower than arduino
> > >
> > > Really? That isn't my experience. Given that the M4 is running at
> > > 120MHz and the Arduino is 8MHz and both are running the same code?
> >
> > No I got it wrong and mixed it with raspberry, I think.
> >
> The pi's huge, glaring slow i/o problem is that internal usb-2 hub. AIUI,
> only the wifi and gpio bypass that huge bottleneck.
> >
> > ___
> > Emc-users mailing list
> > Emc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 
>
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Chris Albertson]

THat is the neat thing about the STM32 range.   There is the take $2 chip
on the "bluepill" and also the M4 chips with 5X faster clocks and FPUs

Here is a nice chart showing STM32 products sorted be speed, power and
size.  None of these cost much mover $20.The larger ones are Arduino
Ono pin compatable so off the shelf shields fit.

The price is right and there are so many of these on the market.But
that $2.50 STM32F103 board  most things.   I buy them 10 at a time.

On Sat, Mar 9, 2019 at 3:37 AM andy pugh  wrote:

> On Sat, 9 Mar 2019 at 05:48, Kirk Wallace 
> wrote:
> >
> > I have used AVR chips to add features to LinuxCNC that where not easy to
> > do with a parallel port alone. Now I would like to take a try at using
> > one of these Blue Pills:
> > > https://www.ebay.com/itm/222676944274
>
> When I found that an actual Arduino wasn't capable enough for a recent
> project I used one of these instead.
>
> https://www.adafruit.com/product/3800
>
> Lots more RAM, a relatively fast CPU and decent floating-point means
> that it can run serial kinematics (which is what I wanted)
>
>
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1916
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Gene Heskett]

On Saturday 09 March 2019 08:50:19 grumpy--- via Emc-users wrote:

> On Sat, 9 Mar 2019, Gene Heskett wrote:
> > On Saturday 09 March 2019 07:53:05 Nicklas Karlsson wrote:
> >>> On Sat, 9 Mar 2019 at 11:59, Nicklas Karlsson
> >>>
> >>>  wrote:
>  I think CPU Cortex-M4 is a lot slower than arduino
> >>>
> >>> Really? That isn't my experience. Given that the M4 is running at
> >>> 120MHz and the Arduino is 8MHz and both are running the same code?
> >>
> >> No I got it wrong and mixed it with raspberry, I think.
> >
> > The pi's huge, glaring slow i/o problem is that internal usb-2 hub.
> > AIUI, only the wifi and gpio bypass that huge bottleneck.
>
> maybe this would help
> https://geekworm.com/collections/raspberry-pi-hats/products/x820-v3-0-
>usb-3-0-2-5-inch-sata-hdd-ssd-storage-expansion-board
>
Looked this over but I don't see it solving the biggest problem of the 
pi, the fact that the video data has to get to the hdmi circuitry thru 
the internal usb2 hub. That precludes doing a full screen video update 
rate of more that about 6 or 7 frames a second.  And if the pi gets 
busy, way less than a frame a second, which was the condition when I 
made the mistake in calculating K for a g76 operation. The result was 
that any movement (jog) button took over a second to get from the 
keyboard to start moving the machine, it moved at the commanded speed 
for a minimum of a second, and it was 3 cycles of screen updates at 
about 1.5 seconds each before the screen was fully updated.  The 
onscreen backplot was showing a deeper than normal depth of cut which 
was my clue to recheck my math. The math error was caused by the 
document section describing G76 NOT saying that K is a factor from P, so 
it took k=.466 as inches, not k=[p/0.866].

And because the 3 cornered thread cutting chips are so gawdawfull 
expen$ive, and fragile I tend to fix the g76 anchor point off the end of 
the thread, and define #<_Ze> as [p * -number of threads] as I can add 
one thread at a time while cutting air until the end of the last thread 
just clears the ER-42 collet. That way I can also adjust my off the end 
of the work z starting point in p increments without screwing up a 
partially cut thread. The one thing I wish I could do is teach G76 to 
cut so as to compensate for the works flexing as I get threads a couple 
thou bigger on the end vs at the chuck. I need, for small work, another 
variable to make it cut the teeniest of tapers, a thou, maybe 2 small at 
the start.  Extreme amounts of H do not fix that for small bolts of 
under 1/4"/6mm.

I should make a tool holder die carrier, but then you're stuck with the 
die makers fit unless you buy split adjustable dies. And must use a 
g33.1, which has its own problems when the spindle is doing lots of 
overtravel, so much I wrote some hal code and some pyvcp.xml to display 
it.  Its helped me to not break so many taps from hitting the bottom of 
the holes. If I use the data it shows me, I can rigid tap at 250 revs 
wearing a 40 lb chuck that makes the belts yelp during the end of stroke 
reversal.  Belts need replaced, I have some powerstroke stuff but can't 
figure out how to assemble them in the room allowed by the adjustments. 
So the spindle or the lower pulleys have to be removed, the belt 
assembled, and the shaft re-inserted.

A long tedious job since the lower dual sheeve that used to have a 
woodruff key now has a shop made (on TLM) taperlock hub. It was 
installed wrong side to by someone in the past, and their attempt to 
tighten the setscrews without the locking key tore up the sheeves bore 
and scored the shaft, so my best fix was to make a taperlock hub for it 
and pull the bronze bushings putting in the torrington needle cages 
called for in the parts list. It turned out that the majority of the 
400F heat I was measureing with an IR thermometer was the friction of 
the setscrews slipping on the shaft.

Moving the drive screws to Jack that apart and remove the upper shaft is 
a major pita, no room to swing the allen wrench w/o driving the 
shaft/pulley 20 degrees back and forth at the same time. I should have 
replaced the belts then but didn't have them. Now I do, but dread the 
job. And I'd need to grow at least one more arm since there's not room 
for 2 people under there. Did I mention it will be a PIMyBack?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[grumpy--- via Emc-users]

On Sat, 9 Mar 2019, Gene Heskett wrote:


On Saturday 09 March 2019 07:53:05 Nicklas Karlsson wrote:


On Sat, 9 Mar 2019 at 11:59, Nicklas Karlsson

 wrote:

I think CPU Cortex-M4 is a lot slower than arduino


Really? That isn't my experience. Given that the M4 is running at
120MHz and the Arduino is 8MHz and both are running the same code?


No I got it wrong and mixed it with raspberry, I think.


The pi's huge, glaring slow i/o problem is that internal usb-2 hub. AIUI,
only the wifi and gpio bypass that huge bottleneck.




maybe this would help
https://geekworm.com/collections/raspberry-pi-hats/products/x820-v3-0-usb-3-0-2-5-inch-sata-hdd-ssd-storage-expansion-board


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Gene Heskett]

On Saturday 09 March 2019 07:53:05 Nicklas Karlsson wrote:

> > On Sat, 9 Mar 2019 at 11:59, Nicklas Karlsson
> >
> >  wrote:
> > > I think CPU Cortex-M4 is a lot slower than arduino
> >
> > Really? That isn't my experience. Given that the M4 is running at
> > 120MHz and the Arduino is 8MHz and both are running the same code?
>
> No I got it wrong and mixed it with raspberry, I think.
>
The pi's huge, glaring slow i/o problem is that internal usb-2 hub. AIUI, 
only the wifi and gpio bypass that huge bottleneck.
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 



___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[andy pugh]

On Sat, 9 Mar 2019 at 12:55, Nicklas Karlsson
 wrote:

> > Really? That isn't my experience. Given that the M4 is running at
> > 120MHz and the Arduino is 8MHz and both are running the same code?
>
> No I got it wrong and mixed it with raspberry, I think.

Ah, right. I agree that it might be a but anaeimic running Linux, but
running "bare metal" like an Arduino it is pretty capable.

One interesting possibility is that, with a 120Mhz clock, it should be
able to talk Mesa Smart Serial, and that would open up some
interesting ideas.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Nicklas Karlsson]

> On Sat, 9 Mar 2019 at 11:59, Nicklas Karlsson
>  wrote:
> 
> > I think CPU Cortex-M4 is a lot slower than arduino
> 
> Really? That isn't my experience. Given that the M4 is running at
> 120MHz and the Arduino is 8MHz and both are running the same code?

No I got it wrong and mixed it with raspberry, I think.


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[andy pugh]

On Sat, 9 Mar 2019 at 11:59, Nicklas Karlsson
 wrote:

> I think CPU Cortex-M4 is a lot slower than arduino

Really? That isn't my experience. Given that the M4 is running at
120MHz and the Arduino is 8MHz and both are running the same code?

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Nicklas Karlsson]

> On Sat, 9 Mar 2019 at 05:48, Kirk Wallace  wrote:
> >
> > I have used AVR chips to add features to LinuxCNC that where not easy to
> > do with a parallel port alone. Now I would like to take a try at using
> > one of these Blue Pills:
> > > https://www.ebay.com/itm/222676944274
> 
> When I found that an actual Arduino wasn't capable enough for a recent
> project I used one of these instead.
> 
> https://www.adafruit.com/product/3800
> 
> Lots more RAM, a relatively fast CPU and decent floating-point means
> that it can run serial kinematics (which is what I wanted)

I think CPU Cortex-M4 is a lot slower than arduino but without operating system 
they do nothing else than running application. These kind of micro controllers 
is what I am used with, they usually have the required hardware for control of 
a servo or ordinary electric motor or other periodic real time tasks.


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[andy pugh]

On Sat, 9 Mar 2019 at 05:48, Kirk Wallace  wrote:
>
> I have used AVR chips to add features to LinuxCNC that where not easy to
> do with a parallel port alone. Now I would like to take a try at using
> one of these Blue Pills:
> > https://www.ebay.com/itm/222676944274

When I found that an actual Arduino wasn't capable enough for a recent
project I used one of these instead.

https://www.adafruit.com/product/3800

Lots more RAM, a relatively fast CPU and decent floating-point means
that it can run serial kinematics (which is what I wanted)



--
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1916


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Chris Albertson]

The easy way to program a "Blue Pill" is with the Arduino IDE.  Arduino is
VERY well documented but
for more complex work mBed is just as well documented is not so limiting as
Arduino.

The little $3 board can completely replace an Arduino.  Most pins are 5
volt So it plays
well with ether 5V or 3.3v parts.   Except for the names of the pins the
"blue pill"
can run Arduino code.  But it is about 20x faster with about 20x more
memory at 1/4 the price.

The way you program this is to just connect them to the USB port like an
Arduino.   But the key is
you need to first load a boot loader into the chip.

A step up from using the Arduino IDE is to use ARM's "mbed".  This is a
system for programming the full range
of STM32 chips and is pretty easy.  It includes an RTOS that makes like
easy. and gives you multitasking,
queues and drivers and Arduino-like ease of use.

There are two ways to program in the mbed environment.  (1) use the online
compiler.  This is simple because there is nothing to install on the local
PC. and the environment is very Arduino-like with one-click access to
example code and documentation. and the second way is to compile on the
local PC.  You can use a command line to do that or set up Eclipse.

mBed devices are easy to program.  When you plug them into a USB port they
appear to be a thumb drive.  You simply drag the binary executable file to
the device and it gets copied into the chip's flash ROM.   This works the
same way in Windows, Mac or Linux.

mbed is open source and is backed by Arm Holdings, the owner of the ARM
architecture.  It is their OS for STM32.

There are other MUCH more powerfull STM32 boards that are all source code
compatible.  I have one that is 200 MHz with hardware floating point.
 The chips (even the low-end "blue pill" can generate pulses in hardware
with no CPU overhead and they can read quadrature also in hardware.  The $3
chip can track an A/B encoder at about 5 MHz.with no CPU usage.

I have one running now on my desk that is bussy running some sonars and an
array of switches and turning the data into a serial stream.

I have another that is a PID loop to control a pair of motors. It presents
a serial command interface to the next level up controller.

These are so cheap and easy to use that I use them just to save wire.  Run
all the switch leads into a "blue pill" then just have I2C or SPI


For simple stuff look at using Aruduino IDE with these for more
sophiticated work look at using mBed.
https://www.mbed.com/en/platform/mbed-os/

I would NOT bother trying to program these  from "bare metal".  You will
spend all yurtime readinf the STM32F103 documents.Thenif ever
tou chagechips yu need to re-read the book.   the mbed os (and arduino)
 interpose alaer that standardizes the hardware across the entire STM32
line.

HINT:   While the "blue pill" is cheap and more than you need for many
uses, for only about $13 tyu can buy a "STM32F446 Nucleo" which is an order
of magnitude more capable and importently the Nucleor comes with a
programmer/hardware debugger that can beuse with Blue Pill type boards.
This programmer presents the "drang and drop" programming interface.

Yes this is applicable to machine tools.  put o on a moter and now you have
amoter that accepts serial commands


On Fri, Mar 8, 2019 at 9:48 PM Kirk Wallace 
wrote:

> I have used AVR chips to add features to LinuxCNC that where not easy to
> do with a parallel port alone. Now I would like to take a try at using
> one of these Blue Pills:
> > https://www.ebay.com/itm/222676944274
>
> So far I have used this link:
> >
> https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Programming-an-STM32F103XXX-with-a-generic-%22ST-Link-V2%22-programmer-from-Linux
>
> to get OpenOCD installed, configured and running. I am able to telnet to
> port  and play with some of the commands. Next, it seems that I need
> to come up with a way to develop and compile C files to flash to the
> STM32, but a lot of the STM32 information on the Web is old or conflicts
> with different methods from various sources. If someone here has a
> simple development system, I would appreciate any links or hints.
>
> Thank you.
>
> --
> Kirk Wallace
> http://www.wallacecompany.com/machine_shop/
> http://www.wallacecompany.com/E45/
>
>
> ___
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>


-- 

Chris Albertson
Redondo Beach, California

___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] STM32 Blue Pill

[Kirk Wallace]

I wish I had found this earlier:

https://www.youtube.com/watch?v=K-jYSysmw9w


This seems to be the shortest path to getting a blink program working. 
The steps in this video seem to work so far. I just need to dig up a USB 
to serial adapter from my breadboarding stash rather than use the 
ST-Link adapter.


On 3/8/19 9:46 PM, Kirk Wallace wrote:
I have used AVR chips to add features to LinuxCNC that where not easy to 
do with a parallel port alone. Now I would like to take a try at using 
one of these Blue Pills:

https://www.ebay.com/itm/222676944274


So far I have used this link:
https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Programming-an-STM32F103XXX-with-a-generic-%22ST-Link-V2%22-programmer-from-Linux 



to get OpenOCD installed, configured and running. I am able to telnet to 
port  and play with some of the commands. Next, it seems that I need 
to come up with a way to develop and compile C files to flash to the 
STM32, but a lot of the STM32 information on the Web is old or conflicts 
with different methods from various sources. If someone here has a 
simple development system, I would appreciate any links or hints.


Thank you.




--
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

[Emc-users] STM32 Blue Pill

[Kirk Wallace]

I have used AVR chips to add features to LinuxCNC that where not easy to 
do with a parallel port alone. Now I would like to take a try at using 
one of these Blue Pills:

https://www.ebay.com/itm/222676944274


So far I have used this link:

https://github.com/rogerclarkmelbourne/Arduino_STM32/wiki/Programming-an-STM32F103XXX-with-a-generic-%22ST-Link-V2%22-programmer-from-Linux


to get OpenOCD installed, configured and running. I am able to telnet to 
port  and play with some of the commands. Next, it seems that I need 
to come up with a way to develop and compile C files to flash to the 
STM32, but a lot of the STM32 information on the Web is old or conflicts 
with different methods from various sources. If someone here has a 
simple development system, I would appreciate any links or hints.


Thank you.

--
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/


___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users