Here's some example diagrams of various servo diagrams. Most have at least parts of the basic PID spread around but most have extra components and, more importantly, the whole servo loop structure extends well beyond the PID fusing elements.
And a significant input is always the left edge profile inputs - called various things like set temperature, target position - whatever the ideal control is.
I just had a random thought on this. I wonder if those neural nets can be trained on something like these problems? The benefit may be either auto tuning and or ability to operate with past experience. Run one, guide it, once done, ship it trained kind of thing.
The number of inputs and desired output is generally small too. Might not even need to be a big net.
The "past experience" may present as better stability and or faster arrivals at control target, like when humans do this knowing how a given system behaves.
Once trained for a specific domain, they can be bit depth reduced to a fraction of their training and development size and depth and still function with high fidelity.
Was reading a paper on this a few days ago. They took one for images and reduced it to 8 bits and then even fewer and it worked fine, but was small and used only basic CPU math. Their goal was to put the net on mobile, for example. Client side voice recognition, etc...
I kind of want to play with the idea myself, but have no real target to test on. So, I'm just tossing it out there.
Not sure how this topic wandered so far afield, but getting back to the tools for P2: Dave, your loadp2 and p2asm work great! Thank you for posting them. PNut is a quick way to get started, but for me nothing beats command line tools for productivity.
I got loadp2 running reliably under Linux, Cygwin and MinGW.
Do the baud problems you mentioned before still persist ?
Or can you now get to 2Mbd ok ? ( & all values below that ?)
I ran some tests with loadp2 using only Prop_Txt and I was able to go up to 4Mbd on Linux. On a Windows machine I could only go up to 256Kbd. I haven't figured out how to get a higher rate on Windows yet, but it must be possible. PNut can load the large VGA demo program in about 2 seconds, which works out to about 2Mbd. BTW, Chip did mention in a post back in 2015 that PNut uses a 2-stage loader using MainLoader. The fact that user programs come up in the 80MHz mode also indicates that a 2-stage loader is used.
Not sure how this topic wandered so far afield, but getting back to the tools for P2: Dave, your loadp2 and p2asm work great! Thank you for posting them. PNut is a quick way to get started, but for me nothing beats command line tools for productivity.
Thanks, Eric. Let me know if you find any problems, and I'll fix them as soon as I can. I'm going to work on loadp2 a bit more to get a higher baud rate, and to allow the user to set an operating baud rate for the program. I'll also post an update to s2p to fix a few issues.
I ran some tests with loadp2 using only Prop_Txt and I was able to go up to 4Mbd on Linux. On a Windows machine I could only go up to 256Kbd. I haven't figured out how to get a higher rate on Windows yet, but it must be possible.
Quite a difference, are they similar resourced PC's ? 4MBd is good
Do they use the same serial-bridge device ? Which one ? One stop bit or two ?
Autobaud will work above 2MBd region, but the granularity gets worse.
If you are lucky with a Crystal-derived 20MHz and a Crystal-derived, or Crystal-locked 48MHz in USB bridge, 4MBd should extract with no offset, but 4MBd is less likely on a final device RC osc.
The most capable bridge device for software testing is the FT2232H (crystal, and larger buffers) and then confirm more vanilla bridges like FT230X or CP2102N.
PNut can load the large VGA demo program in about 2 seconds, which works out to about 2Mbd. BTW, Chip did mention in a post back in 2015 that PNut uses a 2-stage loader using MainLoader. The fact that user programs come up in the 80MHz mode also indicates that a 2-stage loader is used.
@Dave
Here's my Windows app that I have been using to test the serial loader.
It detects multiple P2's and generates Txt and Hex files too.
Runs Ok @ 2Mbaud on my Pc's.
I'm curious to see if it works on your machine.
Just to be clear, the loadp2 serial speed limitation on Windows is a software limitation, and not hardware. Running PNut on my Windows machine appears to run at 2Mbd without a problem. The GCC libraries for MinGW and Cygwin provide maximum baud rates of 256000. This seems to be a Windows software limitation. However, there are clearly ways to get around it as shown by PNut and ozprodev's software. ozprodev, can you post your source code? What language did you write it in?
Just to be clear, the loadp2 serial speed limitation on Windows is a software limitation, and not hardware. Running PNut on my Windows machine appears to run at 2Mbd without a problem. The GCC libraries for MinGW and Cygwin provide maximum baud rates of 256000. This seems to be a Windows software limitation. However, there are clearly ways to get around it as shown by PNut and ozprodev's software. ozprodev, can you post your source code? What language did you write it in?
Are you trying to use the enum symbols for baud rate? I think you can just use the integer value instead of the symbols to get the higher baud rates.
Cygwin uses the rates defined in winbase.h, which is included from windows.h. They are defined as "#define CBR_xxxx xxxx", and they do match the numerical value of the baud rate. However, CBR_xxxx values only go up to 256000. The Bxxxx numbers are defined in termios.h, and the go up to B3000000, which is defined as 0x0100f. The 0x01xxx indicates it an extended baud rate. The routines that osint_cygwin.c uses to set the baud rate use the CBR_xxxx values, and not Bxxxx.
I've tried using the numerical value, but nothing seems to work above 256000. For values below that, I think the driver uses the nearest CBR_xxxx rate.
Serial ports are treated differently in Windows than they are in Linux. In Linux the serial file structure can be manipulated just like any other file. That's not the case in Windows. There must be a way to increase the baud rate under Windows, but I just haven't figured out how to do it yet. An internet search shows that many people of encountered this problem. I keep searching, but if I can't find a quick solution I just leave it at 256Kbd for now.
Cygwin uses the rates defined in winbase.h, which is included from windows.h. They are defined as "#define CBR_xxxx xxxx", and they do match the numerical value of the baud rate. However, CBR_xxxx values only go up to 256000. The Bxxxx numbers are defined in termios.h, and the go up to B3000000, which is defined as 0x0100f. The 0x01xxx indicates it an extended baud rate. The routines that osint_cygwin.c uses to set the baud rate use the CBR_xxxx values, and not Bxxxx.
I've tried using the numerical value, but nothing seems to work above 256000. For values below that, I think the driver uses the nearest CBR_xxxx rate.
Serial ports are treated differently in Windows than they are in Linux. In Linux the serial file structure can be manipulated just like any other file. That's not the case in Windows. There must be a way to increase the baud rate under Windows, but I just haven't figured out how to do it yet. An internet search shows that many people of encountered this problem. I keep searching, but if I can't find a quick solution I just leave it at 256Kbd for now.
Just to be clear, the loadp2 serial speed limitation on Windows is a software limitation, and not hardware. The GCC libraries for MinGW and Cygwin provide maximum baud rates of 256000.
Wow, really, seems like the dark ages....
I recall RaspPi also had similar imposed limitations, but they were quickly fixed.
However, there are clearly ways to get around it as shown by PNut and ozprodev's software. ozprodev, can you post your source code? What language did you write it in?
Running PNut on my Windows machine appears to run at 2Mbd without a problem.
I'm a little stunned the much-vaunted C is stuck way back in the past, with enum locked Baud values.
Serial hardware was never really enum locked, and for a long time it's been possible to use a LONG to define BAUD.
The better USB serial ports deliver their nearest BAUD value, (up to 3MBd, 12MBd, 15MBd), some older/poorer drivers will spit an error.
That's why a variable baud choice, and 115200 default is a good idea.
I've tried using the numerical value, but nothing seems to work above 256000. For values below that, I think the driver uses the nearest CBR_xxxx rate.
Hmm, don't you just hate it when some coder from the past, thinks they know best, and over-rule your values...
An internet search shows that many people of encountered this problem.
Surely someone has solved it, or are those C-flows not that widely used for multi-platform development ?
Here, we run serial COMs in FreePascal or FreeBasic - both allow Longs for Baud, and accept any value.
The USB-Bridge driver then either uses closest, or gives an error.
Well it turns out that I can specify a baud rate that is not in the list of defined constants. So David Betz was correct about this. I had to add a couple of delays to get things to work. One delay was added after the secondary loader was loaded, and before I started to load the user program. The second delay was added after the user program was loaded and before changing the baud rate to the user baud rate. So now I'm able to load at 2Mbd.
So David Betz was correct about this. I had to add a couple of delays to get things to work. One delay was added after the secondary loader was loaded, and before I started to load the user program. The second delay was added after the user program was loaded and before changing the baud rate to the user baud rate. So now I'm able to load at 2Mbd.
What delays are needed ?
There seems multiple levels here ? Is that 2MBd for the 64b encoded, 20MHz boot download portion ?
I think ozpropdev was using just a single large block copy, of the 64b, 20MHz boot ?
I use 50ms after the reset, and 100ms for the other two delays.
Yes, there are multiple levels. I use 2MBd for both levels. I use Prop_Hex rather than Prop_Txt, though I have tried both. Prop_Hex is easier to use.
I have used Prop_Txt to download the user program, but MainLoader is 25% faster than Prop_Txt, so why not use it? MainLoader has the added benefit of pre-setting the clock rate to 80MHz. In the future I might add a checksum at the end just to verify that the code loaded correctly. I can't do that with Prop_Txt.
I have used Prop_Txt to download the user program, but MainLoader is 25% faster than Prop_Txt, so why not use it?
MainLoader has the added benefit of pre-setting the clock rate to 80MHz.
Sure, two stage loaders have a place, and if you go to 80MHz, you probably can support 6MBd Stage 2 speeds. (FT2232H, FT232H)
Adafruit have this https://www.adafruit.com/product/2264
Is it also important to have the ROM download supported up to the top practical speed, as that is simplest and gives an easy to diagnose base.
.. In the future I might add a checksum at the end just to verify that the code loaded correctly. I can't do that with Prop_Txt.
Reading the DOCs multiple times, I think there is a verify-echo possible, as in
..
Before sending the final “~” character, it is a good time to poll the error status by sending a “?” character and waiting for either the “.” (okay) or “!” (error) character to come back. In the case of a signature and a large program, it will take about one second per 100KB of loaded program (not sent text) to compute the SHA-256/HMAC signature, before a response character will be sent.
..
Sender: “> Prop_Hex 0 0 0 0 FB F7 23 F6 FD FB 23 F6 25 26 80 FF 28 80 66 FD F0 FF 9F FD ~”
In case the key was zero and you wanted to sign the data, anyway:
Loader: “.”
Sender: “~”
It’s a good idea to start each hex data line with a “>” character, to keep the baud rate tightly calibrated.
Prop_Txt
The Prop_Txt command is like Prop_Hex, but with one difference: Instead of hex bytes separated by whitespaces, it takes in Base64 data, which are text characters that convey six bits, each. This format is 2.25x denser than hex, and so minimizes transmission size and time. Any signature bytes, however, must still be expressed in hex.
I think that merges to something like this, Prop_Txt + 32 byte signed ?
Sender:
“> Prop_Txt 0 0 0 0 +/cj9v37I/YlJoD/KIBm/fD/n/0 | 4B 7D 21 17 27 EE 87 C0 DD 47 D4 A8 70 5B C5 F1 6F 6D 9B 81 44 83 E6 B3 20 51 28 BE 5D D8 85 40 ?”
Wait for Loader: “.” (okay) or “!” (error) ( appx one second per 100KB of loaded binary program)
Sender: “~”
...
Serial ports are treated differently in Windows than they are in Linux. In Linux the serial file structure can be manipulated just like any other file. That's not the case in Windows. There must be a way to increase the baud rate under Windows, but I just haven't figured out how to do it yet. An internet search shows that many people of encountered this problem. I keep searching, but if I can't find a quick solution I just leave it at 256Kbd for now.
I know this is pretty much sorted now, but I spotted this over in AVR land, which is a Python Loader for their newest Debug Interface.
They've been quite smart here, instead of custom complex debug protocols, or pin-consuming SPI, they've chosen a Serial-UART-variant.
This means they need a calibrated clock, but all small MCUs have those these days.
Elements :
They vary Baud rate to send a double BREAK, as 1200Bd.BreakChar.50ms.1200Bd.BreakChar.50ms (BreakChar = 0x00)
I don't think that Autobauds here, just gives a solid state engine reset.
(tho one could use a known-width-break to Clock-Cal, here 7.500ms wide, and Bit-time = BreakW/864, a 9600Bd Break would select 921600Bd)
Then, they use 115200 as a default speed (use PARITY_EVEN, STOPBITS_TWO & these are much smaller chips than P2), and I spot this...
# Inter-byte delay
self.ibdly = 0.0001
Curious, as I've not seen delays under 1ms used around FS USB Bridges, as that's the USB frame time.
Not sure you can realistically ask any OS to pace such an elastic link, to 0.1ms ?
They seem to be hoping to allow for a half-duplex reply ?
12/115200 = 104.166us 11/115200 = 95.486us 10/115200 = 86.805us
If the echos are rare, and carefully paced bursts, they could get away with this.
All of this could port over to P2, Half Duplex, and Full Duplex ?
It would be nice to have One-Pin P2 boot working from a Standard PC host, till now I've been planning on a local MCU for one-pin cases.
Has anyone tried Python at 2Mbd ?
I've updated s2p, p2asm and loadp2 and put them all in the attached zip file. loadp2 can now load a file without specifying the serial port. I also added a script file called c2b that will compile and assemble a C file, and then load it into a P2 FPGA board.
I finally got the P2 compiler tools to the point where I can post a new update. In this update I introduce a script file called p2gcc that runs the various tools to produce an executable binary file, and optionally loads and runs it on a P2 FPGA board. I also updated the assembler to the V19 instructions mappings, so FPGA v19 is needed to run the P2 executables. I modified loadp2 to set up for a 60MHz clock frequency by default. The clock frequency and mode can be changed using command-line arguments.
I added a linker called p2link that will link the object files together, and there is a lib subdirectory that contains stdio, stdlib and string libraries with some of the most frequently used library routines. I haven't put file I/O routines in the libraries yet, but I do have some basic file I/O routines included with the filetest and fsrwtest sample programs. These programs assume that an SD card is connected to I/O pins 0, 1, 2 and 3.
The zipfile contains Windows/MinGW executable files. Executables for Cygwin and Linux can be built using build_cygwin and build_linux.
All of the sample programs and tools have been tested under Windows, MinGW, Cygwin and Linux. I anticipate that there are bugs that I haven't found yet, so please let me know if you encounter any issues. I think the next step is to integrate file I/O into the libraries and make the libraries more complete. I plan on accomplishing this by borrowing the library code from PropGCC.
build_linux will build all binaries on masOS, as well... I have not had a chance to test results on an fpga P2 yet, but running testall 'almost' succeeds.
./testall
... <-- a bunch of successful results removed for this post
propeller-elf-gcc -mcog -Os -S sdspi.c
sdspi.c:48:16: error: macro "getcnt" passed 1 arguments, but takes just 0
sdspi.c:49:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' token
Modifying sdspi.c to change all references to 'getcnt' to 'getcntX' makes testall complete successfully...
int getcntX(void) // <-- renamed as somehow there is already a getcnt(arg) macro that takes an arg
{
return CNT;
}
This may have been caused due to the version of propeller-elf-gcc on my Mac. Somewhere there's a getcnt macro that has an argument?
Using built-in specs.
COLLECT_GCC=propeller-elf-gcc
COLLECT_LTO_WRAPPER=/opt/parallax/bin/../libexec/gcc/propeller-elf/4.6.1/lto-wrapper
Target: propeller-elf
Configured with: /Users/myUserName/source/propeller-gcc/gcc4/configure --target=propeller-elf --prefix=/Users/myUserName/source/propeller-gcc4-build/target --disable-nls --disable-shared --enable-languages=c,c++ --with-pkgversion=propellergcc-alpha_v1_9_0_ --with-bugurl=http://code.google.com/p/propgcc/issues
Thread model: single
gcc version 4.6.1 (propellergcc-alpha_v1_9_0_)
I grep'ed the header files in the PropGCC include directory on my machine, and I can't find a getcnt macro defined there. The getcnt function in sdspi.c could be replaced with CNT. I had to create the getcnt function to get the code to compile under Taz C. I can remove it for the next update. However, it would be good to know where the macro is defined on your machine. It seems like it must be in propeller.h or maybe cog.h.
getcnt looks to be defined without arguments on line 53 of: "propeller-gcc/lib/include/propeller1.h"
/**
* @brief CNT register accessor.
*
* @details P1 provides a COG accessible CNT register.
*
* This macro is a convenience for portability between P1/P2 code.
*
* @returns the global CNT value.
*/
#define getcnt() _CNT
Comments
And here's a related link to integrating modelling into the servo - https://www.routledgehandbooks.com/doi/10.4324/9780203132746.ch3
The number of inputs and desired output is generally small too. Might not even need to be a big net.
The "past experience" may present as better stability and or faster arrivals at control target, like when humans do this knowing how a given system behaves.
Once trained for a specific domain, they can be bit depth reduced to a fraction of their training and development size and depth and still function with high fidelity.
Was reading a paper on this a few days ago. They took one for images and reduced it to 8 bits and then even fewer and it worked fine, but was small and used only basic CPU math. Their goal was to put the net on mobile, for example. Client side voice recognition, etc...
I kind of want to play with the idea myself, but have no real target to test on. So, I'm just tossing it out there.
Eric
Do they use the same serial-bridge device ? Which one ? One stop bit or two ?
Autobaud will work above 2MBd region, but the granularity gets worse.
If you are lucky with a Crystal-derived 20MHz and a Crystal-derived, or Crystal-locked 48MHz in USB bridge, 4MBd should extract with no offset, but 4MBd is less likely on a final device RC osc.
The most capable bridge device for software testing is the FT2232H (crystal, and larger buffers) and then confirm more vanilla bridges like FT230X or CP2102N.
Interesting.
Here's my Windows app that I have been using to test the serial loader.
It detects multiple P2's and generates Txt and Hex files too.
Runs Ok @ 2Mbaud on my Pc's.
I'm curious to see if it works on your machine.
What version of Windows and appx CPU speed is the test PC ?
Win 10 Home i7 2.5GHz laptop
Win 10 Home Pentium 2.1GHz laptop
All tests used Propplugs except for P123-A7 & A9 boards which used their on-board FT bridges (I don't have part number close at hand.)
I've tried using the numerical value, but nothing seems to work above 256000. For values below that, I think the driver uses the nearest CBR_xxxx rate.
Serial ports are treated differently in Windows than they are in Linux. In Linux the serial file structure can be manipulated just like any other file. That's not the case in Windows. There must be a way to increase the baud rate under Windows, but I just haven't figured out how to do it yet. An internet search shows that many people of encountered this problem. I keep searching, but if I can't find a quick solution I just leave it at 256Kbd for now.
My code was written in Visual Basic 2015.
Here's the source code.
Not sure it will be much help to you though.
Wow, really, seems like the dark ages....
I recall RaspPi also had similar imposed limitations, but they were quickly fixed.
Well, maybe a windows-side software problem, related to MinGW and Cygwin, and not so much a 'Windows software limitation'
IIRC PNut uses Freepacal, and above ozpropdev says Visual Basic 2015
I'm a little stunned the much-vaunted C is stuck way back in the past, with enum locked Baud values.
Serial hardware was never really enum locked, and for a long time it's been possible to use a LONG to define BAUD.
The better USB serial ports deliver their nearest BAUD value, (up to 3MBd, 12MBd, 15MBd), some older/poorer drivers will spit an error.
That's why a variable baud choice, and 115200 default is a good idea.
Hmm, don't you just hate it when some coder from the past, thinks they know best, and over-rule your values...
Surely someone has solved it, or are those C-flows not that widely used for multi-platform development ?
Here, we run serial COMs in FreePascal or FreeBasic - both allow Longs for Baud, and accept any value.
The USB-Bridge driver then either uses closest, or gives an error.
I've also used Synaser libraries, mentioned with links here :
http://wiki.freepascal.org/Hardware_Access
Seems good dual-platform support and examples here,
Source is here... with both unix and windows forms.
https://www.ararat.cz/synapse/doku.php/download
and the synaser.pas has this record defined, (I think this is Windows Control Block record ?)
type TDCB = record DCBlength: DWORD; BaudRate: DWORD; Flags: Longint; wReserved: Word; XonLim: Word; XoffLim: Word; ByteSize: Byte; Parity: Byte; StopBits: Byte; XonChar: CHAR; XoffChar: CHAR; ErrorChar: CHAR; EofChar: CHAR; EvtChar: CHAR; wReserved1: Word; end; PDCB = ^TDCB;I think you can change the BaudRate in that record, and sidestep other code that limits your choices ?
What delays are needed ?
There seems multiple levels here ? Is that 2MBd for the 64b encoded, 20MHz boot download portion ?
I think ozpropdev was using just a single large block copy, of the 64b, 20MHz boot ?
That's correct, just a P2 reset then burst the 64b encoded chunk @2Mbaud.
Yes, there are multiple levels. I use 2MBd for both levels. I use Prop_Hex rather than Prop_Txt, though I have tried both. Prop_Hex is easier to use.
I have used Prop_Txt to download the user program, but MainLoader is 25% faster than Prop_Txt, so why not use it? MainLoader has the added benefit of pre-setting the clock rate to 80MHz. In the future I might add a checksum at the end just to verify that the code loaded correctly. I can't do that with Prop_Txt.
True, but at the expense of speed.
Sure, two stage loaders have a place, and if you go to 80MHz, you probably can support 6MBd Stage 2 speeds. (FT2232H, FT232H)
Adafruit have this https://www.adafruit.com/product/2264
Is it also important to have the ROM download supported up to the top practical speed, as that is simplest and gives an easy to diagnose base.
Good point, I thought Chip had some ROM loader checksum capability, but I do not see it in the docs ?
..
Before sending the final “~” character, it is a good time to poll the error status by sending a “?” character and waiting for either the “.” (okay) or “!” (error) character to come back. In the case of a signature and a large program, it will take about one second per 100KB of loaded program (not sent text) to compute the SHA-256/HMAC signature, before a response character will be sent.
..
Sender: “> Prop_Hex 0 0 0 0 FB F7 23 F6 FD FB 23 F6 25 26 80 FF 28 80 66 FD F0 FF 9F FD ~”
In case the key was zero and you wanted to sign the data, anyway:
Sender: “> Prop_Hex 0 0 0 0 FB F7 23 F6 FD FB 23 F6 25 26 80 FF 28 80 66 FD F0 FF 9F FD | 4B 7D 21 17 27 EE 87 C0 DD 47 D4 A8 70 5B C5 F1 6F 6D 9B 81 44 83 E6 B3 20 51 28 BE 5D D8 85 40 ~”
To do the same, but also poll for an error after the signature has been checked (note the space before the “?”):
Sender: “> Prop_Hex 0 0 0 0 FB F7 23 F6 FD FB 23 F6 25 26 80 FF 28 80 66 FD F0 FF 9F FD | 4B 7D 21 17 27 EE 87 C0 DD 47 D4 A8 70 5B C5 F1 6F 6D 9B 81 44 83 E6 B3 20 51 28 BE 5D D8 85 40 ?”
Loader: “.”
Sender: “~”
It’s a good idea to start each hex data line with a “>” character, to keep the baud rate tightly calibrated.
Prop_Txt
The Prop_Txt command is like Prop_Hex, but with one difference: Instead of hex bytes separated by whitespaces, it takes in Base64 data, which are text characters that convey six bits, each. This format is 2.25x denser than hex, and so minimizes transmission size and time. Any signature bytes, however, must still be expressed in hex.
I think that merges to something like this, Prop_Txt + 32 byte signed ?
Sender:
“> Prop_Txt 0 0 0 0 +/cj9v37I/YlJoD/KIBm/fD/n/0 | 4B 7D 21 17 27 EE 87 C0 DD 47 D4 A8 70 5B C5 F1 6F 6D 9B 81 44 83 E6 B3 20 51 28 BE 5D D8 85 40 ?”
Wait for Loader: “.” (okay) or “!” (error) ( appx one second per 100KB of loaded binary program)
Sender: “~”
I know this is pretty much sorted now, but I spotted this over in AVR land, which is a Python Loader for their newest Debug Interface.
https://github.com/mraardvark/pyupdi/blob/master/updi/physical.py
https://github.com/mraardvark/pyupdi
They've been quite smart here, instead of custom complex debug protocols, or pin-consuming SPI, they've chosen a Serial-UART-variant.
This means they need a calibrated clock, but all small MCUs have those these days.
Elements :
They vary Baud rate to send a double BREAK, as 1200Bd.BreakChar.50ms.1200Bd.BreakChar.50ms (BreakChar = 0x00)
I don't think that Autobauds here, just gives a solid state engine reset.
(tho one could use a known-width-break to Clock-Cal, here 7.500ms wide, and Bit-time = BreakW/864, a 9600Bd Break would select 921600Bd)
Then, they use 115200 as a default speed (use PARITY_EVEN, STOPBITS_TWO & these are much smaller chips than P2), and I spot this...
# Inter-byte delay self.ibdly = 0.0001Curious, as I've not seen delays under 1ms used around FS USB Bridges, as that's the USB frame time.Not sure you can realistically ask any OS to pace such an elastic link, to 0.1ms ?
They seem to be hoping to allow for a half-duplex reply ?
12/115200 = 104.166us 11/115200 = 95.486us 10/115200 = 86.805us
If the echos are rare, and carefully paced bursts, they could get away with this.
Their half-duplex is wired
Vcc Vcc +-+ +-+ | | +---------------------+ | | +--------------------+ | Serial port P-+ +-P MCU device | | | +----------+ | | | TX O------+ 4k7 +----o----IO UPDI | | | +----------+ | | | | | | | | | RX I----------------------+ | | | | | | | G--+ +--G | +---------------------+ | | +--------------------+ +-+ +-+ GND GNDAll of this could port over to P2, Half Duplex, and Full Duplex ?
It would be nice to have One-Pin P2 boot working from a Standard PC host, till now I've been planning on a local MCU for one-pin cases.
Has anyone tried Python at 2Mbd ?
I added a linker called p2link that will link the object files together, and there is a lib subdirectory that contains stdio, stdlib and string libraries with some of the most frequently used library routines. I haven't put file I/O routines in the libraries yet, but I do have some basic file I/O routines included with the filetest and fsrwtest sample programs. These programs assume that an SD card is connected to I/O pins 0, 1, 2 and 3.
The zipfile contains Windows/MinGW executable files. Executables for Cygwin and Linux can be built using build_cygwin and build_linux.
All of the sample programs and tools have been tested under Windows, MinGW, Cygwin and Linux. I anticipate that there are bugs that I haven't found yet, so please let me know if you encounter any issues. I think the next step is to integrate file I/O into the libraries and make the libraries more complete. I plan on accomplishing this by borrowing the library code from PropGCC.
build_linux will build all binaries on masOS, as well... I have not had a chance to test results on an fpga P2 yet, but running testall 'almost' succeeds.
./testall ... <-- a bunch of successful results removed for this post propeller-elf-gcc -mcog -Os -S sdspi.c sdspi.c:48:16: error: macro "getcnt" passed 1 arguments, but takes just 0 sdspi.c:49:1: error: expected '=', ',', ';', 'asm' or '__attribute__' before '{' tokenModifying sdspi.c to change all references to 'getcnt' to 'getcntX' makes testall complete successfully...
int getcntX(void) // <-- renamed as somehow there is already a getcnt(arg) macro that takes an arg { return CNT; }This may have been caused due to the version of propeller-elf-gcc on my Mac. Somewhere there's a getcnt macro that has an argument?
dgately
getcnt looks to be defined without arguments on line 53 of: "propeller-gcc/lib/include/propeller1.h"
dgately