Search

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.

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?.

Active Member

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.

Active Member

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 ?

Well-Known Member

Member

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.

Callbacks:
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.

Findings

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.

Active Member

Your welcome... different LCD same method I presume ... I don't profess to be a programmer . far from it . but i just keep 'typing' till i get a result , the K42 is supposed to be more efficient with I2C , no waiting for the slave ACKSTAT.. but I moved on after the RTC chip to some dsPIC33 ... lots of peripherals, and memory and 70MIPS ..

New Member

After several evenings of butting my head against this new way of handling i2c I've now come to the state that I'd like to Shamefully come back here and request some help in converting this attached code into the F24K42 (similar enough to the F25K42). I've been digging in datasheets for well over 16 hours now and I can't say I'm getting any closer to figuring out this new code.

My old code was admittedly initially handed to me by a teacher at the university where I studied. I've modified it quite a bit since,, with bits of code from here and there and quite a bit of my own.

But now I've come to a brick wall in my conversion attempts cause its just so different, everything is differently named and split up in several sub-bits doing different things.

Since you people in this thread seems to have quite a bit of experience with both the new and the old ways, I'd be Very happy to get some help in this conversion process.

I've inlined most, if not all, of my defines to make it easier to follow. It should be a pretty rudimentary I2C code with not much in terms of safety, but it works for me.

//Kind regards, Roze.

Attachments

Active Member

Hi Roze .. I have not done any slave code for K42, and My C is 'amateur' . I did a slave I2C for PIC18F14k22 but steered clear of using an interrupt. so cannot compare.. perhaps explain what is the problem with your code ?.. are you using actual hardware ? ..what is the master PIC ?

Edit, I was incorrect.. I did implement a ISR for I2C slave.. (14K22) ..it was a back-pack for LCD ... seems rather simple ! I have 8 buffers to simplify decoding

New Member

The Master is not a PIC at all, its a HLK-RM04 SoC.
I've now made an yet another attempt to fix my code. This time compile at least goes through. Will try to test it tomorrow.
My issue is that everything changed to interrupts