RetroBSD

2.11BSD operating system for microcontrollers
It is currently Thu Nov 14, 2019 12:48 am

All times are UTC




Post new topic Reply to topic  [ 13 posts ] 
Author Message
PostPosted: Thu Feb 02, 2012 1:51 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
For some boards (ie baremetal, dip, expl16) there is a devcfg.c where one can set the cpu config (there is a change in *.ld and Makefile as well). On some boards (ie ubw32, ubw32-uart..) the cpu config setup is done in Serge's hid-bootloader afaik. Would it be possible to standardise that in the way all boards will have the devcfg.c (with the changes in *.ld and Makefile)? So when the cpu starts it always takes the settings from the devcfg.c. Then we can experiment with other cpu settings independently from bootloader (ie my favorite 120/120MHz setting :) ).

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Thu Feb 02, 2012 4:19 am 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1092
Hi Pito,

Another useful program would display the current settings of the config bits. My debugger does this as hex, but translating the hex to ascii with their meanings would be nice.

I haven't yet figured out how to read memory from any of our languages, but given that the rest should be pretty easy.

I suppose it could be part of sysctl? If that is easier.

Wiz


Top
 Profile  
 
PostPosted: Thu Feb 02, 2012 4:33 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
sysctl is certainly a good place for it - it's kernel memory that it's displaying, so having the kernel look at the config settings and set the right flags in memory would be do-able.

_________________
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  
 
PostPosted: Thu Feb 02, 2012 6:08 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
The different devcfg.c files for bootloader and cpu might be useful in a scenario, where usb bootloader will use internal 8MHz (because of USB freq) and when switched to normal operation the cpu will use ie. 11.0592Mhz or similar all_baudrate crystal for precise usart baudrates (when usb not used).
Moreover, especially for various datalogging apps one may not need to run it @80MHz.

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Thu Feb 02, 2012 7:29 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
The thing with the devcfg.c is that it contains the configuration bits that get burned in at program time.

These are the startup values, and are what whatever the booting system is uses.

If it's got a bootloader, then these are for the bootloader. If it doesn't, then they're for the main retro system.

That can't be changed - it's how a pic operates.

It is, however, possible to change the oscillator settings on the fly using software. So, if you're unhappy with the settings the bootloader uses, you can write software to change them. It'd have to be part of the kernel. Maybe have sysctl able to change the oscillator on the fly? That'd be nice.

_________________
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  
 
PostPosted: Thu Feb 02, 2012 9:18 am 
Contributor
User avatar

Joined: Thu Nov 08, 2012 7:04 am
Posts: 2401
Location: Rapa Nui
..yea, you are right, those hardwired config bits :(
But changing them on fly should be possible..

_________________
Pukao Hats Cleaning Services Ltd.


Top
 Profile  
 
PostPosted: Thu Feb 02, 2012 10:28 pm 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1092
Hi Serge, Majenko and Pito,

Yes, you can change lots of the config bits on the fly. I am not sure about the clock speed. I suspect it may need a power cycle.

I program those locations as regular memory. To get new values I erase the whole 4K block to FFs and then using my j-tag debugger program them to the desired values. A plain reset doesn't seem to do the trick. I have to remove and reapply power to have the effect for the clock. As noted earlier the 1.8v bypass cap. affects the ability of the chip to get the clock pll started. Once it starts it seems to keep running OK.

When the bits have a I/O space image, like RAM and Flash wait states, I can modify them from a program even though the config bits have not changed.

I hope this helps.

Wiz


Top
 Profile  
 
PostPosted: Fri Feb 03, 2012 12:05 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
I am experimenting with yet another new way of configuring the kernel.

It's loosely based on the way FreeBSD works, with a config file that specifies settings for your specific board, and can inherit and override settings from other boards.

I felt the Makefile was beginning to get rather messy with all the definitions in there, so I thought a system that generated it all for you would be good.

At the moment I have it working with basic settings. All the -DWHATEVER bits I have moved into a "config.h" file that is included by every C and S file. The devcfg.c file is generated by the settings specified in the config. The files to compile into the kernel are also generated.

And the config file is far easier to understand and modify than the Makefile.

Here's my "retro1" config:


include boards/baremetal.conf

ident RETRO1

device adc
device power
device gpio

option power_led G12
option power_switch G0
option power_control E9

option console_rtscts
option console_baud 115200

option sd_port SPI1CON
option sd_mhz 13
option sd_cs C14

option led_disk E4
option led_kernel E3
option led_tty E2
option led_aux G13

option lcd_rs G9
option lcd_rw G15
option lcd_e G8
option lcd_db0 E6
option lcd_db1 G7
option lcd_db2 E5
option lcd_db3 G6
option lcd_db4 C1
option lcd_db5 C2
option lcd_db6 E7
option lcd_db7 C3

option ucb_meter

option kernel_highlight


The whole thing is controlled by a "schema" file which defines what should be done for each option/device etc. Here's a snippet:


option console_usb
define CONSOLE_USB
include usb_console.o
include usb_device.o
include usb_function_cdc.o

define USB_NUM_STRING_DESCRIPTORS=3
define USB_MAX_EP_NUMBER=3
end option
option console_uart1
define CONSOLE_UART1
include cons.o
end option

option led_disk
define LED_DISK_PORT={port $1}
define LED_DISK_PIN={pin $1}
end option
option led_kernel
define LED_KERNEL_PORT={port $1}
define LED_KERNEL_PIN={pin $1}
end option
option led_tty
define LED_TTY_PORT={port $1}
define LED_TTY_PIN={pin $1}
end option
option led_aux
define LED_AUX_PORT={port $1}
define LED_AUX_PIN={pin $1}
end option

chip pic32mx512f795l
define _P32MX512F795L
define CPU_KHZ=80000
define BUS_KHZ=80000
define PIC32MX7

config 0 debug_enabled

config 1 fpbdiv_1
config 1 osciofnc
config 1 fckm_disable
config 1 fcks_disable
config 1 wdtps_1024

config 2 fpllidiv_2
config 2 fpllmul_20
config 2 upllidiv_2
config 2 uplldis
config 2 fpllodiv_1

config 3 userid(0xffff)
config 3 fsrssel_7
config 3 fethio
end chip

option osc_internal
config 1 fnosc_frcdivpll
config 1 poscmod_disable
end option

option osc_hs
config 1 fnosc_pripll
config 1 poscmod_hs
end option


There's loads more I'd like to add.

_________________
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  
 
PostPosted: Fri Feb 03, 2012 1:19 am 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1092
Hi Serge, Pito and Majenko,

I really like the idea of a "manual" that you edit, like what you have shown.

I wonder how many MicroChip errors we will stumble into? With a chip this complicated, it is hard to know where to begin. Hopefully at least power-on reset gives a known state! The power-on states should probably be part of our documentation as well.

From what I have seen, the whole, what is reset when, is probably best measured and reported on rather than read from the published documentation.

I would add to your page the actual config words finally produced so the reader can easily verify what was done. I have lost so much time when a bit was set wrong and I didn't realize that the bit setting program was the problem. Or sometimes that the manufacturer's documentation was confusing (to me) or occasionally wrong.

Wiz



Top
 Profile  
 
PostPosted: Fri Feb 03, 2012 2:42 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
You can see what config bits have been set by examining the produced devcfg.c file (and the config.h file for #defines). They're there in plain text as they are in the existing ones.

_________________
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  
 
PostPosted: Fri Feb 03, 2012 2:53 am 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1092
Hi Majenko,

I had in mind plain hex as in:

1fc02ff0 = 12345678
1fc02ff4 = abcdef01

Wiz


Top
 Profile  
 
PostPosted: Fri Feb 03, 2012 3:26 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
Just pass the devcfg.c file through CPP and you can see the values of each flag being set:

asm (".section .config"); unsigned __DEVCFG0 __attribute__ ((section (".config0"))) = (0x00000002) ^ 0x7fffffff; unsigned __DEVCFG1 __attribute__ ((section (".config1"))) = (0x00000200 | 0x00004000 | 0x00000003 | 0x00008000 | 0x00000400 | 0x00000000 | 0x000a0000) | 0xff600858; unsigned __DEVCFG2 __attribute__ ((section (".config2"))) = (0x00008000 | 0x00000000 | 0x00000000 | 0x00000100 | 0x00000050) | 0xfff87888; unsigned __DEVCFG3 __attribute__ ((section (".config3"))) = (0x00070000 | 0x02000000 | ((0XFFFF) & 0xffff)) | 0x38f80000

_________________
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  
 
PostPosted: Fri Feb 03, 2012 3:56 am 
Contributor

Joined: Mon Nov 12, 2012 1:34 pm
Posts: 1092
Hi Majenko,

That's cool. I didn't know how to do that :).

I have observed config bits being set to curious (supposedly illegal) states with Microchip tools? Hidden 'features' ? Maybe tied up with USB?

This leads me to want to know both sides:

1. What the software "told" the hardware to do. Usually I look at the hex file.

2. And what the hardware actually did! I look with my hex debugger.

The whole thing can of course be much more complex with multiple writes meaning different things, etc.

Since I am a low-level type of guy, I start out by peeking and poking.

That is how I discovered that the reset button produces a different result than a software reset than a power cycle reset. Even though the manufacturer's docs would lead you to believe otherwise.

There is one port bit in the PIC that is VERY slow to go tri-state. I don't remember which off hand, but I couldn't drive a simple shift-register serial display with it. I changed to another bit. Maybe my chip was defective? Maybe all chips are the same? I don't know at this point, but it did surprise me.

It's that sort of thing that causes me to want to read and write hardware directly so I can see what is really happening.

For whatever reason, Maximite and RetroBSD REQUIRE different config settings? My debugger works with either?

Wiz


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

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