The BP6.3 -> AVRDUDE code needs to be patched for the BPv4. Cut and paste this over the same section in spi.c and see how it goes. If it works then push it to the SVN else disregard.
Remember the original IR TOY SUMP mode? 4096 BIT samples @ 10kHz. It only sampled the demux IR (from TSOP38438) and not the RAW IR signal (from the QSE159).
This is a screen shot of the the latest somewhat upgraded IR TOY SUMP mode working fantastically well with Jawi's OLS client.
This is effectively V2 of the JTR-SUMP mode and contains some bug fixes, greater bandwidth and quadruple buffering to smooth out the variable USB latency. Gone are the occasional artifacts from the previous version. This one is smooth.
Shown is all of PORTB that includes the RAW and DEMUXed IR streams. (The DEMUXed is on two channels). The sample rate here is 240kHz * 8-bits. That is sort of maxed out. I may be able to get 250kHz or a bit more, just haven't tried it yet and probably will just leave it @ 240kHz. Also note the the firmware has inverted the outputs of both IR detectors.
That leaves 5-bits of PORTB that can be used as a low speed analyzer for other purposes. Any of the PORTB IOC pins can be used to trigger the start of sampling or you can writer your own code.
The waveforms shown are from a NEC IR remote and @ 38.4kHz. Of course we are going to get a little aliasing but the RAW IR shown contains the useful information - 22 pulses per ON time at about 40% duty cycle.
You can also see the real time lag of the DEMUX receiver. I will point something interesting out about this in the new firmware's documentation.
Now that I have this working so well with the PIC18 on the IR TOY, I will port it to the Bus Pirate and perhaps get 1MBs sampling rate. Doesn't exactly replace the OBLS but for reduced requirements and greater samples (potentially limited only by your hard disk) it is not a bad bonus feature, especially considering the price. :)
Sorry I am not sure how to compile for other OSes.
The updated source code will be part of a complete new IR TOY release soonish. Let me know if you need the beta source to compile for Linux etc in the meantime.
Is anyone having any success with irrecord and the IR TOY? I have tried with the latest irrecord and various IR TOY firmwares and it almost always gives a "something went wrong" message when I try to record the actual keys. Occasionally it does receive a key on a retry.
Up until that point it works correctly. I have used the -f option and that did not help.
I have everything working on the new IR TOY firmware and this is the only thing that is not working correctly. All my other tests show that the firmware is working correctly and in any case the same issue is happening with V22 firmware.
There is no problem using irgraph or rec and play or anything untoward visible with terminal software. It is just irrecord so I am wondering has anyone got this to work (on windows) or is there a problem with irrecord itself?
Edit: This was with the official IRTOY DLL and not with my modified DLL.
395 // put back into sampling mode 396 // 397 temp[0] = 's'; 398 serial.Write(temp,1); 399 Sleep(50);
These three lines should not be there. The IR TOY is already in irS mode so the 's' does not need to be sent. If it did then winlirc would then have to read the response "SO1" from the serial port. It does not do this. If it did then it would fail with the older firmware, if it does not then the "S" becomes the first "send packet size" token.
In any case if it were required and actually did re-enter the irS mode then the new settings that have just been sent to the IR TOY would be clobbered and the defaults restored.
I have managed to recompile the IR TOY DLL and it *seems" to me to be working but to recompile I had to change the #include "afxres.h" to windows.h and add another define for something that was missing (I think this is a VS++ 2010 problem but I am not sure...). I would rather have someone who really knows what they are doing fix this and recompile just in case there is a problem with what I did that still lurks unseen.
Jawi, The new client looks really good and has some nice features added. I gave it a try out and found that the device.samples.reverseOrder mode option for the IR TOY does not work any more. The client always shows the output in reverse mode regardless of the setting. Somewhere between ols-0.9.5-b2 and ols-0.9.6-b3 this feature got broken.
(It appears to be broken on the logic shrimp too...)
Also noted that the comment in the cfg file is still opposite to the function.
Finally, did you ever implement the infinite samples mode that was floated quite some time ago now?
Anyway apart from the above it worked well with the latest IR TOY firmware and I love that you got rid of the mouse movement screen artifacts.
Hot of the press microchip have more K series PIC18s with USB coming.
28-pin and 40/44-pin replacements for the 18Fx450 & 18Fx550 families.
Highlights: High performance PIC18 core with 8x8 Hardware Multiply Flash Program Memory with self read/write capability 256 Bytes of integrated EEPROM Internal 48MHz Oscillator with USB Accuracy -Via Active Clock Tuning from USB Host Universal Serial Bus 2.0 Module Enhanced Capture Compare PWM (ECCP) Module with up to 4 outputs Integrated Temperature Indicator Module Up to 25 Channel 10-bit ADC with Voltage Reference 2 Analog Comparators 5-bit Digital to Analog Converter (DAC) MI2C / SPI Module (MSSP) Enhanced Addressable USART Module Charge Time Measurement Unit (CTMU) for measurement applications 25mA Source/Sink current I/O 2x 8-bit Timers 2x 16-bit Timers Extended Watchdog Timer (WDT) Enhanced Power-On/Off-Reset Low-Power Brown-Out Reset (LPBOR) Programmable Brown-Out Reset (BOR) In Circuit Serial Programming and Debug (ICSP/ICD) PIC18LF2xK50 (1.8V – 3.6V) with nanoWatt XLP PIC18F2xK50 (1.8V – 5.5V)
Given that the K series are usually way less than half the cost of the standard legacy family it looks to me that we could have a much lower cost 5V IR TOY 3 someday.
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.
Attached is a zip file with the firmware for JTR's latest work on the BPv4. It is somewhere between V6.1 and V6.2 therefore I do not consider this an official release, just a work in progress looking for testers to thrash it around a little. Only the USB stack and the SUMP mode are in my keeping and that is what I want feedback on.
Basic change log, complete with oversights.
New USB stack with permanent, full duplex double buffered comms. UART1 baud rate set from PC. Recoded SUMP mode that is 100% protocol compatible with existing mode. Code has been highly refactored and is a joy to read and understand. Well, relatively so.... :) Trigger on port change enabled via client. Data sent first sample first. Up to 65535 samples. Should sample at a few hundred kHz, yet to be characterized. 8 channels with AUX1 moved to B7 in firmware. All digital I/Os on the BPv4 header are available.
The trigger on port change is enabled BUT at the last moment I realize that the actual mappings in the sump client may or may not be correct for the I/O pins. This is minor and you can find the triggers via trial and error if they are not where they should be.
Included in the zip file is the new BPv4 cfg file for the OLS client 0.9.5. Copy this into the plugin folder.
Also included is a screen shot showing a binary counter on the I/O. OK, I cheated, it is actually showing the buffer pointer but it was a good way to verify the USB stack and the SUMP mode liked each other.
Please post comments here so that I can track issues with either the SUMP mode firmware or the USB stack. Any other problems please refer elsewhere on the forum.
16F enhanced core with 48MHz internal oscillator and USB clock recovery. I take it this means that there will be no problem using the USB module at FULL SPEED with the internal oscillator. (Hopefully some other issues with the SIE will be addressed too otherwise the firmware stack just get to bloated...)
Enhanced Mid-range Core with 49 Instruction, 16 Stack Levels Flash Program Memory with self read/write capability Internal 48MHz Oscillator Universal Serial Bus 2.0 Module with clock recovery from USB host 2x Standalone PWM Modules Complementary Waveform Generator (CWG) Module Integrated Temperature Indicator Module 10 Channel 10-bit ADC with Voltage Reference 2 Analog Comparators 5-bit Digital to Analog Converter (DAC) MI2C / SPI Module Enhanced Addressable USART Module 25mA Source/Sink current I/O 2x 8-bit Timers (TMR0/TMR2) 1x 16-bit Timer (TMR1) Extended Watchdog Timer (WDT) Enhanced Power-On/Off-Reset Low-Power Brown-Out Reset (LPBOR) Programmable Brown-Out Reset (BOR) In Circuit Serial Programming (ICSP) Integrated In-Circuit Debug Circuit PIC16LF145x (1.8V – 3.6V) PIC16F145x (1.8V – 5.5V)
Really excited about these PICs. Already planning to port my assembler stack to them. :)
Attached is "tester" for the reworked IR TOY firmware. This version is hardcoded to just use the usb2uart mode without the requirement to enter it or without it returning a sign-on message. It really is just a USB2UART mode.
Fully double buffered and real time. Should easily support 1 Mbit/s transfers. Optional compile time enable/disable of CDC handshake signals DTR and RTS, both directly from host Supports polarity inversion of RX/TX and DTR, RTS handshake via pin strapping on RB3 and RB5 respectively. Added Auto flush on timeout. No "orphan" bytes. Auto ZLP handling for both IN and OUT transfers. Baud rate set by host via SET_LINECODING in cdc.c Works like a typical USB to RS232 chip except that some signals are not supported and there is no BREAK command.
USB2UART CUSTOM FIRMWARE INSTRUCTIONS
1) Installation
There are no specific installation procedures. The USB2UART mode uses the same VID/PID as the IR TOY and therefore the required drivers should already be installed.
2) Signals
By default the polarity of the TX and TX signals will be normal. To invert the logic of the TX and RX pull PORTB-RB3 LOW.
The same applies for the DTR and RTS signals. To invert pull PORTB RB5 LOW.
The polarity is set ONCE IMMEDIATELY AFTER A RESET.
The DTR signal is output on PORTA RA2
The RTS signal is output on PORTA RA1
Note: Due to a bug in the windows CDC driver the RTS signal is only updated when the DTR signal is also updated. This bug applies to all versions of windows but not to other O/S's
This firmware may or may not contain an easter egg.
