You bring up a good point. Write-only devices are actually perfect examples of where a dedicated cog makes perfect sense - send the data to a buffer and then let it do the work on its own time. I think I'll do that. I'm used to things like ADCs and SD cards where you end up doing a blocking call anyway because you're waiting to read data back in. In those cases, dedicated cog is just a waste of hardware! Interesting that my ADC and SD routines both rely on SPI (dedicated cog) and my UART routines are inline assembly... I seem to have gotten things a tad backwards
I agree that a COG driver that only supports blocking calls is really a waste of a COG. It isn't really parallel processing, it's more a technique to get more COG memory space by suspending one COG and letting another one run the code. It would be totally unnecessary if the COG has more memory in the first place. This is true of the COG floating point processors as well as, I must admit, the external memory drivers used by PropGCC XMM mode. They would be totally unnecessary if there was more COG memory in the COG executing the LMM loop.
To follow up with the transmit routines being enhanced, UART receive routines are now capable of 2.75 Mbaud burst speeds. I am not sure how much time is required between words, but I believe at that baud it is going to equate to more than 1 stop bit. If anyone wants to set up a rig to test this with something that can reliably transmit high-speed serial without delays between words, I'd love to hear the results of your test.
If anyone wants to set up a rig to test this with something that can reliably transmit high-speed serial without delays between words, I'd love to hear the results of your test.
The FT232H can send packed data up to ~ 6MBd, and has baud granularity of 24MHz/N iirc, so that covers
2.4, 2.666; 3 MBd
Or, since you already have Transmit to > 4MBd, with finer granularity, the other test method would be one COG sending, and another receiving, initially in the same Prop, but checking across Props would also be useful.
Could there be merit in a (min) stop bit width definable in SysClks ( > 1 bit time floor / default) ?
Could there be merit in a (min) stop bit width definable in SysClks ( > 1 bit time floor / default) ?
That's what I'm most interested in measuring, but haven't written a program for any of my other boards to test it. It needs to come from some board with hardware UART capable of transmitting fast enough without delays
That's what I'm most interested in measuring, but haven't written a program for any of my other boards to test it. It needs to come from some board with hardware UART capable of transmitting fast enough without delays
Drawing from the other thread, if you expand Tx to a 29-30bit ability, you can pack 3 8 bit bytes into that, with either one or 2* stop bits, and use that to check Rx operation on triplets, which should be enough to detect limits
* 2 Stop bits totals 33 bit times, but the last 2 bits sent are both 1, so a single-bit-exit delay after the DJNZ manages the 33 bit frame for testing.
Oh I see what you mean. That's clever it'd take some work to unpack the data and test it for accuracy (removing stop/start bits), but that is probably a lot easier than setting up another environment for a different chip
Oh I see what you mean. That's clever it'd take some work to unpack the data and test it for accuracy (removing stop/start bits), but that is probably a lot easier than setting up another environment for a different chip
with a formatted 32b test patters (3 bytes) you could do a single add with a 32b reg with 4 x 1 bit, placed carefully @ b0.Byte1, b1.Byte2, b0,b1.Byte3 - that means RX pattern increments by 1,2,3 on each byte and you can check that in RxEnd to find errors.
At somewhere around 3MBd (3.0769?) the extra add and djnz would pack into the time budgets, to allow up to 85 * 3 = 255 byte packed blocks of rolling test patterns, for full array-flow testing.
You can also use a fixed (not changing) pattern using NCO out , workable for 1 stop bit (10bT) and 3 stop bit (12bT), but 2 stop bits(11bT) places the level change in mid bit, ie the wrong place.
2 Stop bit Sw flows could be tested in 7b or 9b settings.
Also, a Fo value of close to 17.0 bit times, can be used to confirm Rx sample-position.
ie sweep the Fo and look for Rx changes from 00H to 80H, this moves the edge in fSys increments, and ideal sample time is 17.0 bit times.
with a formatted 32b test patters (3 bytes) you could do a single add with a 32b reg with 4 x 1 bit, placed carefully @ b0.Byte1, b1.Byte2, b0,b1.Byte3 - that means RX pattern increments by 1,2,3 on each byte and you can check that in RxEnd to find errors.
At somewhere around 3MBd (3.0769?) the extra add and djnz would pack into the time budgets, to allow up to 85 * 3 = 255 byte packed blocks of rolling test patterns, for full array-flow testing.
You can also use a fixed (not changing) pattern using NCO out , workable for 1 stop bit (10bT) and 3 stop bit (12bT), but 2 stop bits(11bT) places the level change in mid bit, ie the wrong place.
2 Stop bit Sw flows could be tested in 7b or 9b settings.
Also, a Fo value of close to 17.0 bit times, can be used to confirm Rx sample-position.
ie sweep the Fo and look for Rx changes from 00H to 80H, this moves the edge in fSys increments, and ideal sample time is 17.0 bit times.
You seem to have this all mapped out in your head already... any chance I can persuade you to get it written? I've got a half-way decent unit testing environment in PropWare all ready for you
SD work continues. It's just dawned on me that my structure is pretty messed up though - including code for a fictitious third layer of abstraction (with the first being sectors and second being clusters). There are numerous references to this third tier, but it's all coded with the second and third both referring to clusters. Now that I've finally realized my mistake, it makes why I've been having trouble wrapping my head around the code. It also explains a number of bugs that have left me stumped.
The next commit is going to be huge.. but hopefully clear up a lot of bugs and simplify the code significantly through heavy refactoring.
Hello all!
Installation has been completely revamped. No more custom Python script! This is mostly good news, but a few small drawbacks. Installation instructions have been updated.
PropGCC no longer comes with. You're on your own for that.PROPGCC_PREFIX environment variable is no longer set for you.
If you already have PropWare installed, you will want to remove the PROPWARE_PATH environment variable. It is no longer needed but can be used to override the default search path.
WindowsWindows now has a simple .exe installer - just double click and press "next" until it's done. As detailed in the instructions linked above, you'll need to modify the PATH variable when running from the command line.
Linux.deb and .rpm packages are now provided for Linux installations. Just use dpkg or rpm and you'll be good to go!
MacI'm working on it. Don't hold your breath though. Sorry
Update for Mac users:
Zips are provided along with instructions on what to do. I'm afraid that's the best I can do.
WS2812It's here! A driver that shamelessly copies the core code from JohnnyMac's driver is implemented. It does not require a new cog - I believe this is a first for the Propeller - all other WS2812 objects that I've seen require a dedicated cog to run fast enough. As with UART, PropWare::WS2812 takes advantage of PropGCC's FCache execute JohnnyMac's same assembly without requiring a new cog. Well done PropGCC team!
API docs available here.
Note that the WS2812 is only in the nightly branch at the moment. I'll push to release-2.0 within the next week or so.
That's pretty neat. I like how you did it inline. That's the same technique that I used for the I2C master driver, and I think it turned out really well. It looks like it works well for the WS2812.
Does PropWare have an I2C slave object?
That's pretty neat. I like how you did it inline. That's the same technique that I used for the I2C master driver
Where do you think I learned how to write fcache code?
PropWare doesn't have any I2C object yet - master or slave. I personally am not fond of I2C so it's been very low on my priority list. Never even thought of a slave object though... interesting idea. It'd have to run painfully slowly - just like slave SPI. I suppose you could configure a specific frequency at runtime rather than paying attention to the SCLK line and then it would be no more difficult than UART. That would probably satisfy 95% of use cases.
And I'm very fond of I2C
Anyway, for my sailboat project I'm using an Arduino to read PWM inputs. The master controller then queries over I2C for the data. I'd like to replace the Arduino with a Propeller, but I'd need a slave I2C object to have it drop in. But that's waiting until I get around to writing the object.
For an I2C slave you don't set or do anything with the clock line: you're expected to be ready to respond at any time. And there's no reason it couldn't run at the standard I2C fast speed (400KHz clock): it's not all that fast from what I remember on the I2C master code.
I think what you suggest is in line with what I was saying would be feasible. But like SPI, I2C doesn't have to run at 400 kHz. So, to write a "proper" slave object, you would not take any parameter for frequency - it would only read from SDA when SCL says to. And it's reading both lines that I think would be very difficult. Maybe could be done to work up to 400 kHz? I'm not sure. I'm not too well versed in I2C.
Yeah. I think we've crossed wires here, and are in agreement. With I2C you read/write on the edge transition so there isn't too much to that portion of the ASM. The more challenging part* for a slave I2C object is setting it up to have a bank of addressable registers, and then using that bank in the rest of your program.
* It's not challenging in the "unsolved problem" sense, but challenging in the "takes time to do" sense.
Tonight I was commanded by my better half to play a song. I've long since forgotten how to play clarinet and singing has never been my forte, so I decided to make the Propeller do the hard work. In the JukeBox repository of my GitHub account, you can now find a simple Propeller application that plays a musical number as programmed via the user at the command line. I happened to have a 3.5mm jack lying around that had some wires soldered onto it already, so I stuck that into a quickstart and then plugged it into my computer speakers. It plays Mary Had a Little Lamb like a champ!
I post this in the PropWare thread because it is the first public project that I'm aware of which actually uses PropWare. If you know of others, please share the link.
Progress continues on the SD card issues. I'm a little sidetracked at the moment converting my SPI class to use inline assembly and FCache rather than a dedicated cog, which is part of what is taking so long (that, and there are some bugs that I'm just plain having trouble fixing).
But... I'm getting bored with all those bugs, so I'm going to start something that I've wanted to do for a very long time. I'm going to create a web service that compiles PropWare applications written in the browser! I'll have a service listening on my server, http://david.zemon.name/, which will accept project files to be compiled via a PropWare build system. When you click build, your project will be send over, the service will build your binary and then return you a binary (or inform you of any errors).
For those familiar with mbed - that's where I'm drawing inspiration.
I'll start a new thread for this once I have a prototype functioning
A momentous day! I've completed testing of the new FAT filesystem and SD card routines and they're working great. There are a lot of features I would still like to implement, and have every intention of implementing, but for the moment you can at least read from, write to, create, delete and check for existing files. For a full list of available functions, check out the API docs for the FatFileReader and FatFileWriter. Also, see a FatFileReader example here and FatFileWriter example here.
With the necessary work complete on the filesystem logic, I am ready to call this "release candidate 1". Before release, I will be creating an easy-install Windows package which includes a PropGCC release as well as the necessary changes to the PATH environment variable.
Please give this latest release a try and let me know if you run into issues.
Another cool change in PropWare was just added (nightly branch only at the moment). Spin files are now allowed! I've created a new supported language, "SPIN2DAT" and when this is enabled, any spin file in your project will be converted via spin2cpp to a dat file and then linked into your project. Check out the example using FullDuplexSerial.
And I finally have ideas for supporting other types of Spin via PropWare, so look for that soon.
I'm appalled with myself. I thought I was doing a pretty good job documenting all public methods... doxygen says otherwise. Having tweaked the settings a bit more, there are over 400 public classes/methods/variables/macros in the HAL that do not yet have documentation, and another couple hundred in the tests folder.
And those numbers are after I've spent the last many nights doing nothing but adding documentation.
Alas, this is going to take longer than I thought.
Cool news though is that I learned about all the different graphs doxygen & graphviz are capable of producing, so the PropWare API docs have lots of pretty pictures now!
Documentation is my key concern at the moment as I try to get a final v2.0 release out. I will be continuing to work very hard on both API docs as well as installation, getting started and example instructions. I'm also working to create formal guidelines for contributing code to PropWare, since I would like to post more requests to the community for peripheral submissions.
An alpha VGA object has been created, but yet to be tested by anyone (I don't have VGA hardware yet). See this open issue.
I also created a very simple WatchDog object which will perform a hard reset of the chip if not fed in a timely fashion.
PropWare is warning free! For the first time in a long time, the PropWare source code has zero warnings when compiled with "-Wall". I did have to cheat in one small spot though: the Runnable class.
plate<class T>
static int8_t invoke (T &runnable) {
static_assert(std::is_base_of<Runnable, T>::value,
"Only PropWare::Runnable and its children can be invoked");
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wpmf-conversions"
return (int8_t) _start_cog_thread(runnable.get_stack_top(), (void (*) (void *)) &T::run, (void *) &runnable,
&runnable.m_threadData);
#pragma GCC diagnostic pop
}
I don't think there is any way to get around that though. Perhaps when release 2.0 for PropWare is complete, I'll work on the warnings coming out of Simple and libpropeller too.
I've just reported several issues at PropWare's github repository. Hopefully, they will help in sorting-out Mac OS X installation & configuration problems.
@dgately, I'll be tackling the OSX issues tomorrow.
This week I've removed all traces of Python from PropWare. It served its purpose well while I was using it, but I've learned how to force git and CMake to do everything I was previously doing with Python.... and it's now done with fewer lines of code and results in a cleaner workspace. The change was rather drastic though, so if anyone experiences issues with missing symbols in libraries or missing headers, please let me know so I can get them added in.
Another benefit is that PropWare now downloads the Learn folder straight from git, instead of relying on a zip to be published to Parallax's website. This is a big bonus for me because those zips were published to Dropbox, which is blocked by my company's firewall.
Another benefit is that PropWare now downloads the Learn folder straight from git, instead of relying on a zip to be published to Parallax's website.
Good news! You may want to mention in the ReadMe that git users should use "git clone --recursive https://github.com/DavidZemon/PropWare.git" to get all of PropWare, libpropeller & the Learn folder content with a single command.
Comments
Documentation was also updated.
The FT232H can send packed data up to ~ 6MBd, and has baud granularity of 24MHz/N iirc, so that covers
2.4, 2.666; 3 MBd
Or, since you already have Transmit to > 4MBd, with finer granularity, the other test method would be one COG sending, and another receiving, initially in the same Prop, but checking across Props would also be useful.
Could there be merit in a (min) stop bit width definable in SysClks ( > 1 bit time floor / default) ?
Drawing from the other thread, if you expand Tx to a 29-30bit ability, you can pack 3 8 bit bytes into that, with either one or 2* stop bits, and use that to check Rx operation on triplets, which should be enough to detect limits
* 2 Stop bits totals 33 bit times, but the last 2 bits sent are both 1, so a single-bit-exit delay after the DJNZ manages the 33 bit frame for testing.
with a formatted 32b test patters (3 bytes) you could do a single add with a 32b reg with 4 x 1 bit, placed carefully @ b0.Byte1, b1.Byte2, b0,b1.Byte3 - that means RX pattern increments by 1,2,3 on each byte and you can check that in RxEnd to find errors.
At somewhere around 3MBd (3.0769?) the extra add and djnz would pack into the time budgets, to allow up to 85 * 3 = 255 byte packed blocks of rolling test patterns, for full array-flow testing.
You can also use a fixed (not changing) pattern using NCO out , workable for 1 stop bit (10bT) and 3 stop bit (12bT), but 2 stop bits(11bT) places the level change in mid bit, ie the wrong place.
2 Stop bit Sw flows could be tested in 7b or 9b settings.
Also, a Fo value of close to 17.0 bit times, can be used to confirm Rx sample-position.
ie sweep the Fo and look for Rx changes from 00H to 80H, this moves the edge in fSys increments, and ideal sample time is 17.0 bit times.
You seem to have this all mapped out in your head already... any chance I can persuade you to get it written? I've got a half-way decent unit testing environment in PropWare all ready for you
The next commit is going to be huge.. but hopefully clear up a lot of bugs and simplify the code significantly through heavy refactoring.
Installation has been completely revamped. No more custom Python script! This is mostly good news, but a few small drawbacks.
Installation instructions have been updated.
PropGCC no longer comes with. You're on your own for that.PROPGCC_PREFIX environment variable is no longer set for you.
If you already have PropWare installed, you will want to remove the PROPWARE_PATH environment variable. It is no longer needed but can be used to override the default search path.
WindowsWindows now has a simple .exe installer - just double click and press "next" until it's done. As detailed in the instructions linked above, you'll need to modify the PATH variable when running from the command line.
Linux.deb and .rpm packages are now provided for Linux installations. Just use dpkg or rpm and you'll be good to go!
MacI'm working on it. Don't hold your breath though. Sorry
Zips are provided along with instructions on what to do. I'm afraid that's the best I can do.
WS2812It's here! A driver that shamelessly copies the core code from JohnnyMac's driver is implemented. It does not require a new cog - I believe this is a first for the Propeller - all other WS2812 objects that I've seen require a dedicated cog to run fast enough. As with UART, PropWare::WS2812 takes advantage of PropGCC's FCache execute JohnnyMac's same assembly without requiring a new cog. Well done PropGCC team!
API docs available here.
Note that the WS2812 is only in the nightly branch at the moment. I'll push to release-2.0 within the next week or so.
Does PropWare have an I2C slave object?
Where do you think I learned how to write fcache code?
PropWare doesn't have any I2C object yet - master or slave. I personally am not fond of I2C so it's been very low on my priority list. Never even thought of a slave object though... interesting idea. It'd have to run painfully slowly - just like slave SPI. I suppose you could configure a specific frequency at runtime rather than paying attention to the SCLK line and then it would be no more difficult than UART. That would probably satisfy 95% of use cases.
Anyway, for my sailboat project I'm using an Arduino to read PWM inputs. The master controller then queries over I2C for the data. I'd like to replace the Arduino with a Propeller, but I'd need a slave I2C object to have it drop in. But that's waiting until I get around to writing the object.
For an I2C slave you don't set or do anything with the clock line: you're expected to be ready to respond at any time. And there's no reason it couldn't run at the standard I2C fast speed (400KHz clock): it's not all that fast from what I remember on the I2C master code.
* It's not challenging in the "unsolved problem" sense, but challenging in the "takes time to do" sense.
I post this in the PropWare thread because it is the first public project that I'm aware of which actually uses PropWare. If you know of others, please share the link.
But... I'm getting bored with all those bugs, so I'm going to start something that I've wanted to do for a very long time. I'm going to create a web service that compiles PropWare applications written in the browser! I'll have a service listening on my server, http://david.zemon.name/, which will accept project files to be compiled via a PropWare build system. When you click build, your project will be send over, the service will build your binary and then return you a binary (or inform you of any errors).
For those familiar with mbed - that's where I'm drawing inspiration.
I'll start a new thread for this once I have a prototype functioning
With the necessary work complete on the filesystem logic, I am ready to call this "release candidate 1". Before release, I will be creating an easy-install Windows package which includes a PropGCC release as well as the necessary changes to the PATH environment variable.
Please give this latest release a try and let me know if you run into issues.
The following is taken from the README in the FileWriter example project.
The loop is pretty simple. For PropWare:
while (!reader.eof()) writer.put_char(reader.get_char());And Simple:
int c; while (EOF != (c = fgetc(reader))) fputc((char) c, writer);That's almost 3x faster in CMM and 9x faster in LMM! I'm content!
And I finally have ideas for supporting other types of Spin via PropWare, so look for that soon.
And those numbers are after I've spent the last many nights doing nothing but adding documentation.
Alas, this is going to take longer than I thought.
Cool news though is that I learned about all the different graphs doxygen & graphviz are capable of producing, so the PropWare API docs have lots of pretty pictures now!
Documentation is my key concern at the moment as I try to get a final v2.0 release out. I will be continuing to work very hard on both API docs as well as installation, getting started and example instructions. I'm also working to create formal guidelines for contributing code to PropWare, since I would like to post more requests to the community for peripheral submissions.
An alpha VGA object has been created, but yet to be tested by anyone (I don't have VGA hardware yet). See this open issue.
I also created a very simple WatchDog object which will perform a hard reset of the chip if not fed in a timely fashion.
plate<class T> static int8_t invoke (T &runnable) { static_assert(std::is_base_of<Runnable, T>::value, "Only PropWare::Runnable and its children can be invoked"); #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wpmf-conversions" return (int8_t) _start_cog_thread(runnable.get_stack_top(), (void (*) (void *)) &T::run, (void *) &runnable, &runnable.m_threadData); #pragma GCC diagnostic pop }I don't think there is any way to get around that though. Perhaps when release 2.0 for PropWare is complete, I'll work on the warnings coming out of Simple and libpropeller too.
This week I've removed all traces of Python from PropWare. It served its purpose well while I was using it, but I've learned how to force git and CMake to do everything I was previously doing with Python.... and it's now done with fewer lines of code and results in a cleaner workspace. The change was rather drastic though, so if anyone experiences issues with missing symbols in libraries or missing headers, please let me know so I can get them added in.
Another benefit is that PropWare now downloads the Learn folder straight from git, instead of relying on a zip to be published to Parallax's website. This is a big bonus for me because those zips were published to Dropbox, which is blocked by my company's firewall.
Good news! You may want to mention in the ReadMe that git users should use "git clone --recursive https://github.com/DavidZemon/PropWare.git" to get all of PropWare, libpropeller & the Learn folder content with a single command.
dgately