May I suggest we create three directories in this repo?
- Sample component scripts
- Sample startup scripts
- Computer scripts/batch files
1 Like
Sure thing, and I’ll add it as a submodule to the firmware repo.
3 Likes
i used it as a logic analyzer in a pinch because i did not feeling like rewiring a harness to read spi commands, it worked for me well enough to use sigrok to then decode what i needed.
3 Likes
As sump seemingly works fine on the BP6 along with protocols, what are the benefits of fala specifically for bp6?
In SUMP mode the Bus Pirate acts as a typical logic analyzer. You set sample count, triggers, and arm each capture.
In FALA mode the Bus Pirate captures every bus action automatically, and sends the samples to PulseView in the background. You get a live view of what happened on the bus automatically without any kind of configuration.
4 Likes
| Mode | FALA Syntax | FALA Commands |
|---|---|---|
| 1-WIRE |  |
|
| UART | |
|
| HDUART | |
|
| I2C | |
|
| SPI | |
|
| 2WIRE | |
|
| DIO | |
|
| LED | |
|
Final FALA testing in syntax and commands (such as scan).
Commands are going to be tricky. FALA is setup as a single shot buffer, not a loop, so if the command length exceeds the FALA capture buffer weird things happen. For now I just want to make sure everything is wrapped by the capture commands and is FALA compatible.
1-Wire
Mode commands (such as scan) are now wrapped in FALA capture hooks. This is done at the outer most level in ui_process.c, meaning even commands that don’t generate bus activity (such as reading help) will generate captures. I should probably rework the command struct anyways, and add a flag that determines if the app can handle it’s own FALA (same as the general vs. command provided help works now).
All mode commands (that make sense) now handle fala internally for the best user experience. However, the global FALA capture can still be enabled if a command does not want to explicitly support FALA.
2 Likes
struct _global_command_struct {
char command[MAX_COMMAND_LENGTH];
bool allow_hiz;
void (*func)(struct command_result* res);
char* help_text;
};
struct _local_command_struct {
char command[MAX_COMMAND_LENGTH];
void (*func)(struct command_result* res);
char* description_text;
bool fala_supress_capture;
};
I’m going to do some rework of the command structs:
- Separate global and local command structs
- Add option to suppress fala captures and allow the command to handle it internally
- Maybe a few other tweaks when I get in there
Then I will update all the mode commands to handle FALA captures internally for the nicest possible user experience.
3 Likes
All of the global and mode commands have been updated with the new structs, and have been integrated with FALA.
Modes still need to be verified one by one. Will work on that now.
1 Like
Bugs
If buffer wraps, returns -1 and pulseview crashes. (1-Wire BS18B20 commands)Returning 0 samples causes malloc in pulseview but it doesn’t crash so that’s an improvement.DIO transitions stair-step offset
UART
Updated FALA to know when the buffer wrapped and report invalid buffer error. This can be enhanced later.
Check this out! Even the decoders work live and update with every capture.
HDUART
Seems to be working, but note that there is currently no way to auto trigger on incoming data. This is something we can polish up later.
SPI
The RESID (reset ID) has a long delay, which is what you can see
2WIRE
2WIRE and sle4442 command seem good to go.
DIO
DIO works, but I noticed some offset when changing pins.
Changed to a pin mask method so every pin changes at the same time.
LEDs
WS2812 (single data wire) LEDs are definitely getting cut off while stuff is still in the buffer. Will get that next.
- Future feature: when working with on-board LEDs, we can move the FALA base pin to RGB_CDO internally. For now, FALA won’t show anything when using onboard LED.
A new wait_idle function seems to work ok, but we have another issue related to idle:
The reset for these LEDs should be >50uS idle.
case M_LED_WS2812:
case M_LED_WS2812_ONBOARD:
hwled_wait_idle(); //wait until the FIFO is empty and the state machine is idle
busy_wait_us(50); // 50ms delay to reset
I added the wait idle before the 50uS delay, but it is not working in here. So maybe the wait idle isn’t working the way I think it is.
Had to increase the reset delay to 100us to get my string of LEDs to cooperate. WS2812 is working. Now to test APA102…
Turns out there are several bugs in the APA102 mode:
- Start frame is sent four times
- Stop frame is incorrect and sent four time
- No automatic handling of the data start bits and global brightness
Partially fixed, but I still don’t like how spaced out the frames are.
There we go. 0x00000000 start frame. Three pixels of data with 0b111 + global set to high. 0xFFFFFFFF stop frame.
2 Likes
Iwill test that out with 2-Wire when j am bavk home. Thanks for that
Awesome, thank you!
2WIRE and HDUART are based on the same PIO program, they will probably cut off sampling early and will need a “wait until everything is done” flag.
Can you explain why there are two columns? I don’t understand .
And to be clear, you start up FALA mode with the command FALA. Does this have to be before or after mode selection?
And then youproceed with your normal BP commands,while you have sigrok running, right?
The two columns:
- FALA syntax: the mode has been verified that FALA works as intended
- FALA commands: the commands have been updated to work with FALA, but may not work if the mode syntax functions are not verified.
The second column isn’t really needed, I managed to port all commands to FALA very quickly.
Use binmode to select FALA at any time. It will update when you switch modes. Here’s the guide for FALA and Pulseview:
That’s a pretty good round of testing and bug fixes all over the place 
The remaining modes (HDUART, I2C, 2WIRE) all use the same basic PIO program, so I’ll fix those all at once tomorrow.
2 Likes
Ah! Thanks! I didn’t realize the on-line docs were updated re: FALA. I’ll have to try it out. Need help porting the modified pulseview to Linux?
1 Like
Thanks for checking it out! I hope you find it as magical as I do
I believe there is a thread on compiling for Linux from @phdussud 's git repo.
Let’s hold off on a distributable though, as it sounds like there may be so me tweaks to the protocol and some fixes to PulseView.
1 Like
2WIRE mode has been updated to status “verified for FALA” Two more to go!
2 Likes
HDUART has been verified.
Something to think about: we don’t currently trigger on incoming bytes in async protocols like UART and HDUART. We could set a trigger on the appropriate pin and then capture incoming bytes too.
1 Like
To avoid losing this, consider opening a GitHub issue to track this future feature?
2 Likes
I2C mode validation is in progress, but I ran into a nasty bug in the new syntax compiler that ate of most of my afternoon.
At the moment, I2C does not seem to work with FALA at all, but I have not dug into the cause.