I'll do some more testing with Prop_Hex and Prop_Ascii to see if I can figure out why it's not reliable for me. I suspect there may have been other issues when I was developing the code, and I stopped looking at it once I got something that worked using the secondary loader. I believe at some point I was able to load a large binary using Prop_Hex.
Maybe it is also timing/delays ? I'd usually expect 115200 to be far enough clear of 2MBd to make that a non issue, but one never knows....
eg 2 Stop bits may help at elevated baud rates( > 1M?) , as one bottleneck I recall is from AutoBAUD (hardware) + Calcs re-calibrating the SmartPin quick enough to be ready for the next char Start bit edge.
There could be other timing issues around reset-release to first Char.
Q: Do your FPGAs also load at 1.714Mbd, 1.5Mbd, 1.333MBd ?
Yes on DE2-115,P123-A9. Didn't try others.
What delays are used, and what loader code do you use ?
One way to check if this uses 20M or 80M in FPGA, would be to push higher than 2MBd,
If you have FT232H/FT2232H, they can do most of these
(2000000,2181818.182,2400000,2666666.667,3000000,3428571.429,4000000 & 6M & 12M)
I've gotten loadp2 to run under Cygwin and Linux. The loading part seems to work OK, but the terminal emulator is a bit flaky under Cygwin. Sometimes it works, and sometimes it doesn't. I've no idea what's causing the flakiness. Under Linux, I had to add a call to the select function in the serial rx routine. Without the call to select the rx routine will hang waiting for data from the serial port.
I've gotten loadp2 to run under Cygwin and Linux. The loading part seems to work OK, but the terminal emulator is a bit flaky under Cygwin. Sometimes it works, and sometimes it doesn't. I've no idea what's causing the flakiness. Under Linux, I had to add a call to the select function in the serial rx routine. Without the call to select the rx routine will hang waiting for data from the serial port.
Did you look at the serial code in my p2load program? I'm pretty sure the terminal mode works on both Windows and Linux although I use MinGW instead of Cygwin under Windows.
I downloaded p2load from GitHub, and disabled the loading code so I could just run the terminal. It wasn't displaying all of the text coming from the board. The console I/O did seem to work OK. loadp2 uses the serial I/O functions contained in osint_linux.c and osint_cygwin.c. I'll have to try the stubbed out p2load under Linux to see how well that works.
I downloaded p2load from GitHub, and disabled the loading code so I could just run the terminal. It wasn't displaying all of the text coming from the board. The console I/O did seem to work OK. loadp2 uses the serial I/O functions contained in osint_linux.c and osint_cygwin.c. I'll have to try the stubbed out p2load under Linux to see how well that works.
Interesting. I admit that I hardly ever use Windows. Mostly, I just use it for testing and I've verified that console I/O seems to work with p2load. I didn't do much more testing than that as I recall. Are you saying that if the Propeller is blasting stuff out the serial port that some of it is missing on the PC side? I'm not sure I understand what you mean by the console working but not text coming from the board.
I downloaded p2load from GitHub, and disabled the loading code so I could just run the terminal. It wasn't displaying all of the text coming from the board. The console I/O did seem to work OK. loadp2 uses the serial I/O functions contained in osint_linux.c and osint_cygwin.c. I'll have to try the stubbed out p2load under Linux to see how well that works.
Interesting. I admit that I hardly ever use Windows. Mostly, I just use it for testing and I've verified that console I/O seems to work with p2load. I didn't do much more testing than that as I recall. Are you saying that if the Propeller is blasting stuff out the serial port that some of it is missing on the PC side? I'm not sure I understand what you mean by the console working but not text coming from the board.
Oh and I'm not really using osint_cygwin.c in any of my code so maybe that has problems. As I mentioned before, I've been using MinGW. I think jazzed decided a while back when he was managing the PropGCC project that we needed to use MinGW instead of Cygwin for licensing reasons.
When I run the chess program it prints out the board in a burst at the full serial rate. That's about 20 lines with about 30 characters per line. It's not a lot of data, but I only see a couple of lines with the stubbed out p2load. I'll run some more tests tomorrow to see if I can get a better handle on it.
When I run the chess program it prints out the board in a burst at the full serial rate. That's about 20 lines with about 30 characters per line. It's not a lot of data, but I only see a couple of lines with the stubbed out p2load. I'll run some more tests tomorrow to see if I can get a better handle on it.
Can you build the Windows version with MinGW or are you tied to Cygwin?
Well I use Cygwin on all my Windows machines, and I don't have MinGW installed on any of them. So in that sense I'm tied to Cygwin for development. I know that the PropGCC distributions for Windows are done with MinGW, and it might be a good idea to put MinGW on one of my machines to test with that. I know that the terminal emulator in propeller-load works fine on Windows, so I'm thinking of building a stubbed out version of propeller-load to see if that works. Maybe the Cygwin version has never been tested very thoroughly.
One way to check if this uses 20M or 80M in FPGA, would be to push higher than 2MBd,
If you have FT232H/FT2232H, they can do most of these
(2000000,2181818.182,2400000,2666666.667,3000000,3428571.429,4000000 & 6M & 12M)
The FPGA's reset to 20Mhz and the code loaded must have a "CLKSET #$FF" instruction to switch to 80MHz after loading.
Well I use Cygwin on all my Windows machines, and I don't have MinGW installed on any of them. So in that sense I'm tied to Cygwin for development. I know that the PropGCC distributions for Windows are done with MinGW, and it might be a good idea to put MinGW on one of my machines to test with that. I know that the terminal emulator in propeller-load works fine on Windows, so I'm thinking of building a stubbed out version of propeller-load to see if that works. Maybe the Cygwin version has never been tested very thoroughly.
I'm pretty sure that propeller-load uses the same Cygwin serial code as p2load.
I installed MinGW and gave it a try. I ran into a few issues, but I was able get it working. MinGW doesn't support the usleep function, which I was using. However, I found that osint_mingw.c contained an msleep function that I could used. I also was able to used the terminal emulator in osint_mingw.c instead of using my own. The final problem had to do with the way I was opening the binary file that was to be loaded. I was using the "r" mode in fopen. However, because MinGW just provides a wrapper for the Window I/O it was treating it like a text file. Windows does "lovely" things to a binary file when reading it as a text file. I just needed to use "rb" instead of "r". I guess for portability it's a good idea to always include the "b" in the mode string.
So loadp2 works fine with MinGW. I'll clean up the code a bit and post the new source code.
I installed MinGW and gave it a try. I ran into a few issues, but I was able get it working. MinGW doesn't support the usleep function, which I was using. However, I found that osint_mingw.c contained an msleep function that I could used. I also was able to used the terminal emulator in osint_mingw.c instead of using my own. The final problem had to do with the way I was opening the binary file that was to be loaded. I was using the "r" mode in fopen. However, because MinGW just provides a wrapper for the Window I/O it was treating it like a text file. Windows does "lovely" things to a binary file when reading it as a text file. I just needed to use "rb" instead of "r". I guess for portability it's a good idea to always include the "b" in the mode string.
So loadp2 works fine with MinGW. I'll clean up the code a bit and post the new source code.
Congratulations! One of these days I'll try to figure out why osint_cygwin.c doesn't work. I have Cygwin installed on my new Surface Pro 4 so it shouldn't be too hard to try it.
I got loadp2 running reliably under Linux, Cygwin and MinGW. The MinGW executable will also run in a normal Windows command window, so I included it in the zip file. I eliminated the conion.* files and integrated the conion functions into osint_cygwin.c. The original console functions in osint_cygwin.c would change the stdin to the raw mode, and then change back to the normal mode every time they were called. This made them a bit glitchy. I changed this so that stdin goes into the raw mode just before running the terminal loop, and it then goes back to the normal mode after exiting the loop. This makes the console I/O work cleanly now.
The only remaining problem that I know of is that exiting loadp2 will reset the P2 under Linux. So to keep the P2 from resetting you have to use the -t option even if there's no need for terminal I/O.
I haven't looked at increasing the baud rate yet. Most of the programs I've been playing with are less than 30K in size, so they only take a few seconds to load at 115200. However, the VGA demo programs do take a long time to load. I'll try increasing the baud rate tomorrow.
Ouch, there's quite a lot that could be nick-picked about that posting Mike. Source vs binary is significant, since when was Wine every considered as platform independent?, pendulum swung how far?, sad?
Just now on my Win 10 box I am running almost everything I would normally be running on Linux. Let's scan the icons on my desktop:
Chrome
Firefox
Simple IDE
Propeller IDE
BST
Quartus
Qtcreator
Visual Studio Code
Atom
Espruino IDE
Gimp
Inkscape
KiCad
Atom
Lazarus
LTSpice
Mosquitto
Virtual Box
Bash (Cygwin or LSW)
The last of those gets me the ability to run pretty much all the command line tools from Ubuntu/Debian.
It truly is the year of Linux on the desktop. (Only the actual Linux kernel is not here except under VirtualBox)
Quite amazing now that MS is busy embracing Open Source and Free Software.
I deliberately left "embracing" there in a somewhat ambiguous manner. I thought about putting quotes around it.
For those who do not know it's from the famous expression "Embrace, extend and extinguish" describing MS tactics. From Wikipedia:
"Embrace, extend, and extinguish",[1] also known as "Embrace, extend, and exterminate",[2] is a phrase that the U.S. Department of Justice found[3] that was used internally by Microsoft[4] to describe its strategy for entering product categories involving widely used standards, extending those standards with proprietary capabilities, and then using those differences to disadvantage its competitors.
I attended a Microsoft Developer Day session last year and I nice young MS guy, an ex Firefox dev I believe, assured us that MS was not like that anymore and really, truly, wanted to support Open Source. He even admitted that MS has a lot of sins behind it.
One smells a rat of course and one wonders what MS is up to.
My only conclusion is that it's got to do with Azure. They know the era of getting pots of money from a desktop OS and apps is coming to and end. Everything is moving to the "cloud". They need us to select their cloud, Azure, not somebody else's. And God forbid not something that resembles an actual cloud.
To make this azure lock in plan work they have to attract a new generation of developers who are expecting Open Source tools. Hence Visual Studio Code,
the Chakra JS engine for node.js, LSW, etc.
Is PropGCC compatible with the Eigen c/c++ matrix library? It's very useful for coding feedback control systems and matrix heavy operations like the nonlinear Extended Kalman Filter. I used it for this falling-up robot:
Wish I could do it with the Prop2, but I had to move on.
... Extended Kalman Filter. I used it for this falling-up robot:
Funny you should use that for motion control. Someone recently posted a link to a Kalman Filter tutorial and there was some discussion around the incompleteness of what each part did but one thing that did stand out was how similar the whole algorithm is to a regular servo loop.
...one thing that did stand out was how similar the whole algorithm [kalman] is to a regular servo loop.
What?!
I presume by "regular servo loop" you mean the typical PID controller?
The Kalman filter is a thousand times more complicated and is predicated on different ideas.
I refuse to believe you could watch this lecture series on the Kalman Filter and still say it is similar to PID:
Even by the end of the series you don't have anything that will actually control anything much without a lot more thought. If I squint very hard I can just about understand what he has going on there. That's without understanding most of the maths behind it.
The only similarity I see is that the they both have sensor inputs, both deliver outputs and have processing in the middle
At some point I think I have to implement what he shows in that series, in C++ or whatever, and try and reproduce the results of his example.
Hmm....thinking about it some more a Kalman Filter and a PID controller don't even perform the same function.
As far as I can gather so far the Kalman Filter takes sensor inputs from all kind of sources, fuses them together and arrive at an estimate of something useful, position, orientation, speed, whatever.
However the Kalman Filter itself does say anything about what control changes one should make to change those positions, orientations, speeds, etc to what you want them to be. A PID algorithm does.
Profile generation is outside the servo loop, it forms as an input to the servo.
To use your words, servos take input from multiple sources (At the simplest form the profile "set-point" and feedback.) and fuses them all together to produce a demand output. PID is the classic central part of a servo but certainly doesn't have to be the only way. Kalman Filter looks to be a suitable alternative to PID inside of the servo loop.
The only similarity I see is that the they both have sensor inputs, both deliver outputs and have processing in the middle
That's the thing. Regular filters are one input, one output, with band filtering as its objective. That most definitely is not what is going on in a KF, where there is behavioural mapping/modelling being performed. The name of "Filter" has particularly loose meaning in this case me thinks.
Depending on how you look at it a PID controller only has one input, the error signal. And one output, the drive/control signal. It does it's best to keep the error to zero, depending on you P, I and D coefficients.
Or one could allow that the inputs are the desired set point and the actual situation. The required subtraction to get the error being part of the algorithm.
I do agree that the "filter" in Kalman Filter is not being used in the typical frequency domain idea of filter. Rather
it reflects the idea of filtering noise and errors so as to get an accurate estimation of reality. It is doing this from the multiple sensor inputs
and the physical model you have built in.
However, I don't see the Kalman Filter alone as a control system. It is not generating control outputs. It needs something else to close the loop.
For example, at the end of the Kalman Filter process you might know where you are in 3D space and you know which way you are pointing. But that says nothing about what to do if your position/orientation is not what you want.
Comments
C99 provides 'intptr_t' as 'the integer that's the same size as a pointer' in <stdint.h>.
Eric[/quote]
Worked for 32 bit system and OS but memory size has gone up since then.
Maybe it is also timing/delays ? I'd usually expect 115200 to be far enough clear of 2MBd to make that a non issue, but one never knows....
eg 2 Stop bits may help at elevated baud rates( > 1M?) , as one bottleneck I recall is from AutoBAUD (hardware) + Calcs re-calibrating the SmartPin quick enough to be ready for the next char Start bit edge.
There could be other timing issues around reset-release to first Char.
What delays are used, and what loader code do you use ?
One way to check if this uses 20M or 80M in FPGA, would be to push higher than 2MBd,
If you have FT232H/FT2232H, they can do most of these
(2000000,2181818.182,2400000,2666666.667,3000000,3428571.429,4000000 & 6M & 12M)
I'm using P2's default text loader.
Txt/hex data is sent as one big chunk from PC end with 1 stop bit.
The FPGA's reset to 20Mhz and the code loaded must have a "CLKSET #$FF" instruction to switch to 80MHz after loading.
So loadp2 works fine with MinGW. I'll clean up the code a bit and post the new source code.
The only remaining problem that I know of is that exiting loadp2 will reset the P2 under Linux. So to keep the P2 from resetting you have to use the -t option even if there's no need for terminal I/O.
Or can you now get to 2Mbd ok ? ( & all values below that ?)
If you use Windows use MinGW or Cygwin to run Linux software on Windows.
The pendulum swung full backwards. Nor its not 'Use Wine to run Propeller-Tool on Linux' its use 'MinGW to run Linux Tools on Windows'.
Jupp. Platform independent. Great.
Sad.
Mike
Just now on my Win 10 box I am running almost everything I would normally be running on Linux. Let's scan the icons on my desktop:
Chrome
Firefox
Simple IDE
Propeller IDE
BST
Quartus
Qtcreator
Visual Studio Code
Atom
Espruino IDE
Gimp
Inkscape
KiCad
Atom
Lazarus
LTSpice
Mosquitto
Virtual Box
Bash (Cygwin or LSW)
The last of those gets me the ability to run pretty much all the command line tools from Ubuntu/Debian.
It truly is the year of Linux on the desktop. (Only the actual Linux kernel is not here except under VirtualBox)
Quite amazing now that MS is busy embracing Open Source and Free Software.
For those who do not know it's from the famous expression "Embrace, extend and extinguish" describing MS tactics. From Wikipedia:
"Embrace, extend, and extinguish",[1] also known as "Embrace, extend, and exterminate",[2] is a phrase that the U.S. Department of Justice found[3] that was used internally by Microsoft[4] to describe its strategy for entering product categories involving widely used standards, extending those standards with proprietary capabilities, and then using those differences to disadvantage its competitors.
I attended a Microsoft Developer Day session last year and I nice young MS guy, an ex Firefox dev I believe, assured us that MS was not like that anymore and really, truly, wanted to support Open Source. He even admitted that MS has a lot of sins behind it.
One smells a rat of course and one wonders what MS is up to.
My only conclusion is that it's got to do with Azure. They know the era of getting pots of money from a desktop OS and apps is coming to and end. Everything is moving to the "cloud". They need us to select their cloud, Azure, not somebody else's. And God forbid not something that resembles an actual cloud.
To make this azure lock in plan work they have to attract a new generation of developers who are expecting Open Source tools. Hence Visual Studio Code,
the Chakra JS engine for node.js, LSW, etc.
Some say "EEE" is a policy that alive and well in MS:
http://techrights.org/2016/03/21/microsoft-elop-telstra/
Wish I could do it with the Prop2, but I had to move on.
I presume by "regular servo loop" you mean the typical PID controller?
The Kalman filter is a thousand times more complicated and is predicated on different ideas.
I refuse to believe you could watch this lecture series on the Kalman Filter and still say it is similar to PID:
Even by the end of the series you don't have anything that will actually control anything much without a lot more thought. If I squint very hard I can just about understand what he has going on there. That's without understanding most of the maths behind it.
The only similarity I see is that the they both have sensor inputs, both deliver outputs and have processing in the middle
At some point I think I have to implement what he shows in that series, in C++ or whatever, and try and reproduce the results of his example.
As far as I can gather so far the Kalman Filter takes sensor inputs from all kind of sources, fuses them together and arrive at an estimate of something useful, position, orientation, speed, whatever.
However the Kalman Filter itself does say anything about what control changes one should make to change those positions, orientations, speeds, etc to what you want them to be. A PID algorithm does.
Or am I missing a big point here somewhere?
To use your words, servos take input from multiple sources (At the simplest form the profile "set-point" and feedback.) and fuses them all together to produce a demand output. PID is the classic central part of a servo but certainly doesn't have to be the only way. Kalman Filter looks to be a suitable alternative to PID inside of the servo loop.
Clearly I am not understanding.
Depending on how you look at it a PID controller only has one input, the error signal. And one output, the drive/control signal. It does it's best to keep the error to zero, depending on you P, I and D coefficients.
Or one could allow that the inputs are the desired set point and the actual situation. The required subtraction to get the error being part of the algorithm.
I do agree that the "filter" in Kalman Filter is not being used in the typical frequency domain idea of filter. Rather
it reflects the idea of filtering noise and errors so as to get an accurate estimation of reality. It is doing this from the multiple sensor inputs
and the physical model you have built in.
However, I don't see the Kalman Filter alone as a control system. It is not generating control outputs. It needs something else to close the loop.
For example, at the end of the Kalman Filter process you might know where you are in 3D space and you know which way you are pointing. But that says nothing about what to do if your position/orientation is not what you want.