BPv4
LOGIC SHRIMP
LCD BACK PACK
IR TOY
OLS
ECHO TEST SAMPLE (For BPv4 and IR TOY)
http://http://www.newfoundelectronics.com/JTR_DP_usbstack_projects.zip
Pretty much this is getting to be the final work on the current generation USB stack and the DP hardware. At least for the time being... While the usb stack is not the latest I have it is the best trade-off between many competing issues and at a level that is fully understood should I need to revisit it. Some hardware got an improved stack and some got rolled back a level so that it was all compatible and modular.
Because of on going problems with MPLAB X that I an working with the microchip dev tool team to sort out, mostly these projects are MPLAB 8.xx based. MPLAB X is fine for all the PIC18 projects but it tends to not want to load the BPv4 firmware.
Keep in mind that I have not fully tested all the projects as such, rather only the usb stack and the general workings of the cdc API.
The USB stack is organized like this.
[project folder]
[usb stack folder]
The project folder requires these files that are referenced by the usb stack:
prj_usb_config.h (replaces cdc_config.h)
descriptors.h (For the most it is the same file for all projects with only the strings changed. However this could need to be changed at anytime so I did it this way for forward compatibility.)
The project needs to be built with these files:
usb_stack.c
cdc.c
The usb stack header files need to be included in each and any module that uses the usb stack.
#include "..dp_usbusb_stack_globals.h" // USB stack only defines Not function related.
main.c (only!) needs to include the configwords and the descriptor header:
#include "descriptors.h" // JTR Only included in main.c
#include "configwords.h" // JTR only included in main.c
For the PIC18F14K50 the cdc bulk endpoint size specified in prj_usb_config.h needs to be set to 32 as there is not enough usb ram for the cdc double buffering otherwise.
Both the paths for the project and the usb stack need to be included in MPLAB's search path at least for C30 projects. C18 seems to work without them though.
project -> built options -> project -> directories -> show directories for -> include search path
Add:
..dp_usb
.
With this stack I have (hopefully) completely separated the stack and the project that uses it.
PLEASE! DO NOT break this by putting project items in headers or source files belonging to the usb stack like I/We did in the past. usb_stack_globals.h is for the usb stack. I suggest the use of prj_globals.h for items belonging to the application.
I also got rid of the requirement to include files from the microchip MAL. No more generictypedefs.h, compiler.h etc. There was not much point in moving away from the microchip usb stack if we where still using files from the MAL.
While, of course, there will be a requirement to change the directory structure between projects and the usb stack for the purposes of packaging complete projects I "suggest" for the time being that any work done on the project is done in the current structure as in my zip file at least until it is debugged and ready for release. I do not wish to have any more copies of the usb stack on my harddrive and I will not touch anything that has absolute paths...
OK, now it is over to all of you to finalize this work and get all these projects finished with the new open source stack. Let me know if you find any issues.
JTR
P.S. Happy Australia Day!
Really nice work JTR! I've done some development with the Microchip USB stack myself, so I understand the level of complexity you were dealing with. I really hope this project will become THE open source alternative to the Microchip stack that the community has so long been waiting for.
Personally, I don't have the time to help you with the development, but next time I need USB in some project I'll try your stack first. It's up to the people of DP now to make this a mature stack!
Maybe we could ask/propose Microchip to put some development effort into this stack, so they could offer it as their default USB stack. I've heard they were unhappy with the current licensing issues of their current stack, so they might be very interested...
Happy Australia Day to you too!
Thanks JTR, this is great. It even includes Sjaak's echo demo.
Can I get rid of cdcconfig.h in /dp-usb/? It looks to be set in proj_usb_config.h.
Here's my plan:
1. Get some documentation in order
2. Release it on BPv4 and IR TOy as a test
3. If all is good, release updates for the rest.
The problem with the BPv4 and MPLAB X has been solved! There is a bug in MPLAB X and C30 interaction that causes it to fall over when an identifier has the underscore internally prefixed making it the same name as a reserved keyword. In out case it is the "stack" variable in basic.c. Changing this to "stack_" has solved the problem. Thanks to the microchip Dev Tool Team for their hard work in tracking down this problem.
wartos, Thanks for your words of encouragement. However this stack is still a long way of replacing the microchip stack. Until it supports the hardware pingpong mode it will not work with the PIC24E, dsPIC33E or the PIC32MX families. Currently it is only a CDC stack and works in device mode only. Anyone looking to get under the hood with it and add new classes etc _should_ discover that right from the word go it cheated on some details... However for the current requirements of DP it is a good usb stack.
[quote author="ian"]Happy Australia Day to you too!
Thanks JTR, this is great. It even includes Sjaak's echo demo.
Can I get rid of cdcconfig.h in /dp-usb/? It looks to be set in proj_usb_config.h.
Here's my plan:
1. Get some documentation in order
2. Release it on BPv4 and IR TOy as a test
3. If all is good, release updates for the rest.[/quote]
Yes, cdc_config.h is fully depreciated and can be deleted. Also usb_lang.h is not needed as the defines are in usb_stack.h.
I have also done an MPLAB X project for the BPv4 and this a long with the changes above are in a new zip file at the same link.
I agree that the main effort should be on the bus pirate. All the others are straight forward and need little work and testing. The BPv4 is a major, major piece of work though and requires many people to look at their modules and test them. Getting the bus pirate firmware to be compatible with V3 and V4 really is not a trivial matter.
I started some documentation, I need to dig up my older echo demo that uses double buffer mode too.
http://dangerousprototypes.com/docs/Ope ... ontrollers (http://dangerousprototypes.com/docs/Open_source_USB_stack_for_PIC_microcontrollers)
We'll post this up and try to get some more developers involved.
[quote author="ian"]Happy Australia Day to you too!
Thanks JTR, this is great. It even includes Sjaak's echo demo.
Can I get rid of cdcconfig.h in /dp-usb/? It looks to be set in proj_usb_config.h.
Here's my plan:
1. Get some documentation in order
2. Release it on BPv4 and IR TOy as a test
3. If all is good, release updates for the rest.[/quote]
Yes, cdc_config.h is fully depreciated and can be deleted. Also usb_lang.h is not needed as the defines are in usb_stack.h.
I have also done an MPLAB X project for the BPv4 and this a long with the changes above are in a new zip file at the same link. The documentation page needs to be edited as this issue is fixed.
I agree that the main effort should be on the bus pirate. All the others are straight forward and need little work and testing. The BPv4 is a major, major piece of work though and requires many people to look at their modules and test them. Getting the bus pirate firmware to be compatible with V3 and V4 really is not a trivial matter.
I started some documentation, I need to dig up my older echo demo that uses double buffer mode too.
The new stack only uses double buffer mode. There is no single buffer mode available and the code to arm the double buffer mode is now in user_configure_init() and the disarm code has been deleted. It is too much trouble to maintain both and it was in between the switching of modes that the strange ZLP after 48 bytes error occurred on the IR TOY. Writing a stack to work on one family of pics difficult enough, to work on several harder, to work with polling or interrupts on root hardware and hubs with windows XP, windows 7, linux and mac is really trying when all the oddities are added in. Trying to get it all to work with both double and single buffered modes is just another potential failure point and for what gain?
Something else to add to the documentation is the interrupt Vs polling method.
The stack is totally agnostic to either mode. It does not either enable or disable the global usb interrupt. if Interrupts are to be used they need to be enabled in the user application. If interrupts are enabled then no further polling of the usb stack is required. However as a result of enabling interrupts the timing of user applications is no longer fully determinable. This is the price you pay for interrupts. Personally, I recommend against using interrupts on the BPv4 and the IR TOY because of this.
If interrupts are not enabled then the stack needs to be called regularly to have at least a one to one relationship with the number of transactions including the sending of set up packets and status bytes. The cdc stack will itself call the usb handler each time a packet is sent or received over cdc if the stack has been compiled with label USB_INTERRUPTS NOT defined. There is no runtime checking on whether interrupts are enabled or not in code. It is a compile time choice.
If interrupts are enabled the the label USB_INTERRUPTS should be defined in the "prj_usb_config.h" file so the the cdc.c module compiles correctly.
Where can i download the sources?The link in the first post is broke.
[quote author="exapod"]Where can i download the sources?The link in the first post is broke.[/quote]
Sorry! Problem with the underscores. Link fixed.
Thank you.
Thank you, this is great!
I am working with this version to port the USB Backpack to the 18F24J50. I noticed that WaitOutReady() does not call usb_handler() so if you aren't using interrupts it does not work. Is that intended? Are interrupts required in this version?
Thanks
[quote author="dolabra"]Thank you, this is great!
I am working with this version to port the USB Backpack to the 18F24J50. I noticed that WaitOutReady() does not call usb_handler() so if you aren't using interrupts it does not work. Is that intended? Are interrupts required in this version?
Thanks[/quote]
While leaving out the calls was intentional it was not intentional to make the stack require interrupts to work. Rather it is a case of the "theory" and "practice" not quite being the same. Read on...
While the theory of the stack operation says that calls to WaitOutReady() should not require a call to the main usb stack, and in most cases it works without them (when the WaitOutReady() and WaitInReady() functions are used correctly) in practice we may need to add the calls to the main usb stack back into these functions. I found this when I ported the cdc stack into assembler and put it on one of my old projects that is heading for a relaunch. What I ended up with that was the best compromise is this.
WaitOutReady
btfss BD1OST, UOWN, BANKED
return
BTFSC PIE2, 5, ACCESS
BRA WaitOutReady
CALL ServiceUSB
BRA WaitOutReady
WaitOutReady
btfss BD1OST, UOWN, BANKED
return
BTFSC PIE2, 5, ACCESS
BRA WaitOutReady
CALL ServiceUSB
BRA WaitOutReady
As you can see the usb stack is only called if the endpoint is not ready. This system has two functions. Firstly it will only call the usb when it was going to be waiting anyway and does not produce much (if any) latency and secondly, it clears the FIFO in case it was full due to the user app not calling the usb stack often enough. I found that because the FIFO is only 4 deep on the PIC18 there is just not enough headroom to cover for unexpected transfers and the time away from the main user loop.
The higher level cdc functions (putc_cdc and getc_cdc etc.) (only) call the usb stack on a one to one basis, after a packet transfer (including any ZLP) This is just enough for our normal cdc bulk endpoint operation and the reason why the usb stack is not needed (for the cdc bulk transfers) to be called anytime from WaitOutReady() or WaitInReady() when the endpoint is available.
On a related note, another very important consideration is that the usb stack needs to be called 10-12 times for the CDC CLASS handler immediately after it has entered the CONFIGURED STATE. Therefore use of any blocking function must be avoided. I really do not like the idea that the CDC CLASS requests being handled outside the main loop but I cannot control the entire use / misuse of the stack. While the user code should imho use calls to getInReady() and getOutReady() and behave in a non blocking manner, if such is not the case then the calls to the usb stack in WaitOutReady() and WaitInReady() will cover the cdc class setup and the occasional unpredicable set-up request per chance the main user loop is not servicing them fully.
In summary WaitOutReady() and WaitInReady() are not really indented for general use but even if they are only used under known conditions by the higher level layers of the cdc stack it is just to marginal all things considered to not call the usb stack at least when the endpoint is not ready. This is what I found in practice and the above system when added to my assembler version proved to work very well. I have no problem with, and recommend that such is also added to the DP open source stack**. It was a mistake on my part to leave them out even if I had "theory" on my side and knew how to trim it all to get it to work case by case. It is just to fragile.
**Note, the DP usb stack chooses between interrupt mode and polled mode at compile time so the changes need to be conditional compile directives and not runtime interrupt flag testing like I use on my assembler stack.
Make the changes and see how it goes and rack it up as a good catch.
Thanks for the very complete explanation --- my real issue is the one of blocking calls right after initialization. What I was attempting to do was to block and wait for command , but when I did that the CDC class was not working properly. With a lot of trial and error I found that it was the lack of calls to the stack that was causing the problem. Ultimatly, I really want to read from the USB or the serial port, so I'll need to be non-blocking anyway, so I think I'll just go that way.
Thanks.
I'm just curious? What is the plan with the stack? Will this version be integrated in the the svn?
I certainly like this version better it is a little easier to understand and the getc_cdc functions are quite handy.
Hi,
is somebody here, who is able to use it with PIC18F14K50? I was spent few days with it and still not working :o(
I wish I could help. I don't have any experience with the 14k50 and only a tiny bit of experience with USB.
One thing came to mind. Make sure you are using an appropriate linker file. The USB data locations need to be specified correctly for the the part.
Yes, it look like good idea.
With MCC18 default one (18f14k50_g.lkr) I'm able to compile, but not running, with project one (18f14k50-usb.lkr) I can not compile:
MPLINK 4.40, Linker
Device Database Version 1.3
Copyright (c) 1998-2011 Microchip Technology Inc.
Error - section 'usb_data3' can not fit the section. Section 'usb_data3' length=0x00000100
Errors : 1
yeah, check the data sheet for locations. Figure 22-4 should help.
I don't see a 14k50 file in svn?
This one: http://code.google.com/p/dangerous-prot ... .lkr?r=821 (http://code.google.com/p/dangerous-prototypes-open-hardware/source/browse/trunk/Honken_USB_Stack/18f14k50-usb.lkr?r=821)
Sorry for that - I'm newbie in using C with microcontrolers, so that this linker alocations is chaotic for me
on figure 22-4 I see, that I have 0x100 bytes for usb ram, it is what linket also informing me. The problem is, I'm not sure, where is the over limit.
OK, 50% understand - 18F2550 have USB data from $500-$7FF, you are using it for cdc_acm_in_buffer, cdc_In_bufferA, cdc_In_bufferB, cdc_Out_bufferA and cdc_Out_bufferB. 18F14K50 have USB data $280-$2FF, then I should decrease buffer sizes. Will try it.
Now it look like I'm able to run it on pic18F14k50
I have changed in cdc.c buffers like this:
#ifdef __18F14K50 //JFU
#pragma udata usb_data
BYTE cdc_acm_in_buffer[CDC_NOTICE_BUFFER_SIZE]; //JTR NEWLY defined NOTICE BUFFER SIZE and increased from 8 to 10 bytes in usb_config.h
// #pragma udata usb_data3
BYTE cdc_In_bufferA[16];
BYTE cdc_In_bufferB[16];
BYTE cdc_Out_bufferA[16];
BYTE cdc_Out_bufferB[16];
#else
#pragma udata usb_data
BYTE cdc_acm_in_buffer[CDC_NOTICE_BUFFER_SIZE]; //JTR NEWLY defined NOTICE BUFFER SIZE and increased from 8 to 10 bytes in usb_config.h
#pragma udata usb_data3
BYTE cdc_In_bufferA[64];
BYTE cdc_In_bufferB[64];
BYTE cdc_Out_bufferA[64];
BYTE cdc_Out_bufferB[64];
#endif
Great!
I'm not an expert, but do you have to (did you?) also change the CDC_BUFFER_SIZE?
#define CDC_BUFFER_SIZE 64u in the usb_config.h (or something like that)
I wonder why that #define was not used to allocate the buffers?
That is a good question why it is not used in def.
second question is, how it is possible, that it works before I changed it in prj_usb_config.h
#ifdef __18F14K50 //JFU
#define CDC_BUFFER_SIZE 16u
#else
#define CDC_BUFFER_SIZE 64u
#endif
are you running the echo demo? if that is the case, I think the buffer only ever contains 1 byte, so there isn't any overrun of the buffer.
A new version has been posted at the same link in the first post. Not much has changed, just a bug fix to stop the request for string descriptors being incorrectly stalled. There is a slight reworking of the interrupt macros to depreciate the priority mode of the PIC18. This is an application level choice and not for the usb stack to enforce. As this has not been used in any project it is moot.
Also added is a echo test for the 18F14K50 and a few changes to the code that only result in changes to the compiled hex file when the 14K50 is used.
Hi JTR,
some mistake? link (http://http://www.newfoundelectronics.com/JTR_DP_usbstack_projects.zip) not wirking :(
[quote author="fulda"]Hi JTR,
some mistake? link (http://http://www.newfoundelectronics.com/JTR_DP_usbstack_projects.zip) not wirking :([/quote]
"He who forgets the past is doomed to repeat it." :(
Guess I forgot the past and didn't replace the spaces with underscores (again!)
Fixed now. Sorry about that.
[quote author="JTR"][quote author="fulda"]Hi JTR,
some mistake? link (http://http://www.newfoundelectronics.com/JTR_DP_usbstack_projects.zip) not wirking :([/quote]
"He who forgets the past is doomed to repeat it." :(
Guess I forgot the past and didn't replace the spaces with underscores (again!)
Fixed now. Sorry about that.[/quote]
underscores is definitely better than repeating other history:)
Hello JTR,
I have used your package and built successfully the BPv4 (no compile nor linking error).
But after loading it in the bus pirate v4 and starting it, it is not recognized correctly by the PC. It also does not ask for a new driver.
Also we have all BPv4 leds on which does not look normal compared with the standard 6.1 release.
In fact i wanted to build a release which includes XSVF Player and wanted to use your last release as i had problems with the 6.1 legacy + jtag : the chain scan provides the good result but it detects an error ("Error sending data") while trying to transfert the first 4096 data block. I tried to reduce the buffer size without success and it seems no byte is transfered. Then i was suspecting the BPv4 firmware side and decided to try with your last release usb stack.
Best Regards
JM
Hello JTR,
I have found the problem i reported in my previous post regarding the current BPv4 integration of XSVF Player in official 6.1 release.
In fact, in xsvf, they made a first test of U1STAbits.URXDA and when true, they call UART1RX().
The problem was due to the direct call to the physical UART1 URXDA flag which is no longer significant when using the USB UART emulation. As a test via UART1RXRdy() (which is compatible with usb emulation) is also done within the UART1RX(), then i just removed the first test to URXDA.
Then as i had problems with your BP4 release, i have integrated JTAG within the official 6.1 release.
Best Regards
JM