Sending data(angle_velocity) for x-axis{L3GD20) to Processing.
Red dots are x-angle_velocity's resister value(subtracting x0[initial average]).
Green line is angle(sum of x-angle_velocity).
Sensor is static state.
But angle is increasing(to plus or negative ).
Offset-drift must cancel.
Hi profb_raino.
PCT2075 and LM75 can connect on same i2c-line, if 2 device's address are different.
LM75: address are 8.i2c-clock is max 400kHz. accuracy:+-2degree
PCT2075:address are 27. i2c-clock is max 1MHz. accuracy:+-1degree
I wrote DHT11 's code by only Forth word.
Forth word 'singlewire' is long.
Although not measurment about each pulse width, it seem no problem.
Reply from DHT11; checked 160usec( sum of Lo and Hi)
bit; checked only Hi-pulse width ("0" when less than 50usec "1" when more than 50usec)
Compared DHT11 and PCT2075 about Temperature.
Almost same.
I have no idea about Humidity.
: TEST
begin
." DHT11:" space
disp_DHT11 \ Display Humidity and Tempareture from DHT11
5 spaces
." PCT2075:" space
GetTemp degree \ Display Tempareture from PCT2075
d2000 delms
cr
fkey? swap drop
until
;
I tried PCF85263(rtc).
This rtc has many functions.
I wrote only writing current-time and reading current-time.
i don't understand timestamp,stopwatch, watchdog,etc well.
PCA9624 reply to h03[SoftwareReset] and h70[ALLCALLADR].
reserve-address don't count i2c-device.
h70 isn't reserve-address.
So i2c-devices are 7pcs. Actually 6pcs.
These I2C UARTs always seem like a good idea except for the fact that they are never cheap. The 100 off price is $2.46 in a rather high pin-count TSSOP24. For less than 50 cents I can buy a Silabs CPU (EFM8BB10F8G-A-SOIC16) in a friendly SOIC16 and use that as an I2C UART with larger FIFOs plus it's customizable. In fact I have code that flashes these parts from the Prop and only needs one extra dedicated line in addition to the I2C bus. These newer EPM8 parts are just like the older C8051Fs but they seem to also have a UART bootloader mode. 8051 assembly code itself is very easy and tools are freely available and there is also BASCOM and other languages too. I normally assemble to a binary image which is then included with the C2PROG.spin which I F10 into RAM to do the once off Flashing of these parts.
I wrote PCF2129(rtc).
Slaveaddres is h51.
Same as PCF85263(rtc).
So, separate by PCF9546.
Connected PCF85263(rtc) to PCF9546's [SC0 SD0].
Connected PCF2129(rtc) to PCF9546's [SC1 SD1].
No connecting any line by default.
Sal has gotten time to start back in on releasing PropForth 6.0. The assembler, kernel builds, and base startup are all working. Sal is ironing out bugs in the process so an average (non-Sal) user (i.e. me) can perform the build without help other than the instructions.
Propforth 6 is primarily Propforth 5.5 with changes to the build process. Included are:
- Build for FPGA versions of the prop.
- Linux build - PropTool for windows is no longer required
- SPIN is no longer required. SPIN is still generated (E.G. for changing clock speed and serial I/O pins); however the binary file created can be loaded directly. The SPIN and the binary are identical once loaded on the prop.
Also included are:
- Pooled tasking (extension)
- controled serial on both ends (tool chain mod)
FGPA prop: Propforth typically uses a subset of the prop's functions. Sal typically does realtime bit-banging, and so does not often use features like video generation B-side provisions, and more advanced frequency functions (I'm not sure about the last one). Anyway, the FPGA versions allow us to remove any unsued frealestate, like the video generator and the B-side functions, and instead add more cogs and/or memory. The same propforth source code that runs on a physical prop chip will run on the FPGA prop, and tcode that runs on an FPGA prop will also run on the physical propchip. Sal has examples of 8 cogs and lots of ram, and 16 cogs and not so much ram, but still more than the physical prop. If the FPGA board is present, the automated build will build and load the FPGA as well as build and load the propforth kernel, and then perform the automated testing as usual.
LINUX BUILD: Way back when we first looked at linux build, we were just getting away from the original Windows/Proptool method. Build was successful on a linux PC, but required special steps. Now, we should be able to compile on any linux box (PC, raspberry pi, DLink DIR-505L). The result off this should be an easy integration of a propforth unit (realtime multitasking) with a linux unit (PC or DIR-505L).
No SPIN: Till now, the Proptool was used to resolve things like forward references in the compile process. The inital kernel would run a simple version of forth, and this loaded addition forth source, which in turn generated the optimized assembler kernel (per the typical forth development methodology). Now, we will just go to directly generating the optimized kernel at the end of a linux tool set. A SPIN file can still be generated for when anyone wants to tweak the kernel at that stage. The untweaked SPIN file and the binary file will look identical on the physical prop chip.
Pooled Tasking: Generic forth multitasking in software is a "round robin". Each task does it's thing, and processign at full speed, and gives up control when it hits a slow spot, for example when it has to hit I/O. This is how forth can manage realtime multitasking on single task processors. The engineer has to pay attention and balance stuff, but its very effective when done well, and its pretty easy. Sal is doing a similar thing on the prop. In additon to each task being in a pool, the cogs are also in a pool. The next task executes on the next availible cog. Each task give up control when it hits a slow spot, for example when it has to wait for a shared resource like hub ram. This was a mod to the kernel, but might manifest as an extension that we just load on top of the standard kernel.
Here is the really cool advantge of pooled tasking: If a task has to wait a long time, it would ruin the "realtime" response of the process, which is very noticable on a single core system. On the physical prop with 8 cogs, it only reduces the capability of the system by 1/8th. On a 16 cog FPGA prop, a stalled task reduces system capability by 1/16th. This might allow some interesting flexibity in realtime/multiasking systems.
Controlled serial: serial comms have been problematic as the serial "standard" is not very standard at all, and tends to be many conflicting "standards" that always find a way to screw up right when we don't want them to. The fl (fastload) was used to load source text by streaming it to an available cog, and that cog handled the buffring etc. It would fine most of the time, but still had problems at awkward times. Now Sal has decided that the only way to get it completely consistent is to control (as in "define") both ends of the serial communication interface. The work started with the "gotern" and "gomuxterm" functions are now integrated into the tools, and serial communication between the host and the prop "just works". I don't know what this means to Windows or Mac, we will work through that when (if) it comes up.
we're still at least weeks out before I get anything for testing, but at least we can know what to expect. As always I can send out the early version to interested folks once we declare it clean and stable.
Incidently, Sal has not found any bugs in the propforth kernel for a couple years, so we are becoming confident that the code might be good.
The PF6 package is to contain three areas of source code - C, GO, and FORTH. We dont need to do anything with the C or GO, those parts of the tool chain can be used as-is, they just need to be present for the build and test automation. Each section will contain the precompiled binaries as usual.
C source code - for the proxy terminal
GO sourcre code - for the PC serial comms
PropForth - for the build and development environments
Linux and Windows will be included, and Mac support will be included according to the hardware we have available. We might need to find a new Mac person, this will be resolved later as it becomes relevant.
We talked about 32 and 64 bit support. Most everything is already on 64 bit architecture machines, but a few folks might only have access to 32 bit PC's. We decide that maintaining both 32 bit and 64 bit processes would be doable, but would be time consuming PITA. So, Sal said he would do BOTH 32 and 64 bit ONCE. After the first release of PF6, only 64 bit PC will be supported. The 32 bit material would be included, but would not be supported. If anybody does not have access to a 64 bit PC, they can request a 32 bit build. We would then try to talk them into upgrading, and generate 32 bit builds as needed. I just tossed my old 32 bit PC's, so everything would likely be done on virtual box machines.
Comments
Red dots are x-angle_velocity's resister value(subtracting x0[initial average]).
Green line is angle(sum of x-angle_velocity).
Sensor is static state.
But angle is increasing(to plus or negative ).
Offset-drift must cancel.
Red:x
green:y
Blue:z
It's strange.
Values from accel_X actually indicate y-axis's acceleration.
And values from accel_Y actually indicate x-axis's acceleratio .
Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- <-- PCT2075 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- eeprom 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- <-- MPU6050 70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- i2c_device:3 Prop0 Cog6 okCode is almost same as PCT2075.
Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- <-- LM75 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- eeprom 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- <-- MPU6050 70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- i2c_device:3 Prop0 Cog6 okI like i2c_detect, it looks like it will be handy.
Are LM75 and PCT2075 drop-in replacements for each other? how are they different? Very interesting. Can I askwhat you are using them in?
PCT2075 and LM75 can connect on same i2c-line, if 2 device's address are different.
LM75: address are 8.i2c-clock is max 400kHz. accuracy:+-2degree
PCT2075:address are 27. i2c-clock is max 1MHz. accuracy:+-1degree
I bought magazine with i2c-devices last week.
i2c devices(19type);
PCAL9554BPW PCAL9555APW:GPIO
LM75BD PCT2075D:Temperature sensor
PCA9600DP PCA9571ADP:Bus buffer
PCA9629APW;motor controller
PCA9632DP1 PCA9624PW PCA9622DR PCA9626B PCA9955ATW PCA9956ATW;LED controller
PCA9541AD/01 PCA9546AD:multiplexa
PCF8591T;A/D D/A converter
SC16IS750IPW;bridge
PCF85263AT PCF2129AT/2;RTC
I don't think what use thse devices yet.
Forth word 'singlewire' is long.
Although not measurment about each pulse width, it seem no problem.
Reply from DHT11; checked 160usec( sum of Lo and Hi)
bit; checked only Hi-pulse width ("0" when less than 50usec "1" when more than 50usec)
Almost same.
I have no idea about Humidity.
: TEST begin ." DHT11:" space disp_DHT11 \ Display Humidity and Tempareture from DHT11 5 spaces ." PCT2075:" space GetTemp degree \ Display Tempareture from PCT2075 d2000 delms cr fkey? swap drop until ;This rtc has many functions.
I wrote only writing current-time and reading current-time.
i don't understand timestamp,stopwatch, watchdog,etc well.
Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 49 -- -- -- -- -- -- h48:LM75 h49:PCT2075 50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- h51:eeprom h51:PCF85263 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- h68:MPU6050 70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- i2c_device:5 Prop0 Cog6 ok Prop0 Cog6 ok 2015 4 4 17 20 00 set_current Prop0 Cog6 ok test CurrentTime Year: 2015 Date: APR 17 FRI 20:00:03 CurrentTime Year: 2015 Date: APR 17 FRI 20:00:04 CurrentTime Year: 2015 Date: APR 17 FRI 20:00:05 Prop0 Cog6 okProp0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: -- -- -- 03 -- -- -- -- -- -- -- -- -- -- -- -- <-- PCA9624 reply 10: 10 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- PCA9624 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 49 -- -- -- -- -- -- <-- h48:PCT2075 h49:LM75 50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h50:eeprom h51:PFC85263 60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- -- <-- PU6050 70: 70 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- PCA9624 reply i2c_device:7 [0 - 7] and [h78 - h7F] are reserve-addressPCA9624 reply to h03[SoftwareReset] and h70[ALLCALLADR].reserve-address don't count i2c-device.
h70 isn't reserve-address.
So i2c-devices are 7pcs. Actually 6pcs.
I don't write all functions yet.
Almost same as PCA9624.
Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: -- -- -- 03 -- -- -- -- -- -- -- -- -- -- -- -- <-- PCA9624 PCA9632DP1 reply 10: 10 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- PCA9624 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 49 -- -- -- -- -- -- <-- h48:PCT2075 h49:LM75 50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h50:eeprom h51:PFC85263 60: -- -- 62 -- -- -- -- -- 68 -- -- -- -- -- -- -- <-- h62:PCA9632DP1 h68:MPU6050 70: 70 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- PCA9624 PCA9632DP1 reply i2c_device:8 [0 - 7] and [h78 - h7F] are reserve-address Prop0 Cog6 okPCA9632DP1 reply h03[SoftwareReset] and h70[ALLCALLADR].reserve-address don't count i2c-device.
h70 isn't reserve-address.
So i2c-devices are 8pcs. Actually 7pcs.
Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: 00 -- -- 03 -- -- -- -- 08 -- -- -- -- -- -- -- <-- 8:PCA9955A 10: 10 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h10:PCA9624 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 49 -- -- -- -- -- -- <-- h48:PCT2075 h49:LM75 50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h50:eeprom h51:PFC85263 60: -- -- 62 -- -- -- -- -- 68 -- -- -- -- -- -- -- <-- h62:PCA9632DP1 h68:MPU6050 70: 70 -- -- -- -- -- 76 -- -- -- -- -- -- -- -- -- i2c_device:10 [0 - 7] and [h78 - h7F] are reserve-address Prop0 Cog6 okh00 PCA9955A reply
h03 PCA9624 and PCA9632DP1 reply
h70 PCA9624 and PCA9632DP1 reply
h76 PCA9955A reply
'i2c_detect' don't count reserve-address as i2c-device.
h70 and h76 isn't reserve-address.
So i2c-devices are 10pcs. Actually 8pcs.
Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: 00 -- -- 03 -- -- -- -- 08 -- -- -- -- -- -- -- <-- 8:PCA9955A 10: 10 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h10:PCA9624 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 49 -- -- 4C -- -- -- <-- h48:PCT2075 h49:LM75 h4C:SC16IS750 50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h50:eeprom h51:PFC85263 60: -- -- 62 -- -- -- -- -- 68 -- -- -- -- -- -- -- <-- h62:PCA9632DP1 h68:MPU6050 70: 70 -- -- -- -- -- 76 -- -- -- -- -- -- -- -- -- i2c_device:11 [0 - 7] and [h78 - h7F] are reserve-address Prop0 Cog6 okh00 PCA9955A reply
h03 PCA9624 and PCA9632DP1 reply
h70 PCA9624 and PCA9632DP1 reply
h76 PCA9955A reply
'i2c_detect' don't count reserve-address as i2c-device.
h70 and h76 isn't reserve-address.
So i2c-devices are 11pcs. Actually 9pcs.
These I2C UARTs always seem like a good idea except for the fact that they are never cheap. The 100 off price is $2.46 in a rather high pin-count TSSOP24. For less than 50 cents I can buy a Silabs CPU (EFM8BB10F8G-A-SOIC16) in a friendly SOIC16 and use that as an I2C UART with larger FIFOs plus it's customizable. In fact I have code that flashes these parts from the Prop and only needs one extra dedicated line in addition to the I2C bus. These newer EPM8 parts are just like the older C8051Fs but they seem to also have a UART bootloader mode. 8051 assembly code itself is very easy and tools are freely available and there is also BASCOM and other languages too. I normally assemble to a binary image which is then included with the C2PROG.spin which I F10 into RAM to do the once off Flashing of these parts.
I have even written Forth code support for Flashing and debugging these parts as well. Too easy!
Of course you also get all the extra peripherals with it including 12-bit ADC.
Just a thought.
Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: 00 -- -- 03 -- -- -- -- 08 -- -- -- -- -- -- -- <-- 8:PCA9955A 10: 10 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h10:PCA9624 20: 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h20:PCAL95554BPW 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 49 -- -- 4C -- -- -- <-- h48:PCT2075 h49:LM75 h4C:SC16IS750 50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h50:eeprom h51:PFC85263 60: -- -- 62 -- -- -- -- -- 68 -- -- -- -- -- -- -- <-- h62:PCA9632DP1 h68:MPU6050 70: 70 -- -- -- -- -- 76 -- -- -- -- -- -- -- -- -- i2c_device:12 [0 - 7] and [h78 - h7F] are reserve-address Prop0 Cog6 okh00 PCA9955A reply
h03 PCA9624 and PCA9632DP1 reply
h70 PCA9624 and PCA9632DP1 reply
h76 PCA9955A reply
'i2c_detect' don't count reserve-address as i2c-device.
h70 and h76 isn't reserve-address.
So i2c-devices are 12pcs. Actually 10pcs.
I was mistake about definition of slaveaddress.
I upload PCAL9554BPW_0.2.
This has 16bit ports.
Almost same as PCAL9554BPW.
Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: 00 -- -- 03 -- -- -- -- 08 -- -- -- -- -- -- -- <-- 8:PCA9955A 10: 10 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h10:PCA9624 20: 20 21 -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h20:PCAL95554BPW h21:PCAL9555APW 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 49 -- -- 4C -- -- -- <-- h48:PCT2075 h49:LM75 h4C:SC16IS750 50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h50:eeprom h51:PFC85263 60: -- -- 62 -- -- -- -- -- 68 -- -- -- -- -- -- -- <-- h62:PCA9632DP1 h68:MPU6050 70: 70 -- -- -- -- -- 76 -- -- -- -- -- -- -- -- -- i2c_device:13 [0 - 7] and [h78 - h7F] are reserve-address Prop0 Cog6 okh00 PCA9955A reply
h03 PCA9624 and PCA9632DP1 reply
h70 PCA9624 and PCA9632DP1 reply
h76 PCA9955A reply
'i2c_detect' don't count reserve-address as i2c-device.
h70 and h76 isn't reserve-address.
So i2c-devices are 13pcs. Actually 11pcs.
Prop0 Cog6 ok demo [Input port test] P1_7 P1_6 P1_5 P1_4 P1_3 P1_2 P1_1 P1_0 P0_7 P0_6 P0_5 P0_4 P0_3 P0_2 P0_1 P0_0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 [Reverse input porality] P1_7 P1_6 P1_5 P1_4 P1_3 P1_2 P1_1 P1_0 P0_7 P0_6 P0_5 P0_4 P0_3 P0_2 P0_1 P0_0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 [Output port test] P1_7 P1_6 P1_5 P1_4 P1_3 P1_2 P1_1 P1_0 P0_7 P0_6 P0_5 P0_4 P0_3 P0_2 P0_1 P0_0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Prop0 Cog6 okAE-AS3935(Franklin Ligtning Sensor Module)
I don't know operating finely because today is a fine day.
Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: 00 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- i2c_device:1 [0 - 7] and [h78 - h7F] are reserve-address Prop0 Cog6 okAS3935's slaveaddress is [0,1,2,3].This module is 0.
TRCO is inside spec. min305kHz max34.0kHz
SRCO is not inside spec. min1.065MHz max1.19MHz
I have no idea why out of spec.
This device sck is 100kHz.
It seems i2c_detect[400kHz] and i2c_wr[400kHz] is ok.
But i2c_rd[400kHz] don't work.
So, redefined i2c_wr and defined PCF8591_rd.
SCK is about 27.7kHz.
Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: 00 -- -- 03 -- -- -- -- 08 -- -- -- -- -- -- -- <-- 8:PCA9955A 10: 10 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h10:PCA9624 20: 20 21 -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h20:PCAL95554BPW h21:PCAL9555APW 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 49 4A -- 4C -- -- -- <-- h48:PCT2075 h49:LM75 h4C:SC16IS750 h4A:PCF8591 50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h50:eeprom h51:PFC85263 60: -- -- 62 -- -- -- -- -- 68 -- -- -- -- -- -- -- <-- h62:PCA9632DP1 h68:MPU6050 70: 70 -- -- -- -- -- 76 -- -- -- -- -- -- -- -- -- i2c_device:14 [0 - 7] and [h78 - h7F] are reserve-address Prop0 Cog6 okh00 PCA9955A reply
h03 PCA9624 and PCA9632DP1 reply
h70 PCA9624 and PCA9632DP1 reply
h76 PCA9955A reply
'i2c_detect' don't count reserve-address as i2c-device.
h70 and h76 isn't reserve-address.
So i2c-devices are 14pcs. Actually 12pcs.
Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: 00 -- -- 03 -- -- -- -- 08 -- -- -- -- -- -- -- <-- 8:PCA9955A 10: 10 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h10:PCA9624 20: 20 21 -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h20:PCAL95554BPW h21:PCAL9555APW 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 49 4A -- 4C -- -- -- <-- h48:PCT2075 h49:LM75 h4C:SC16IS750 h4A:PCF8591 50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- <-- h50:eeprom h51:PFC85263 60: -- -- 62 -- -- -- -- -- 68 -- -- -- -- -- -- -- <-- h62:PCA9632DP1 h68:MPU6050 70: 70 71 -- -- -- -- 76 -- -- -- -- -- -- -- -- -- <-- h71:PCA9546 i2c_device:15 [0 - 7] and [h78 - h7F] are reserve-address Prop0 Cog6 okh00 - PCA9955A reply
h03 - PCA9624 and PCA9632DP1 reply
h70 - PCA9624 and PCA9632DP1 reply
h76 - PCA9955A reply
'i2c_detect' don't count reserve-address as i2c-device.
h70 and h76 isn't reserve-address.
So i2c-devices are 15pcs. Actually 13pcs.
Slaveaddres is h51.
Same as PCF85263(rtc).
So, separate by PCF9546.
Connected PCF85263(rtc) to PCF9546's [SC0 SD0].
Connected PCF2129(rtc) to PCF9546's [SC1 SD1].
No connecting any line by default.
i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: 00 -- -- 03 -- -- -- -- 08 -- -- -- -- -- -- -- 10: 10 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: 20 21 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 49 4A -- 4C -- -- -- 50: 50 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- 62 -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: 70 71 -- -- -- -- 76 -- -- -- -- -- -- -- -- -- i2c_device:14 [0 - 7] and [h78 - h7F] are reserve-address Prop0 Cog6 ok 1 switch Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: 00 -- -- 03 -- -- -- -- 08 -- -- -- -- -- -- -- 10: 10 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: 20 21 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 49 4A -- 4C -- -- -- 50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- <--- h51:PCF85263 60: -- -- 62 -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: 70 71 -- -- -- -- 76 -- -- -- -- -- -- -- -- -- i2c_device:15 [0 - 7] and [h78 - h7F] are reserve-address Prop0 Cog6 ok 2 switch Prop0 Cog6 ok i2c_detect 0 1 2 3 4 5 6 7 8 9 A B C D E F 00: 00 -- -- 03 -- -- -- -- 08 -- -- -- -- -- -- -- 10: 10 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: 20 21 -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 49 4A -- 4C -- -- -- 50: 50 51 -- -- -- -- -- -- -- -- -- -- -- -- -- -- <--- h51:PCF2129 60: -- -- 62 -- -- -- -- -- 68 -- -- -- -- -- -- -- 70: 70 71 -- -- -- -- 76 -- -- -- -- -- -- -- -- -- i2c_device:15 [0 - 7] and [h78 - h7F] are reserve-address Prop0 Cog6 okThere are bugs in PCF85263_0.1.f.
I will fix bugs someday.
http://forums.parallax.com/showthread.php/123831-PropForth-3.2-is-available/page3
I re-write code.
[video=youtube_share;RBlLZramuIQ]
Propforth 6 is primarily Propforth 5.5 with changes to the build process. Included are:
- Build for FPGA versions of the prop.
- Linux build - PropTool for windows is no longer required
- SPIN is no longer required. SPIN is still generated (E.G. for changing clock speed and serial I/O pins); however the binary file created can be loaded directly. The SPIN and the binary are identical once loaded on the prop.
Also included are:
- Pooled tasking (extension)
- controled serial on both ends (tool chain mod)
FGPA prop: Propforth typically uses a subset of the prop's functions. Sal typically does realtime bit-banging, and so does not often use features like video generation B-side provisions, and more advanced frequency functions (I'm not sure about the last one). Anyway, the FPGA versions allow us to remove any unsued frealestate, like the video generator and the B-side functions, and instead add more cogs and/or memory. The same propforth source code that runs on a physical prop chip will run on the FPGA prop, and tcode that runs on an FPGA prop will also run on the physical propchip. Sal has examples of 8 cogs and lots of ram, and 16 cogs and not so much ram, but still more than the physical prop. If the FPGA board is present, the automated build will build and load the FPGA as well as build and load the propforth kernel, and then perform the automated testing as usual.
LINUX BUILD: Way back when we first looked at linux build, we were just getting away from the original Windows/Proptool method. Build was successful on a linux PC, but required special steps. Now, we should be able to compile on any linux box (PC, raspberry pi, DLink DIR-505L). The result off this should be an easy integration of a propforth unit (realtime multitasking) with a linux unit (PC or DIR-505L).
No SPIN: Till now, the Proptool was used to resolve things like forward references in the compile process. The inital kernel would run a simple version of forth, and this loaded addition forth source, which in turn generated the optimized assembler kernel (per the typical forth development methodology). Now, we will just go to directly generating the optimized kernel at the end of a linux tool set. A SPIN file can still be generated for when anyone wants to tweak the kernel at that stage. The untweaked SPIN file and the binary file will look identical on the physical prop chip.
Pooled Tasking: Generic forth multitasking in software is a "round robin". Each task does it's thing, and processign at full speed, and gives up control when it hits a slow spot, for example when it has to hit I/O. This is how forth can manage realtime multitasking on single task processors. The engineer has to pay attention and balance stuff, but its very effective when done well, and its pretty easy. Sal is doing a similar thing on the prop. In additon to each task being in a pool, the cogs are also in a pool. The next task executes on the next availible cog. Each task give up control when it hits a slow spot, for example when it has to wait for a shared resource like hub ram. This was a mod to the kernel, but might manifest as an extension that we just load on top of the standard kernel.
Here is the really cool advantge of pooled tasking: If a task has to wait a long time, it would ruin the "realtime" response of the process, which is very noticable on a single core system. On the physical prop with 8 cogs, it only reduces the capability of the system by 1/8th. On a 16 cog FPGA prop, a stalled task reduces system capability by 1/16th. This might allow some interesting flexibity in realtime/multiasking systems.
Controlled serial: serial comms have been problematic as the serial "standard" is not very standard at all, and tends to be many conflicting "standards" that always find a way to screw up right when we don't want them to. The fl (fastload) was used to load source text by streaming it to an available cog, and that cog handled the buffring etc. It would fine most of the time, but still had problems at awkward times. Now Sal has decided that the only way to get it completely consistent is to control (as in "define") both ends of the serial communication interface. The work started with the "gotern" and "gomuxterm" functions are now integrated into the tools, and serial communication between the host and the prop "just works". I don't know what this means to Windows or Mac, we will work through that when (if) it comes up.
we're still at least weeks out before I get anything for testing, but at least we can know what to expect. As always I can send out the early version to interested folks once we declare it clean and stable.
Incidently, Sal has not found any bugs in the propforth kernel for a couple years, so we are becoming confident that the code might be good.
C source code - for the proxy terminal
GO sourcre code - for the PC serial comms
PropForth - for the build and development environments
Linux and Windows will be included, and Mac support will be included according to the hardware we have available. We might need to find a new Mac person, this will be resolved later as it becomes relevant.
We talked about 32 and 64 bit support. Most everything is already on 64 bit architecture machines, but a few folks might only have access to 32 bit PC's. We decide that maintaining both 32 bit and 64 bit processes would be doable, but would be time consuming PITA. So, Sal said he would do BOTH 32 and 64 bit ONCE. After the first release of PF6, only 64 bit PC will be supported. The 32 bit material would be included, but would not be supported. If anybody does not have access to a 64 bit PC, they can request a 32 bit build. We would then try to talk them into upgrading, and generate 32 bit builds as needed. I just tossed my old 32 bit PC's, so everything would likely be done on virtual box machines.
[video=youtube_share;khI0aDt32QE]
Maybe cannot read time.
[video]
Youtube image don't be displayed.
Somebody know this reason?