RetroBSD

2.11BSD operating system for microcontrollers
It is currently Tue Apr 07, 2020 5:56 am

All times are UTC




Post new topic Reply to topic  [ 182 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10  Next
Author Message
 Post subject: Re: pic32prog
PostPosted: Sun Mar 08, 2015 11:33 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
Various pull requests have been created. Assuming they all get accepted all future chipKIT bootloaders will have the new baud rate changing facility in them for pic32prog to make use of.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Sun Mar 08, 2015 11:52 pm 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
Fantastic! Now, let us determine what is the max safe speed..
BTW, after the 2Mbaud upload you certainly switch back to 115k, do you??

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 12:20 am 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
No, I don't. Why would I? pic32prog exits and closes the port - what does it matter what baud rate is set then?

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 1:07 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
When we move into such large flash volumes, it would be great to implement a control system over the flash data integrity, for example:
1. picprog will create a md5 or sha1 (or other) hash for the specific upload
2. picprog will upload the flash and the hash into the pic
3. you may check the flash integrity against the hash anytime within your app then (or bootloader can do that during passing into your app).
Good for upcoming Mars mission.
PS: the bootloader may provide a ram memtest as well.. ;)

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 8:02 am 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
Hi

majenko wrote:
Various pull requests have been created. Assuming they all get accepted all future chipKIT bootloaders will have the new baud rate changing facility in them for pic32prog to make use of.


I have seen this addition and it's a great idea for testing the maximum
rate a particular device can achieve.

I have one comment though, the stk500v2 protocol exclusively uses
big-endian, I think any additions should respect that choice.

In other news, I am going to create a USB boot loader for the SDXL today
which compiles using the MPIDE compiler (at least I hope to do this).

This will allow anyone to build a new boot loader relatively easily.

Bye


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 2:49 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
I considered the endian briefly, and decided on using little endian for this since the pic32 is little endian. It makes absolutely no difference to anything though... It's little endian now, and is in the main pic32 bootloader repo now, so little endian it is.

I have improved the support for handling bootloaders that don't have support for it now - the request returns the requested baud in the response so you can confirm it was accepted, since the bootloader is a bit idiotic and accepts everything with a "Yep, that's fine" whether it is or not. Bit silly really. Still, now it will check that returned baud rate value matches, and only if it does will it actually change the baud rate. Falls back to the default (or "-b") baud rate if the request fails.

Just waiting for Serge to accept the pic32prog pull request and re-compile all the binaries, and I can include it in UECIDE as default so everyone can benefit from it ;)

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 4:19 pm 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
lo

majenko wrote:
I considered the endian briefly, and decided on using little endian for this since the pic32 is little endian. It makes absolutely no difference to anything though... It's little endian now, and is in the main pic32 bootloader repo now, so little endian it is.


right.

Quote:
I have improved the support for handling bootloaders that don't have support for it now - the request returns the requested baud in the response so you can confirm it was accepted, since the bootloader is a bit idiotic and accepts everything with a "Yep, that's fine" whether it is or not. Bit silly really. Still, now it will check that returned baud rate value matches, and only if it does will it actually change the baud rate. Falls back to the default (or "-b") baud rate if the request fails.


The boot loader should return STATUS_CMD_FAILED if the commands fails. I realise it's set up
to always say OKAY but that's a issue can that be fixed without adding a workaround.

The whole loader could do with a overhaul to be honest.

Quote:
Just waiting for Serge to accept the pic32prog pull request and re-compile all the binaries, and I can include it in UECIDE as default so everyone can benefit from it ;)


What devices use a serial interface for the boot loader? The chipKIT Pi is one but I
unfamiliar with anything else.

Bye


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 4:23 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
nroff-man wrote:
The boot loader should return STATUS_CMD_FAILED if the commands fails. I realise it's set up
to always say OKAY but that's a issue can that be fixed without adding a workaround.

Yes, I know that, but you try visiting every person who has ever bought a chipKIT board, breaking into their house / place of work / laboratory / Mars base and replacing their bootloaders.

This solution works on existing boards without the need for a bootloader upgrade - one of the most vital things with this system.
nroff-man wrote:
What devices use a serial interface for the boot loader? The chipKIT Pi is one but I
unfamiliar with anything else.

Pretty much every chipKIT board that has ever been made, except the Fubarino and similar. That's the Uno32, Max32, uC32, WF32, Wi-FIRE... and so on and so on... Many many boards.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 4:32 pm 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
lo

majenko wrote:
nroff-man wrote:
The boot loader should return STATUS_CMD_FAILED if the commands fails. I realise it's set up
to always say OKAY but that's a issue can that be fixed without adding a workaround.

Yes, I know that, but you try visiting every person who has ever bought a chipKIT board, breaking into their house / place of work / laboratory / Mars base and replacing their bootloaders.


How many are there?

Quote:
This solution works on existing boards without the need for a bootloader upgrade - one of the most vital things with this system.


There are other ways to go about this. It may be worth while investigating the
firmware version command, for example.

Quote:
nroff-man wrote:
What devices use a serial interface for the boot loader? The chipKIT Pi is one but I
unfamiliar with anything else.

Pretty much every chipKIT board that has ever been made, except the Fubarino and similar. That's the Uno32, Max32, uC32, WF32, Wi-FIRE... and so on and so on... Many many boards.


Ok.

bye bye


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 4:35 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
nroff-man wrote:
lo

majenko wrote:
nroff-man wrote:
The boot loader should return STATUS_CMD_FAILED if the commands fails. I realise it's set up
to always say OKAY but that's a issue can that be fixed without adding a workaround.

Yes, I know that, but you try visiting every person who has ever bought a chipKIT board, breaking into their house / place of work / laboratory / Mars base and replacing their bootloaders.


How many are there?

Between one and a billion.
Quote:
Quote:
This solution works on existing boards without the need for a bootloader upgrade - one of the most vital things with this system.


There are other ways to go about this. It may be worth while investigating the
firmware version command, for example.

Just like skinning a cat. There's more than one way of doing it. There is no bootloader version command in the bootloader, so it would have to be implemented as well as the baud rate change command - or you can just implement the baud rate change command in such a way as it works regardless of what is implemented in the bootloader. I chose the latter as it's less work and perfectly reliable.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 4:39 pm 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
hi

Quote:
Just like skinning a cat. There's more than one way of doing it. There is no bootloader version command in the bootloader, so it would have to be implemented as well as the baud rate change command - or you can just implement the baud rate change command in such a way as it works regardless of what is implemented in the bootloader. I chose the latter as it's less work and perfectly reliable.


with the command GET PARAM there are various values that
can be returned including version information.

avrdude seems to read this but the chipkit bootloader appears
to reply with blanks.

I haven't experimented with it so can't say any more.

bye


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 4:47 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
The parameter system in the chipkit bootloader just stores whatever is sent with set_parameter and returns that same value with get_parameter.

The chipKIT bootloader implements about 3% of the actual stk500v2 protocol - just enough to get it working.

Mind, the stk500v2 protocol is bloody awful and was never intended to be used with a bootloader. It's all a big hack.

Since pic32prog is replacing avrdude in the chipKIT environment we can make whatever changes we like to the protocol to make it work better, but we have to be careful to make sure it doesn't break old systems which still use avrdude. So we can't really start implementing things that change how the existing system works (suddenly returning parameters we weren't returning before, for instance), but adding commands that would never be called by an old system is fine.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 4:57 pm 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
hi

majenko wrote:
The parameter system in the chipkit bootloader just stores whatever is sent with set_parameter and returns that same value with get_parameter.

The chipKIT bootloader implements about 3% of the actual stk500v2 protocol - just enough to get it working.

Mind, the stk500v2 protocol is bloody awful and was never intended to be used with a bootloader. It's all a big hack.

Since pic32prog is replacing avrdude in the chipKIT environment we can make whatever changes we like to the protocol to make it work better, but we have to be careful to make sure it doesn't break old systems which still use avrdude. So we can't really start implementing things that change how the existing system works (suddenly returning parameters we weren't returning before, for instance), but adding commands that would never be called by an old system is fine.


Sounds like you solved it, you just need to query for a chipKIT version parameter and
you know for sure what extensions are available.

PIC32Prog isn't exclusive to chipKIT and shouldn't force other stk500v2 back-ends
to implement a protocol hack. This should be done cleanly as possible with respect
for all users of pic32prog.

Cya


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 5:05 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
nroff-man wrote:
hi

majenko wrote:
The parameter system in the chipkit bootloader just stores whatever is sent with set_parameter and returns that same value with get_parameter.

The chipKIT bootloader implements about 3% of the actual stk500v2 protocol - just enough to get it working.

Mind, the stk500v2 protocol is bloody awful and was never intended to be used with a bootloader. It's all a big hack.

Since pic32prog is replacing avrdude in the chipKIT environment we can make whatever changes we like to the protocol to make it work better, but we have to be careful to make sure it doesn't break old systems which still use avrdude. So we can't really start implementing things that change how the existing system works (suddenly returning parameters we weren't returning before, for instance), but adding commands that would never be called by an old system is fine.


Sounds like you solved it, you just need to query for a chipKIT version parameter and
you know for sure what extensions are available.

PIC32Prog isn't exclusive to chipKIT and shouldn't force other stk500v2 back-ends
to implement a protocol hack. This should be done cleanly as possible with respect
for all users of pic32prog.

Cya

Which is why it has been implemented in such a way that if the command hasn't been implemented it doesn't do anything.

Adding a command isn't a "hack", it's an extension. If the extension doesn't exist then it doesn't do anything. It doesn't rely on the "back-end" telling pic32prog what commands it has available. It tries it, and if it worked it worked, if it didn't work it doesn't change the baud rate.

And of course none of this does anything at all unless you actively tell it to with the -B <baud> flag.

I cannot conceive of a more backwards-compatible, generic, friendly way of doing it than I have done.

Oh, and what other stk500v2 "back-ends" are there that pic32prog works with? There is the bootloader. I know of no others.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 5:16 pm 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
majenko wrote:
nroff-man wrote:
hi

majenko wrote:
The parameter system in the chipkit bootloader just stores whatever is sent with set_parameter and returns that same value with get_parameter.

The chipKIT bootloader implements about 3% of the actual stk500v2 protocol - just enough to get it working.

Mind, the stk500v2 protocol is bloody awful and was never intended to be used with a bootloader. It's all a big hack.

Since pic32prog is replacing avrdude in the chipKIT environment we can make whatever changes we like to the protocol to make it work better, but we have to be careful to make sure it doesn't break old systems which still use avrdude. So we can't really start implementing things that change how the existing system works (suddenly returning parameters we weren't returning before, for instance), but adding commands that would never be called by an old system is fine.


Sounds like you solved it, you just need to query for a chipKIT version parameter and
you know for sure what extensions are available.

PIC32Prog isn't exclusive to chipKIT and shouldn't force other stk500v2 back-ends
to implement a protocol hack. This should be done cleanly as possible with respect
for all users of pic32prog.

Cya

Which is why it has been implemented in such a way that if the command hasn't been implemented it doesn't do anything.

Adding a command isn't a "hack", it's an extension. If the extension doesn't exist then it doesn't do anything. It doesn't rely on the "back-end" telling pic32prog what commands it has available. It tries it, and if it worked it worked, if it didn't work it doesn't change the baud rate.

And of course none of this does anything at all unless you actively tell it to with the -B <baud> flag.

I cannot conceive of a more backwards-compatible, generic, friendly way of doing it than I have done.

Oh, and what other stk500v2 "back-ends" are there that pic32prog works with? There is the bootloader. I know of no others.


I have written an stk500v2 back-end compatible with pic32prog, this is why the
baud rate feature was added.

So, to implement this feature i will reply to a new command with OK plus
return with the baud rate if it is compatible, otherwise, I just reply FAILED?

That sounds reasonable. I look forward to seeing it in operation.

bye-bye

edit:typo


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 5:24 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
If you want to implement it, Yes.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 5:30 pm 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
hi

majenko wrote:
If you want to implement it, Yes.


ok, but let me understand, I also have a stk500v2 compatible
command line programmer as well.

If I select a baud rate when programming a chipkit firmware, it will always
say OK, but in this instance it will mangle the returned data?
what is the mangled data?

bye


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 5:32 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
Not sure I understand what you mean. The baud rate change happens after the response has been sent, so the response will always be sent at the initial baud rate.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 5:38 pm 

Joined: Wed Oct 08, 2014 11:03 am
Posts: 71
hi

majenko wrote:
Not sure I understand what you mean. The baud rate change happens after the response has been sent, so the response will always be sent at the initial baud rate.


ok. you mentioned before that the chipkit firmware always replies OK. so
you have an alternative method to determine if the baud rate change
will occur or or not? is this correct?

maybe you can write an RFC for this command :-)

thx

bye

edit:errors


Top
 Profile  
 
 Post subject: Re: pic32prog
PostPosted: Mon Mar 09, 2015 5:40 pm 
Committer
User avatar

Joined: Thu Oct 11, 2012 8:45 am
Posts: 1801
Location: Room 217, Floor 8, Arm 8, Wheel S7, Mars Base Alpha 3
Yes. You send 4 bytes, those same 4 bytes are returned in the same order. If they match what you sent then you know the baud rate is about to be changed and you should change yours as well.

_________________
Why not visit my shop? http://majenko.co.uk/catalog
Universal IDE: http://uecide.org
"I was trying to find out if it was possible to only eat one Jaffa Cake. I had to abandon the experiment because I ran out of Jaffa Cakes".


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 182 posts ]  Go to page Previous  1 ... 5, 6, 7, 8, 9, 10  Next

All times are UTC


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 post attachments in this forum

Search for:
cron




Powered by phpBB® Forum Software © phpBB Group

BSD Daemon used with permission