Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.
No idea, my Rigol is the cheaper DS1052E - no logic facilities.
I do have a very cheap USB logic analyser though, which I'm going to have to dig out and figure out how to use, as I'm still having TFT 'problems'. It's rather strange, I have a couple of ST7735 based TFT's, one is 128x128 (and is shown working from a 24F in the video I posted), the other is 128x160. The setup's for the two displays are slightly different, but if I setup an Arduino Mini Pro for either, I can plug either display in and I get 'some sort' of display, it might be the wrong size or off centred, but it works. With the PIC version only the 128x128 display works, even if I do the 128x160 setup (but obviously wrong size wrong colours etc.) - all I ever get on the 128x160 display on the PIC is a blank white screen.
So I'm a bit bemused, I've even gone to a lot of trouble to try and make the graphics and setup routines as identical as possible - I'm hoping that comparing PIC to Arduino with the analyser might show me the problem?.
I have decided not to use the 2x16 blue display, and use a I2C Back_pack slave ( My home brew PIC16F1827 ) , can take most character LCD's, so having to modify old master code from PIC24 progs. So my next post on K42 may be a while ...
I noticed Microchip told me how bad my code was and suggest I send them some of my pension , to make it run better...
Shame they don't do a "hobbiest" or "Mature student" MPLABX, XC8 version ....
If you actually google about it, in free mode their compilers deliberately add load's of totally spurious code in order to make the code run slowly, and take up much more space than actually required. A simple loop checking an I/O pin runs so slowly as to make it impossible to read IR remote signals as my assembler tutorials do. But even at that, my XC16 TFT graphics demo on a 24F runs considerably faster than the Arduino version (which is a much lower spec processor).
The MPLABX IDE also runs very slowly, it takes forever to compile XC16 programs, although XC8 ones are a little faster.
I was having speed problems with the Arduino IDE, which I cured by adding various directories to be skipped by my anti-virus, and that helped massively - it compiles quite quickly now.
Hi Nigel, I don't recall any compile speed problems with XC16 , but my stuff was not that big ... ,What PIC24 are you using... as I said X seems to run better on linux.mint , screens not a good as windows , perhaps i need a different GUI scheme. any way to take out the MC filler ?
Just spent a few days creating a 12c state engine 18f25k42 (would suit all K42 microcontrollers).
The library provides an ISR to implement of am state I2C hardware slave for these microcontrollers.
This is a Great Cow BASIC implementation of Microchip Application Note AN734 and TB3159 but this is easily, very easily, portable... now I have got it working.
The library and the demonstration responds to a write and reads of bytes to I2C address (the four K42 addresses are supported).
According to AN734, there are 5 possible I2C states, however there is an additional state that is required when AN734 is implemented in anger.
During defined ISR, each 'of these states are detected. The ISR provides a standard skeleton to implement an I2C hardware slaves, while client code must implement several callbacks the ISR is expecting to call while processing states.
HI2C_Process_In_Message ( in HI2CMESSAGESIZE as byte ) called when slave has recieved a complete I2C write packet
HI2C_Process_Out_Message called when slave is requested to respond to a masters request, the slave needs to send an I2C packet.
In my test code I have a Pot attached and 4 LEDS. The Master will request the value of the Pot and then, the Master will set 3 LEDs to the proportional value of the Pot - and, the Master will set the LEDS to the same value - these LEDs are attached the Master microcontroller.
The test code supports two transactions but this can be easily expanded to support 100s of transaction types.
Transaction #1. Master send I2C packet to address, address, value. as follows to set the LEDs:
0x70, 0x23, 0x00 - turn off all the LEDS
0x70, 0x23, 0x01 - turn on one LED
0x70, 0x23, 0x02 - turn on one LED
0x70, 0x23, 0x03 - turn on two LEDs
0x70, 0x23, 0x04..0xff - turn on LEDs
Transaction #2. Master wants to read the value of the ADC
0x70, 0x81, 0x04, 0x71, 0xNN. Where 0x81 will instruct this slave to read the ADC, where 0x04 equates to ADC4 and then the READ operation will return the single byte value of the Slave ADC to the Master. Any other ADC port request will be returned as 0x00.
To add your own slave commands - simply expand these the example methods.
AN734 is a very useful architecture of how to create a state engine.
TB3159 is useful but pointless. TB3159 contains three serious errors but at least you can get the microntroller to respond to I2C discovery.
The Great Cow BASIC library, which is based upon the 'Legacy I2C module', shows a reference solution that uses AN734 and completes the approach provided in TB3159.