The xCORE-USB sliceKITxCORE-USB sliceKIT contains everything you need to start developing USB applications on xCORE multicore microcontrollers. The xCORE-USB sliceKITxCORE-USB sliceKIT features our 16 core High Speed USB device which delivers the deterministic, responsive processing required to handle a variety of peripheral interfaces, data processing and control tasks.
The kit includes the USB sliceCARD with USB A and USB B connectors which works with xCORE-USB integrated High Speed USB 2.0 PHY. Our sliceKIT product range includes a wide variety of other slice I/O cards, making it easy to rapidly develop systems.
Kit Contents
Core board with 16 core xCORE-USB multicore microcontroller
USB A/B sliceCARD
Mixed Signal sliceCARD
xTAG-2 debug adaptor
Power supply
Product Video
You don't have permission to edit metadata of this video.
Testers will be selected on the basis of quality of applications: we expect a full and complete description of why you want to test this particular product.
Testers are required to produce a full, comprehensive and well thought out review within 2 months of receipt of the product.
Failure to provide this review within the above timescale will result in the enrolee being excluded from future RoadTests.
Thanks for the comment. I have had a really bad time with interfaces trying to add an extra interface to the AVB-DC application in an effort to pass data to the SPI task with in the MODULE_FLASH code. I kept getting a ton of errors about guarded statements until finally I chose to stick my added application code on the same core as the Module_flash code.
I have found the forums are some what helpful and standard peripheral stuff is pretty easy to get going but trying to modify large applications that have library dependents is a pain in the A%$. We are really concerned with choosing this platform for our project with little to no formal training available through XMOS. Whats worse is they don't seem to have a plan in place to do so.
I sat for about three days trying to mimic the interface example code with two tasks (clients) talking to a single server. I was unsuccessful as I stated above.
Have yo had a different experience with XMOS support?
Thanks for the comment. I have had a really bad time with interfaces trying to add an extra interface to the AVB-DC application in an effort to pass data to the SPI task with in the MODULE_FLASH code. I kept getting a ton of errors about guarded statements until finally I chose to stick my added application code on the same core as the Module_flash code.
I have found the forums are some what helpful and standard peripheral stuff is pretty easy to get going but trying to modify large applications that have library dependents is a pain in the A%$. We are really concerned with choosing this platform for our project with little to no formal training available through XMOS. Whats worse is they don't seem to have a plan in place to do so.
I sat for about three days trying to mimic the interface example code with two tasks (clients) talking to a single server. I was unsuccessful as I stated above.
Have yo had a different experience with XMOS support?
I have seen errors concerning lack of guarded statements before, and usually that occurs if an interface has been defined with functions that are not used in the select statement. When that occurs, I put a "case xyz():" and "break;" statements into the select portion of code, just as a stub until I get round to adding more code. Also, I've not currently encountered a situation where I will need to filter out events (I am sure it will happen to me eventually) so I've not used [[guarded]] so far as mentioned.
For training, it is worth checking with XMOS in case they are aware of any - not saying any training will be free or not (I have no idea) but perhaps they know of instructors who run courses from time to time. So far I have just relied on documentation, so probably I'm underusing bits of functionality.
The single best piece of advice I have, is that it is worth drawing out and defining your interfaces on a diagram with all the tasks you plan to use. I don't know what the diagram is called, but it is a typical message sequence type diagram I suspect. I used that method in three XMOS posts, click here for the link to the first post. The diagram was used in parts 2 and 3.
I would say stick with it, because it solves some problems that ordinarily might need dedicated hardware in a CPLD or FPGA, and those are not straightforward to use either, so this provides a good blend of features with C programming and the handful of extensions.
Top Comments
I have been working with the XMOS General Purpose Slice Kit for a couple months now. There is a learning curve involved due to the "xc" language extensions and the hybrid architecture XMOS uses. I spent…
Hi Linas,
The clock is 500MHz, and there is a pipeline type structure (in this case 4 stages), meaning that the throughput will vary (e.g. due to pipeline stalls or intentionally due to instructions or…
When you write question, you should supply all information.
FFT from 500Hz samplig can teke anywhere from 1ns to 10 years, question is sample size, or resolution of your FFT in Hz
With STM32F407 i was able…