![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
dmitrboristuk
Joined: 26 Sep 2020 Posts: 51
|
HMI for read/write inbuilt EEPROM another PIC MCU |
Posted: Mon Nov 21, 2022 3:19 am |
|
|
Good afternoon!
Is it possible in principle to implement a certain device on the PIC controller (console) for reading, editing and writing to the EEPROM of another PIC controller. This is a kind of programmer that works without a PC, with which the read data can be presented in a convenient form (LCD 16x2), edited using incremental and decremental buttons, and then saved to the EEPROM of another PIC controller. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Mon Nov 21, 2022 3:26 am |
|
|
Yes, of course it is.
Design a protocol to talk between the chips. Some standard numeric code
to request a write or read with a packet following.
Then just have a chip with an LCD & keypad. Then a program to when you
select an address, issue a 'read', and display the byte returned. edit this
and offer a 'write' option, that then sends the new value.
This is basic programming. Just down to writing it. |
|
![](templates/subSilver/images/spacer.gif) |
dmitrboristuk
Joined: 26 Sep 2020 Posts: 51
|
|
Posted: Mon Nov 21, 2022 3:37 am |
|
|
Ttelmah
Thank you for your reply. I will explain in more detail, the controller external to the console device can be stopped at the time of its EEPROM configuration (this is even very desirable), that is, the console will essentially perform the functions of a programmer. Tell me where you can start and what documents you recommend for study. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Mon Nov 21, 2022 7:17 am |
|
|
hmm, when you say EEPROM, are you just reading/writing to 'data' EEPROM or do you mean the actual PROGRAM EEPROM ?
In the 1st case, you're changing simple 'data' that could be values used for calculations or maybe displayed 'names' on an LCD.
In the 2nd, you're changing the actual program that the PIC is running. This is really a 'bootloader' style program.
I would suggest that both PICs be of the same type. If mounted near each other, a simple TTL serial interface will work very well. If you can choose a PIC that has two hardware UARTs !
Also when writing to EEPROM,it's usually better to do a 'block' and not a single byte. This really depends on the PIC you choose as not all PICs are the same. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Mon Nov 21, 2022 8:37 am |
|
|
It sounds to me as if he wants to be taught how to actually program this.
In which case he needs to start learning to program!.
Some basic learning and experimentation. Learn how to program keyboards,
displays etc. etc..
All very basic. |
|
![](templates/subSilver/images/spacer.gif) |
dmitrboristuk
Joined: 26 Sep 2020 Posts: 51
|
|
Posted: Mon Nov 21, 2022 11:28 am |
|
|
temtronic
it is about EEPROM data (128 bytes)
It is assumed that the device being developed will read all 128 bytes from the external controller, present them on the screen in a readable form, the user will change them, and at the end of the work they will again be written to the EEPROM of the external controller.
Let me remind you that the EEPROM controller of which is being configured is stopped while the device is connected to it. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Mon Nov 21, 2022 12:04 pm |
|
|
OK, data EEPROM so you can easily use the CCS supplied functions to access the memory PROVIDING the PIC you've chosen has that capability.
Not all PICs have data EEPROM.You should post which one you're using.
The actual communications between the HMI PIC and the remote PIC could be simple 'RS232' (serial ) communications. Again a PIC with 2 HW UARTs would be a good choice, as one UART would be for HMI<>remote and the other for testing say to a PC. |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Mon Nov 21, 2022 12:09 pm |
|
|
This is not impossible, but it won't necessarily be easy. You're essentially trying to duplicate a programmer's view/edit EEPROM functionality but in an entirely embedded application.
You will need to study a PIC's flash programming specification but beware that not all PICs are exactly the same in this regard. Code developed for one family might not be applicable to another. I'm also uncertain whether you'd be able to change the contents of just one byte - you may need to read an entire page, change the one value you want to change, then write the entire page back.
The other sticking point (for me anyway) would be the user interface. Scrolling through 128, 256, or more EEPROM addresses on a 2 or 4 line character LCD would be tiresome at best. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Mon Nov 21, 2022 1:01 pm |
|
|
for the display....
hmm, 128 bytes of data ,presented on a 4x20 LCD could be 4 'screens'.
formatted as
2 bytes for address
2 byes for space
16 bytes as 2 bytes/data x 8
so each row has 8 cells x 4 rows = 32 x4 = 128
Not that 'difficult' to deal with after all we're all experts in HEX, right ?
for the input....
8 push buttons works nice
laid out as
4 cursor keys(up,down ,left,right
1 for page(press..1,2,3,4,1,2,.....
1 for yes
1 for no
1 for 'ok'
getting the data from the PIC is easy, 3 -5 lines of code
writing the new data, maybe 10 ?
A LOT of design cannot be decided or done until a PIC is chosen though..... |
|
![](templates/subSilver/images/spacer.gif) |
dmitrboristuk
Joined: 26 Sep 2020 Posts: 51
|
|
Posted: Mon Nov 21, 2022 1:09 pm |
|
|
newguy wrote: | . You're essentially trying to duplicate a programmer's view/edit EEPROM functionality but in an entirely embedded application.
|
You absolutely understood my message! I do not have to change all the contents of EEPROM by 1 byte, it will be enough to read all its contents into RAM, edit and write back to EEPROM. I am also quite satisfied with access to the configurable controller in programming mode (via standard pins)
temtronic
For example PIC16F18855 |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Mon Nov 21, 2022 2:52 pm |
|
|
thinking about this while I rebuild my MECCANO Magic Motor #1....
Probably the easiest solution is to get the 'other PIC' ( NOT the HMI PIC ) to read/display/alter/save it's EEPROM.
All the routines/functions/code need to be created anyway and it's easier to test within the 'other PIC' as it eliminates any communications problems.
That PIC does have 256 bytes of EEPROM, x2 what you originally said so that's good. I would choose the largest one within that family to be sure you have enough memory for the additional routines.
We don't know what the 'other PIC' has left in memory for the HMI interface. while serial only needs 1 or 2 I/O lines, a 'built-in' HMI would require 7-9 I/O lines,perhaps more depending on how you decide to interface the LCD and KPD to the PIC.
I have never used the PIC you posted,prefer to stay with the 18F46K22 series as I have an old compiler, folders jammed full of working projects and KNOW it's a proven PIC. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Tue Nov 22, 2022 2:34 am |
|
|
The key thing is though that is all just basic programming.
All he needs first, is a routine in the second PIC, that when it receives
a particular command, it stops, and sends the contents of the EEPROM as
a packet of data. Include a checksum just to be confident the transmission
is 'good'. Then the code here sits waiting till it receives the packet 'back',
again with a suitable checksum. Once it receives this, it writes it to the
EEPROM, and sends back a signal to say this is done.
The HMI chip, just needs a basic editor program to display this data, all
it to be edited in whatever format is most convenient (hex, ASCII etc.).
Have this send the command to the second chip to ask for the data, allow
it to be edited, and once complete send this back to the second chip, then
wait for the 'done' signal.
Each step is dead basic. The key is to design the steps to be convenient
and reliable. So make the commands to trigger things a little more than
single characters. Look at existing editors for such data, and try to layout
the HMI interface to suit the actual job involved. So if a large block of the
data is ASCII make this the format used for this part of the data. If some
are numeric values, code the display and editing of these into the format
they are actually used 'in' (float, decimal etc..). Add checksums, since
these just help to ensure nothing has been misread. etc. etc.. |
|
![](templates/subSilver/images/spacer.gif) |
newguy
Joined: 24 Jun 2004 Posts: 1903
|
|
Posted: Tue Nov 22, 2022 9:12 am |
|
|
I believe there's still some confusion regarding the crux of their question. I'm pretty sure that what they're after is an embedded EEPROM reader/programmer which targets any PIC, regardless of the firmware burned into it.
Yes, to create a crude proof of concept they could take the easy route and create custom firmware for the target PIC that would interact with the "programmer" to a) dump the current contents of EEPROM, and b) accept (and burn) new contents. I doubt, however, that that is what they're asking for. I'm quite sure that they want a generic EEPROM reader/programmer which can work with any target PIC and which does not require custom FW to reside on said target PIC.
To the OP: the only way you'll be able to achieve this is if the unit you develop is capable of "programming" the target PIC. Find and read the programming specification of one of the PICs you intend to target. There will likely be slight differences family-to-family, but the underlying procedure will likely be similar for most PICs you intend to target. Next, identify the starting address of the EEPROM within the PIC you intend to target. Your code should concentrate on reading that block of data first. Once you can reliably do this, then concentrate on reversing the process to program either one byte or one page within the target's EEPROM, then read it back using both a conventional programmer (i.e. ICD-U64) and your prototype project.
I strongly recommend buying a good logic analyzer (can't go wrong with a Saleae) and "scope" the target PIC's /MCLR, PGD and PGC lines while you a) read the target's EEPROM using a conventional programmer, and b) update/burn new content into the EEPROM using the same programmer. Those logic traces, in conjunction with reading the programming specification, should be step 1. |
|
![](templates/subSilver/images/spacer.gif) |
dmitrboristuk
Joined: 26 Sep 2020 Posts: 51
|
|
Posted: Wed Nov 23, 2022 12:23 am |
|
|
Thanks everyone for the helpful advice. I agree that the programming document should be studied. For my tasks, it will be enough to have only access to the EEPROM of the configurable microcontroller. That is, in fact, refer to it as a memory chip (for example, 24LC08B). If possible, through the programming interface. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Wed Nov 23, 2022 1:22 am |
|
|
If you mean through the PIC's programming interface, then 'no'. Not
even remotely possible with any PIC. In fact not possible with almost any
processor (that I can remember, a couple of the early Texas chips did
support this with their own specific memory chips), but no normal
EEPROM/processor can do this.
You would need to have your own program in the PIC and your own
interface to this.
I think from another thread you are taking about programming PIC's from
another computer, so are talking about a bootloader operation. If so, two
things apply.
First a bootloader _can_ program the internal EEPROM of a PIC. That
is supported by including the data at the programming address specified
by MicroChip for the particular chip.
Second, you could write a bootloader that did allow an external EEPROM
to be programmed. You would not send the contents 'back', you would just
specify your own memory range in an unused area of the address map
of the target PIC, and rewrite the bootloader so when it detects an attempt
to program this range, it writes the data to the external PIC.
The standard bootloaders are _loaders_ they do not support readback
of the data. |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|